mautrix bridge user-state lives in the bridge's SQLite, not Matrix
Migrating a mautrix bridge from one host to another (e.g., moving the bridge process to a different machine for IP-egress or geography reasons) while keeping the same Synapse, same Matrix user, same conversations.
When you replace a mautrix bridge instance — even one for the same protocol, same Synapse appservice registration, same user MXID, in the same DM room — the per-user UX state silently resets. Things like 'is this room marked as my management room' and 'am I logged in to the remote network' are persisted in the bridge process's local SQLite (mautrix-linkedin.db etc.), not in Matrix account_data or any Synapse-side store. So the fresh bridge instance starts with no record of the management-room marking. The Matrix conversation in Element looks unchanged: same room, same bot, same history. But suddenly the bot stops responding to bare commands like 'login' or 'help' because it now requires the '!<prefix>' to recognize them outside a management room. From the user's perspective it looks like the bridge is broken; in reality the bridge is fine, the state just didn't migrate. Fix is mechanical (just send '!<prefix> set-management-room' once on the new instance) but the failure mode is easy to misdiagnose because everything ELSE about the room is identical.
When migrating a mautrix bridge to a new host, document the per-user re-setup steps as part of the migration runbook: re-set management room, re-do login (the SQLite-stored login state is also fresh). Don't expect the user-facing experience to pick up seamlessly even when Synapse-side identity is preserved. If you preserve the bridge's SQLite file across hosts (rsync mautrix-<name>.db to the new host) you avoid this — at the cost of carrying along potentially-stale login tokens that may need refresh anyway.