Email migrations have a reputation, and it's mostly earned. Everyone knows someone whose company lost a morning of mail, or spent a week fielding "did you get my message?" calls.
But migrations don't fail randomly. They fail for a small number of predictable reasons, and every one of them is a preparation problem rather than a technical one.
Reason one: nobody counted the mailboxes
Not the licence count - the actual mailboxes. Shared mailboxes nobody owns. The distribution list that quietly forwards to a former employee. The alias that one important customer has used for six years.
Every one of those is a thing that can silently stop working, and silence is the problem. A broken mailbox announces itself immediately. A broken alias just means mail stops arriving and nobody notices for a month.
Reason two: the cutover happened at the wrong moment
There is no good time to migrate email, but there are plenty of bad ones. The end of the quarter. The week a big campaign launches. The Friday before someone important goes on leave.
The best cutover window is boring: low volume, full team available the next morning, and nothing else changing at the same time. If you're also switching your CRM that weekend, you've just made every future problem twice as hard to diagnose.
Reason three: it was never tested
"It worked in the test migration" and "we tested the migration" are different sentences.
A real test means moving a real mailbox, with real volume and real folder depth, and then actually opening it. Nested folders, calendar invites with attendees, shared calendar permissions, mobile clients reconnecting. Every one of those has its own way of going wrong, and none of them show up in a spreadsheet.
What good looks like
A migration that doesn't hurt tends to follow the same shape:
- Inventory everything. Mailboxes, aliases, shared boxes, lists, forwarding rules, integrations that send mail on your behalf.
- Pre-stage the data. Move the bulk of it before cutover, so the final sync is small and fast.
- Test with real mailboxes. Including the messiest one you have - usually whoever has been there longest.
- Cut over during a quiet window. Then be present the next morning, when the real questions arrive.
- Support the first week properly. Most issues aren't outages; they're people whose phone stopped syncing and who need two minutes of help.
Done that way, the downtime is usually measured in minutes, and the questions mostly aren't about mail at all.
The part people skip
The last step is the one that gets cut when a project runs long, and it's the one that determines how the migration is remembered. Users don't judge a migration by its data integrity. They judge it by whether their phone worked on Monday.
If you're weighing a move to Microsoft 365 or Google Workspace, we'll scope it with you - including the boring parts that decide how it goes.