Migrating mail to Microsoft 365 — what to plan before you start

Moving mail to Microsoft 365 is technically straightforward and well documented by the vendor. Problems almost never come from the mailbox migration itself. They come from things that were sending mail through the old server and nobody remembered — and from small details noticed only once they stop working.

Before you touch anything

Count what you are actually moving

Not the number of people, but the number of mailboxes: user accounts, shared mailboxes, aliases, distribution lists, functional mailboxes (office@, invoices@, service@). That last group is usually left out of both the quote and the plan.

Check sizes too. A mailbox holding twenty years of correspondence with attachments is a different transfer time from an account created last year.

Find everything that sends mail through the old server

The most important point on this list. A typical list in a small company:

• the multifunction printer with scan-to-mail,
• the invoicing system sending documents to customers,
• the shop or the form on the website,
• monitoring sending alerts,
• a CRM or quoting tool,
• an internal application sending notifications.

Each of these has the old server’s address, a port and a password configured somewhere. After the switch it will stop working — quietly, because nobody reads the printer’s logs.

The simplest way to establish this: go through the old mail server’s logs for what authenticates against it. The list takes fifteen minutes to produce and tends to be surprising.

Check that the domain records are under your control

Who has access to the DNS panel. How long a record change takes at that provider. What the TTL is set to — if it is 24 hours, lower it to a few minutes a week before the migration, otherwise the switch will drag out over a day.

Decide what happens to rules and archives

Rules set up in users’ mail clients usually do not travel with the mailbox. Neither do local archives in files on workstation disks — those can be large, nobody backs them up, and they can vanish along with a laptop replacement.

This is a good moment to collect them and pull them into the mailboxes.

The order that works

1. Domain added and verified in the new environment, MX records untouched.
2. Accounts created, licences assigned, MFA prepared but not yet enforced on everyone.
3. First mailbox synchronisation — the longest stage, runs in the background, does not interfere with work.
4. A trial migration on two mailboxes: your own and one friendly person’s. Confirm everything looks as it should.
5. Switching the MX records — Friday afternoon, not Monday morning.
6. A delta synchronisation of what arrived in the meantime.
7. Repointing devices and systems from the list made earlier.
8. The old server stays switched on for a few more weeks. Do not decommission it immediately.

Point eight is cheap and rescues many situations: through the first weeks it regularly turns out that something else was still hanging off it.

The traps that cost most

Sender addresses in external systems. After the migration they have to be re-authenticated — otherwise messages from the invoicing system start landing in spam. A good moment to sort out SPF, DKIM and DMARC, since they have to be touched anyway.

Shared mailboxes and their permissions. Who has access to which, who may send “on behalf of”. This is rarely documented and always noticed on day one after the migration.

Calendars and rooms. Resources, recurring meetings, permissions to managers’ calendars. They travel unevenly and it is worth checking before rather than after.

Legacy protocols. If some device can only send using old authentication, it will collide with the new environment’s defaults. Better to decide before the migration whether it gets an exception or is repointed another way.

Licences bought “to be safe”. Count the real number needed only after listing the mailboxes — some of them are shared mailboxes, which need no licence.

How long it takes

For a company of a dozen or so people: preparation and inventory is one day, synchronisation runs in the background for a day or two, the switch itself is a few hours on a Friday afternoon, and tidying up details spreads over the following week.

The largest item in that reckoning is not the migration but finding everything that was sending mail through the old server. Get that part right and the rest is predictable.