You Moved the Mailboxes. Did You Move the Business?
Mail is arriving in the new inboxes, which is how the migration got declared a success at 4 p.m. Then the shared mailbox that nobody can open, the mobile calendars that stopped updating, and the office phone that syncs to an account the new provider does not know. The mail moved. The business, it turns out, was wearing more than mail.
Three jobs wearing one name
A mail migration is three separate jobs that share a verb, and each one fails in a different week. Copying is the messages, the folders, the history, moved from the old service to the new. Routing is the DNS: the MX records that decide where new mail lands, and the authentication records that decide whether it is trusted. Workflow is everything the day job actually uses: shared inboxes, aliases, calendar delegation, phone sync, the website form, the invoicing tool.
"Mail is arriving" is evidence for exactly one of the three, routing, and it is the one that announces itself. The other two fail quietly, on a Thursday, in a feature nobody thought to check. The provider's documentation describes the copying in detail, because that is the part with buttons. Microsoft's migration path guidance, for example, is thorough about moving mailboxes and far less interested in your shared calendar for the parts room, because from the provider's side that is a workflow, not a mailbox. The sign-off exists to give the workflows a column of their own.
The sign-off grid
One table, four columns, one row per thing the business actually uses. Expected is written before cutover, actual is filled in after, and the owner column is the one that makes it a plan instead of a wish.
| Task | Expected | Actual | Owner |
|---|---|---|---|
| Personal mailboxes, send and receive | |||
| Shared inboxes | |||
| Aliases | |||
| External send and receive, other companies | |||
| Calendars and delegation | |||
| Phone sync | |||
| Website contact form | |||
| Invoicing tool | |||
| Historical search |
The last row is the one that always surprises. The history was copied, the provider said so, and then someone searches for a contract from two years ago and the index says nothing. Search indexing is a second, slower migration that nobody schedules, and the grid gives it a line to be wrong on.
Three checkpoints
Pilot and inventory. Move a few mailboxes first, the patient ones, and use the week to list everything that touches mail: the shared inboxes, the aliases, the tools, the phones. The pilot exists to find the provider-specific surprises, and the surprises are always provider-specific. Microsoft's IMAP migration troubleshooting is a good example of what the documentation looks like from one vendor's side; your actual pair of providers will have their own list, and the two of them differ from each other.
Cutover, with continuity documented. The MX change is the cutover, and it is the one step that is genuinely split: while caches settle, some senders reach the old service and some the new. That is expected and it is not a failure, but it has to be documented, because it creates a week in which a message can legitimately exist on either side. The cutover note records when the MX changed, what the continuity window was, and who is watching both inboxes through it. Do not cancel the old service inside that window, for the obvious reason.
Validation and reconciliation. The sign-off grid gets run, row by row, and then the reconciliation: counts compared, the split-week checked on both sides, and the grid signed. This is the checkpoint that "it works" turns into a list, and a list is the only form of "it works" that a second person can audit.
Two facts anchor the whole sequence. An MX change never copies history: it only redirects what arrives from now. And a plain mailbox copy, IMAP being the usual mechanism, may omit calendars, contacts, and rules entirely, depending on the tools at each end. Requirements vary by provider and by what the old service will release, which is why the pilot finds out rather than the cutover week.
Closing the old account
The old service gets cancelled by criteria, not by vibes, and the criteria are all on one short list. The sign-off grid is fully green, not mostly, for a period long enough to be boring. A final sync has run, so the last messages of the split week made it across. An export of the whole history has been saved to a file the business owns, in a format named and tested, because the old account is about to stop being a library and become a memory. The vendor's retention terms have been read, so the business knows what the provider keeps, for how long, and under what conditions. And the rollback path was defined before cutover, because the one thing a rollback must handle that no plan thinks of is the message accepted by the service that is about to be switched off.
Keep the old mailbox until the grid says otherwise. "Mostly working" is not a sign-off.
Migrations get judged on the morning of cutover, because that is when the visible thing happens: the addresses, the inboxes, the first message. The business, though, runs on the invisible three: the shared inbox the front desk lives in, the calendar the whole week is arranged around, the tool that sends the invoices. Move the mailboxes and you have moved the addresses. Sign off the grid, row by row, with a name on each one, and only then have you moved the business. The step everyone skips is the last column, and it is the only one that turns a migration into an acceptance test.
Migration questions
Does changing the MX record move old mail?
No. MX records decide where mail from now on gets delivered. They have no memory of what arrived before, and changing them touches nothing in the past. History moves only by an explicit copy, which is a separate job with its own failure modes.
Will calendars transfer?
Depends on the pair of providers and the method. A full platform-to-platform migration usually carries calendars; a plain mailbox copy often does not. The pilot is where this gets tested with a real calendar, because it is the one item whose absence a staff member will notice for a week before anyone connects it to the move.
How can I spot messages accepted by the old service?
By the split-week reconciliation: while caches settle after the MX change, watch both inboxes, note what landed where, and check that each side's copy is searchable afterward. A message that arrived at the service you are about to cancel is the one to verify exists on the other side before the cancel, not after.
When can the old account be closed?
When the grid is green for a full boring period, the final sync is done, an export is saved in a format you can open, and the vendor's retention terms are on the page. "We are not getting mail there anymore" is necessary and not sufficient, because the history is still in there and so is the split week.
More from the blog
- Why Your Business Email Goes to Spam, the deliverability half of the same records
- Before You Enforce DMARC, Find Everything That Sends as Your Business, the fleet a migration reorganizes
- Your New Website Is Live. Why Did Your Business Email Stop?, the cutover that forgot one record
All posts are on the blog. For the step by step versions, see the domain and hosting guides.
A move on the calendar?
Tell us what is at each end of the migration, and we will walk the grid with you: what the providers will and will not carry, what the pilot should test, and what the sign-off looks like when it is really done.