Shared inboxes work far longer than people expect, and then stop working very suddenly. The usual triggers are a second channel, a third timezone, or the first time two agents reply to the same customer with different answers. By then the inbox holds years of institutional memory, which is exactly what makes migration feel risky.

Week one: audit what you actually have

Before touching anything, inventory every address and channel that receives customer messages, including the ones nobody admits to: a founder's personal address, a legacy billing alias, a dormant Facebook page. Then measure volume, unique senders and median response time per source. Two things usually emerge, a long tail of near-dead addresses you can retire, and one unofficial channel carrying real volume.

Week two: decide what history moves

Full historical import is rarely worth it. A pragmatic split:

  • Import: the last 12 to 18 months of conversations, mapped to customer records. This covers almost every case an agent will look up.
  • Archive, searchable: everything older, kept in the original system or an export, with a documented way to search it.
  • Do not import: automated notifications, bounces and internal chatter. They inflate your data and corrupt reporting baselines.

Agree the identity mapping rules at this stage, because the import will expose every duplicate customer record you have.

Week three: run in parallel

Forward inbound mail to the new platform while keeping the old inbox receiving. Agents work exclusively in the new system; the old inbox is read-only insurance. Set a hard rule that no reply goes out from the legacy inbox, because a single out-of-band reply creates a thread the new system cannot see. Use this week to build queues, macros and routing rules against real traffic rather than assumptions.

Week four: cutover and instrument

Change the MX or forwarding configuration properly, migrate remaining open conversations by hand, there are usually fewer than fifty, and publish the new expectations internally. Then watch four numbers daily for a fortnight: unassigned conversation count, oldest unanswered conversation, response time distribution, and the number of replies still leaving the legacy system. The last should be zero within days.

Keep a rollback you can actually execute

Rollback is a forwarding change plus a communications message, and it should be written down before cutover with a named decision owner and a threshold that triggers it. Teams that skip this step tend to muddle through a bad week rather than reverting cleanly.

What good looks like at day 60

  • Every inbound channel lands in one queue with explicit ownership.
  • Response time is measured, not estimated, and reported by channel and account.
  • No conversation is invisible: nothing is answered from a personal address.
  • New agents onboard against documented queues and macros instead of inbox folklore.

The migration itself is a fortnight of real work. The value comes from what becomes possible afterwards, automation, proactive messaging and reporting that were structurally impossible in a shared inbox.