Email migration is one of those jobs that is either completely uneventful or the worst fortnight of somebody's year, and the difference is almost entirely in the preparation rather than the technology.
This is the sequence we use for UK businesses moving from a hosted POP or IMAP service, an on-premises Exchange server or another cloud provider into Microsoft 365.
Stage 1: find out what you actually have
Two weeks before anything moves. This stage takes a day and prevents almost every unpleasant surprise.
- Every mailbox, and its size. Including the ones nobody mentioned — the old enquiries address, the address on the vans, the one the accountant uses.
- Aliases and forwarders. These are invisible until they stop working, and then they are the reason an entire category of enquiry vanished.
- Distribution lists and shared mailboxes. Who is in them, who has access.
- Where DNS is managed. Not where the domain was bought. Where the records are actually edited, and who has the password.
- Devices and clients. Which people are on Outlook, which are on a phone only and who has a locally stored PST file they have never mentioned.
- Anything that sends mail as you. The website contact form, the accounting package, the booking system, the alarm. These break silently and are found by a customer.
That last one is the most commonly missed item in the entire process.
Stage 2: build the destination
Create the tenancy, add the domain and verify it, but do not change the MX record. Verification uses a TXT record and does not affect mail flow.
Create every mailbox, alias, shared mailbox and distribution list to match what you found in stage one. Set up licensing — remembering that shared mailboxes under 50GB do not need one — and configure the security baseline now rather than later: multi-factor authentication, conditional access if you are on Business Premium, and the audit settings.
Configuring security at this point rather than after go-live is the difference between a tenancy that is properly set up and one that spends two years at its defaults.
Stage 3: copy the mail while the old system still runs
This is the stage that makes the migration safe. Mail, calendars and contacts are copied into Microsoft 365 while the existing system continues to receive and deliver normally.
For most businesses this runs over several days. Large mailboxes and slow source systems take longer than anyone expects, and the throughput is usually limited by the source rather than by Microsoft.
At the end of this stage both systems hold the data. Nothing has been switched, nothing is at risk, and you can stop at any point with no consequence.
Every lost-email horror story I have investigated involved the MX record being changed before the copy had finished. There is no other common cause.
Stage 4: cut over
Early evening, Tuesday or Wednesday. Never a Friday.
The sequence matters:
- Run a final delta sync to pick up everything that arrived during the day.
- Lower the DNS time-to-live on the mail records to 300 seconds — ideally done 24 hours earlier so the old long TTL has expired.
- Change the MX record to Microsoft.
- Update SPF to include Microsoft, and add anything else that legitimately sends on your behalf.
- Publish DKIM and enable signing in the Microsoft 365 admin centre.
- Add or update autodiscover so Outlook configures itself.
- Leave the old system receiving for at least a fortnight. It costs almost nothing and it catches every sender whose DNS cache was stubborn.
Send a test message from an outside address and confirm arrival before anyone goes home. Then send one from the website contact form, which is the item most likely to have been forgotten.
Stage 5: the next morning
Be present at the start of the working day rather than reachable. Most issues surface in the first hour and are trivial to fix in person.
The predictable ones: a phone that needs its account re-added, somebody whose Outlook profile did not migrate cleanly, a shared mailbox that needs permission reapplied and one person who has been using a PST nobody knew about.
The four things that go wrong
Rushing the DNS. Covered above. It is the only genuinely destructive mistake in the list.
Forgetting what else sends as you. The website form, the invoicing system, the CRM. If SPF does not list them, their mail starts landing in spam within a day or two. Worth reading the SPF, DKIM and DMARC guide before cutover rather than after.
Deleting the source too early. Keep the old system, in read-only if you like, for at least sixty days. It costs a small amount of money and it is the answer to every awkward question in the first two months.
Assuming Microsoft backs it up. It does not, in the sense most businesses mean. Retention and recycle bins are not backup, and configuring a proper backup should be part of the project rather than a later thought. There is more on that in this article.
What good looks like afterwards
Every mailbox intact including calendars and contacts, every alias still working, SPF, DKIM and DMARC published correctly, multi-factor authentication on every account, backup running and a documented record of what was changed and where DNS lives.
That last item is worth more than it sounds. The next person to touch your DNS will thank you, and quite often that person is you in three years.
If you would like this run without anybody in your business having to think about MX records, our infrastructure team migrates UK businesses to Microsoft 365 as routine work, out of hours, with the security baseline configured properly on the way in. Ask us for a migration plan.
