Email migration to Microsoft 365: what actually goes wrong

The mail almost always arrives. What goes wrong in an email migration is everything attached to it: the calendar and contacts that quietly do not come across, the scanner in the corner that has been emailing invoices for six years, and the authentication records that still describe the old provider, which is why your mail starts landing in customers' junk folders a week after everyone said it went well. Plan for those and a migration is a non event. Ignore them and you spend a fortnight on surprises.

Last updated 14 August 2026. We review this guide every six months, and after any significant change to Microsoft's migration options.

Most of this needs administrator access to both systems. You need control of the domain's DNS records, admin access to the system you are leaving, and admin access to the Microsoft 365 tenant. If you do not have DNS access, find out who does before scheduling anything, because that is the item most likely to stall a migration on the day.

The method decides what survives

Before anything else, establish how the mail is actually being moved, because the methods are not equivalent and the differences are not cosmetic.

IMAP migration is what gets used when moving from most non Microsoft systems, including a lot of older hosting company mail. It has two limitations that catch people every time:

• It moves mail folders only. Contacts, calendar entries and tasks cannot be migrated this way. If nobody says so in advance, people discover it when they open a diary that stops on the day of the move.
• It does not create mailboxes. Every mailbox has to exist in Microsoft 365 first, which means accounts built and licences assigned before the migration begins.

There is a third catch worth knowing: once an IMAP migration finishes, new mail arriving at the old system is not brought across. If the changeover is not sequenced properly, mail that lands during the gap sits in a system nobody is watching.

Cutover migration applies when moving from an on-premises Exchange server, and it does bring mail, calendar and contacts together. It supports up to 2,000 mailboxes on paper, though Microsoft's own guidance is that 150 or fewer is realistic given how long creating and migrating that many accounts takes. For most small businesses one cutover over a weekend is the normal approach. Larger organisations use a staged migration in batches, or run both systems together during a longer transition.

The inventory is the job

The single highest value hour in any migration is spent listing everything that sends or receives mail. Not just the mailboxes: everything.

Mailboxes and people are easy, and everyone remembers them. What gets forgotten is the machinery:

• Scanners and copiers that email scanned documents to staff.
• Alarm systems, camera systems and monitoring equipment that send alerts.
• Accounting and booking software that emails invoices, statements and confirmations to customers.
• The website contact form, which is often sending through the old mail server.
• Distribution lists and shared addresses that were never proper mailboxes, such as an info address that quietly forwards to three people.
• Old mail in local data files on individual computers, which lives nowhere else and will not be part of any server migration.

None of these complain on the day. They fail silently, and you find out weeks later when a customer says they never received an invoice, or when nobody noticed that the alarm stopped emailing. Write the list before you migrate, and test each item afterwards.

Get the accounts and licences ready first

Build the mailboxes and assign the licences before the migration starts, not during it. An account without a licence that includes Exchange Online has nowhere to put the mail, and this is a genuinely common cause of a migration that appears to run and delivers nothing.

This is also the moment to make decisions you would otherwise carry across by accident. People who have left should become shared mailboxes rather than licensed accounts, generic addresses like info and accounts should be shared mailboxes too, and anything that exists only because of how the old system worked should be questioned now. Migrating your existing mess costs the same as migrating a tidy version of it. Our guide to shared mailboxes covers which addresses do not need paying for.

Pre-stage the bulk, then cut over

The pattern that keeps a migration boring: copy most of the mail across while the old system is still running normally, so the final switch only has to carry whatever arrived since. A migration that tries to move everything at the moment of cutover turns a short changeover into a long outage.

Then change the domain's MX records to point at Microsoft 365 and run a final synchronisation to collect the remainder. Expect a period after the DNS change during which some senders still deliver to the old system, because the internet takes time to catch up, and plan to sweep it once more before decommissioning anything.

Do not switch off the old mail system on the day. Leave it running, reachable and unmodified for a few weeks. It costs very little and it is the only thing that will save you if something turns out to be missing.

The problem that appears a week later

This is the one that turns a successful migration into a bad reputation, and it is entirely preventable.

SPF, DKIM and DMARC are the records that tell receiving mail servers who is allowed to send on behalf of your domain. After a migration they still describe your old provider. Until they are updated, mail that is genuinely from you no longer looks like it, so receiving servers file it into junk, and the strict ones reject it outright and your senders get bounces.

