Details in this account are generalised and figures are omitted where they would identify the client.
The situation
A manufacturer with staff across an office, a production area and a small field team. Mail ran on an on-site server that was several years past the point where anybody wanted to touch it, backed up to a device in the same building.
The immediate driver was risk: no support path, no confidence in the backups, and a machine that had been restarted three times in six months for reasons nobody could explain.
What the preparation found
Three things that shaped the plan.
Twenty-two shared mailboxes, not the eight anybody knew about. Accumulated over a decade for departments, projects and customers. Several were unused; several had permissions granted to people who had left.
Building a complete list took a morning of examining the server rather than asking people. Asking produced eight; looking produced twenty-two. That difference is typical.
Mailboxes far larger than expected. Several individuals had well over a decade of mail with substantial attachments. This determined the transfer approach and the timeline more than the user count did.
Six systems sending mail as the company. The website contact form, the accounting system, an alarm monitoring service, the production system, a marketing platform and a courier portal. Two of these nobody had remembered until we went looking.
That last finding mattered most, because email authentication records had to cover all of them or their mail would start failing after the move.
The finding that determines a mail migration is not how many users there are. It is how many things send mail as you, and the answer is always more than anybody says.
The sequence
Weeks one to two: preparation. Accounts created, licences assigned, shared mailboxes recreated with permissions matching a reviewed list rather than the existing one. Unused mailboxes were archived rather than recreated.
Week three: first sync. Mailbox contents copied while the old server continued to receive. Users unaffected and unaware.
Week four: authentication records prepared. Updated to cover the new platform and every one of the six sending systems, with a policy that reported rather than enforced, so that anything failing could be seen before it was blocked.
Week five: cutover. A Friday evening. Mail routing switched, a final synchronisation run to capture anything delivered during the gap, and testing before anybody arrived on Monday.
Weeks six onwards: monitoring. Authentication reports reviewed weekly, and the policy tightened in stages once they were clean.
The two things that caused trouble
A field team member's device. One person's phone had been configured years earlier with settings nobody could now recall, and it continued attempting to connect to the old server for two days after cutover. They had mail on the new platform and did not realise, because their phone showed the old account.
Lesson: check devices explicitly at cutover rather than assuming people will notice. We now include a device list in the preparation.
The alarm monitoring system. It sent mail through the old server using a method the new platform does not support. This was discovered during preparation rather than after — but only because somebody thought to check what would happen rather than assuming it would work.
It was reconfigured to send through an approved route. Had it been missed, alarm notifications would have stopped silently, which is the category of failure that matters.
What went well
The staged authentication approach. Publishing a reporting-only policy first meant every legitimate sender was identified before anything was enforced. Nothing was blocked, and the two systems nobody remembered appeared in the reports rather than in complaints.
The shared mailbox review. Recreating twenty-two mailboxes as-is would have carried a decade of stale permissions into a new platform. Reviewing them first meant the new arrangement reflected who actually needed access.
Cutting over on a Friday. Two people were available all weekend, which is what turned two small problems into things fixed before Monday.
What we would do differently
Build the device inventory earlier. It should sit alongside the mailbox inventory in week one.
Address the mailbox sizes before migrating. Archiving old mail before transfer rather than after would have shortened the synchronisation considerably.
Test the sending systems in a rehearsal. We verified their configuration; we did not send a test message from each until close to cutover.
The general lessons
Find every system that sends mail as you. There are more than you think, and they are the cause of post-migration deliverability problems — see SPF, DKIM and DMARC explained.
Review shared mailbox permissions rather than replicating them.
Publish authentication policy in reporting mode first, always.
Our managed IT team migrates UK businesses to Microsoft 365 with this sequence — see also the migration guide. Start a conversation.