Every email migration that goes wrong goes wrong for the same reason, and the reason is not technical.
The technical part is a solved problem. Microsoft has a ready-made tool, the process is documented, and copying mailboxes from one server to another is decades-old work. What sinks a project is discovering, on Monday morning, that the invoicing system was sending email through an SMTP relay nobody documented — and that no invoice has gone out since Friday.
This article is about that part.
Before anything else: the inventory
Ninety percent of the success lives here, and it is the step everyone wants to skip because “it’s only email”.
Write down, on paper:
The real mailboxes. How many accounts exist, how much each one takes up, and which ones belong to actual people. Every company has accounts for people who left three years ago that nobody disabled, and generic accounts (contact@, finance@) that can become shared mailboxes — which do not consume a license and therefore lower the final cost.
The aliases. Alternative addresses that deliver into the same mailbox. The salesperson who receives mail at both sales@ and commercial@ will notice immediately if one of them disappears.
The distribution lists. everyone@, board@, site-2@. They do not come across with the mailboxes; they have to be recreated.
The rules and forwards. Especially external forwarding — the partner who sends a copy of everything to a personal Gmail. That changes the security configuration you will want to apply afterwards.
Who else sends email using your domain. And this is where the trap lives:
- the ERP sending invoices and payment slips;
- the HR system sending payslips;
- the email marketing platform;
- the website contact form;
- the multifunction printer that scans and sends by email;
- the monitoring system that sends alerts.
That list is almost always longer than the company imagines, and every forgotten item is a silent outage on Monday. Nobody complains that “the printer stopped scanning” until they need to scan something.
The current state of DNS. Where the domain is registered, who has access to the control panel, and what already exists for SPF, DKIM and DMARC. If nobody in the company knows the registrar login, find that out before you set a date. We have seen a project stall for two weeks waiting on the recovery of domain access.
Choosing the migration type
Microsoft offers different routes, and the choice depends on where you are coming from and how much downtime you can take. The mailbox migration documentation covers each one in detail; the practical summary:
Cutover. Everything at once, over a weekend. Simple, cheap, and the best option for most small companies. The practical limit is volume: if you have 200 GB of mailboxes and your upload runs at 10 Mbps, the arithmetic does not fit into a weekend — and that has to be calculated in advance, not discovered on Saturday.
Staged. In groups, over several weeks. It reduces risk, but it creates a period where half the company is on one system and half on the other — with the shared calendar working at half strength. Coexistence needs attention.
Hybrid. The two environments genuinely coexist, with integrated mail flow. This is the right option for large companies or those with regulatory requirements. For a 30-person company, it is a cannon with a cannon’s price tag.
IMAP. For when you are leaving a generic provider that only offers IMAP. It works, but it brings only the email — contacts, calendar and rules are left behind and need a plan of their own.
For most small and mid-sized companies leaving a typical hosting provider, a weekend cutover is the right answer — and the cheapest one.
Migration week, day by day
Two weeks before
Lower the TTL on your DNS records, especially the MX, to 300 seconds. The TTL tells servers around the world how long to cache the old answer. If it is set to 24 hours and you flip the switch on Saturday, part of the internet will keep delivering to the old server until Sunday.
This is the cheapest and most forgotten adjustment in the entire migration. Done in advance, the switchover takes minutes. Forgotten, you spend the weekend explaining why some emails have not arrived yet.
One week before
Create the users, the shared mailboxes, the groups and the aliases. Do not point the MX yet. The environment sits ready and empty, waiting.
Use the time to configure SPF, DKIM and DMARC properly — and here is a warning: if you copy the old SPF record and simply add Microsoft to it, you can end up with two SPF records on the domain. Two SPF records is the same as none: validation fails and your email starts landing in spam. There has to be one single record containing every legitimate sending source.
Tell people. A short message: what changes, when, and what they need to do (usually nothing beyond signing in with the new password).
Friday
Run the first synchronization with the MX still pointing at the old server. The bulk of the data uploads while everyone works as normal, with no pressure.
Saturday
Final synchronization — only the delta, whatever changed since Friday. Then flip the MX. With the low TTL, propagation is fast.
Test, properly:
- sending and receiving from outside;
- replying to an older message;
- three different people’s phones;
- the printer scanning;
- the ERP issuing a document;
- the website form;
- the shared calendar and the meeting rooms.
Monday
Have someone from the team available and physically present, not “on call by phone”. The questions are small — a phone password, a signature that disappeared, a contact that did not come across — but they all arrive within the same two-hour window. Solved on the spot, the migration is remembered as smooth. Pushed to the afternoon, it becomes the story of how “the migration was chaos”.
In the weeks that follow
Do not switch off the old server. Leave it standing, still receiving, for at least 30 days. It is your safety net — and keeping it one more month costs almost nothing.
Once everything is confirmed: turn on MFA, back up the new environment (Microsoft is not doing that for you) and tighten DMARC from p=none to p=quarantine.
The five mistakes we see most
- Not lowering the TTL. Turns a switchover of minutes into a weekend of explanations.
- Forgetting who sends using the domain. The printer, the ERP, the invoicing system. There is always one.
- Two SPF records. Broken authentication, legitimate email in spam, and a cause that is hard to track down afterwards.
- Switching off the old server too soon. Saves one month’s fee and creates a disproportionate risk.
- Migrating without backing up the destination. You left a server that had tape backups and arrived at an environment with no copies at all. Technically you migrated; in practice you went backwards.
How long it takes
For a company of 10 to 50 people leaving a typical provider, the realistic schedule is:
- Week 1 — inventory, decisions and the TTL adjustment;
- Week 2 — building the environment, authentication DNS, the announcement;
- The weekend — synchronization and switchover;
- Week 3 — follow-up, fine-tuning, security;
- Day 30 — decommissioning the old environment.
Three calendar weeks, at a few hours a day. Anyone promising “we’ll migrate on Saturday” is usually looking only at the mailbox copy — and it is precisely the rest that decides whether Monday is calm.
If you have a migration already scheduled, the inventory is the best place to invest your time. If you want a second opinion on your list before the date, it is a short conversation and it usually pays off.