The reason it does so much damage is the delay. Everything works on the day, the migration is declared finished, and the drop in delivered mail shows up gradually over the following fortnight as people mention that they did not receive things. By then nobody connects it to the migration. Update the records as part of the cutover, then check them, and read why business email lands in spam for what each record does. If senders are getting bounces, the bounce code names the cause, and a DMARC rejection is unmistakable once you know what it looks like.

What to check the day after

A migration is not finished when the mail arrives. Before you call it done:

• Send and receive from outside the business, not just internally, because internal mail proves almost nothing.
• Test every device and application on the inventory list, individually.
• Confirm calendars and contacts are present, especially if the move was IMAP based.
• Check shared mailboxes appear for the right people and that they can send, not just read.
• Confirm mobile phones are reconnected, which is where most of the remaining help requests come from.
• Verify SPF, DKIM and DMARC describe the new arrangement.
• Leave the old system running for a few weeks before decommissioning.

If mail is not arriving for someone afterwards, work through why Outlook is not receiving emails, and expect the answer to involve the old system or DNS rather than the new mailbox.

FAQ

Will an email migration lose my calendar and contacts?

It depends entirely on the method, and this is the most common unpleasant surprise. An IMAP migration, which is what is used when moving from most non Microsoft systems, moves the contents of mail folders only. Contacts, calendar entries and tasks cannot be migrated that way and have to be moved separately or exported and imported by hand. A cutover or staged migration from an on-premises Exchange server does move mail, calendar and contacts together. Ask which method is being used before you assume your diary is coming with you.

How long does an email migration take?

The copying takes as long as the volume of mail and the speed of the connection dictate, and for a small business it is usually an evening or a weekend. The part that determines the real timeline is everything either side: building the accounts, assigning licences, reconfiguring every computer and phone, and tracking down the devices that send mail. Plan by the number of people and devices rather than by gigabytes, because the desk visits, not the data, are what fill the calendar.

Will we lose email during the changeover?

You should not, provided the sequence is right. Mail is normally copied across in bulk before anything is switched, so the final cutover only has to carry a small remainder. The risk window is the period after the MX records change while the internet catches up, and mail arriving at the old system during it needs to be collected in a final pass. With an IMAP migration this matters especially, because mail that arrives at the source after the migration finishes is not brought over automatically.

Why did our email start going to junk after we moved to Microsoft 365?

Because the records that prove your mail is genuinely yours still describe the old system. SPF, DKIM and DMARC tell receiving servers who is allowed to send on behalf of your domain, and after a migration they need updating to describe Microsoft 365. Until they do, your legitimate mail looks unauthorised, and receivers respond by filtering it into junk or rejecting it outright. It is the single most common post migration complaint and it is entirely preventable.

What gets forgotten in an email migration?

The things that send mail without a person attached. Scanners and copiers that email documents to staff, alarm and camera systems that send alerts, booking and accounting software that emails invoices and receipts, and website contact forms. None of them complain at the time, and all of them stop quietly. The other common omissions are old mail sitting in local data files on individual computers, distribution lists, and shared addresses that were never proper mailboxes.

How many mailboxes can move at once?

A cutover migration from an Exchange server technically supports up to 2,000 mailboxes, but Microsoft's own guidance is that 150 or fewer is the realistic number, because of how long it takes to create and migrate that many accounts. For most small businesses this is academic, since a cutover in one go is the normal approach. Larger organisations move in batches instead, or run both systems side by side during the transition.

The bottom line

Ask which migration method is being used, because IMAP moves mail and nothing else. Write the inventory of everything that sends mail, including the machines, because that list is where the post migration surprises live. Build accounts and licences first, pre-stage the bulk so the cutover is short, and leave the old system running for a few weeks afterwards. Then update SPF, DKIM and DMARC on the day rather than when someone complains, because the alternative is a fortnight of your mail arriving in junk folders while everyone believes the project finished successfully.

If you would rather hand the whole thing over, what a managed move involves and what it costs is set out on our business email and Microsoft 365 setup page.

Moving your email and would rather it was uneventful? We plan the inventory, do the cutover out of hours, and check the authentication records before anyone notices. Tell us what you are moving from and we will tell you what it involves.