Business email migration: how to switch without losing data

Every mail migration is sold as a copy operation. Messages go from one system to another, and when the count matches, the job is done.

The count always matches. What breaks is everything attached to the messages: the rules that sorted them, the permission that let an assistant open a director's calendar, the recurring meeting that moved by an hour, the read and unread state that told someone what they had already dealt with. This page is about that second category, because it is where the complaints come from and it is almost never in the plan.

What to take away

• Messages move. The structure around them frequently does not, and the gaps are predictable enough to plan for.
• Decide what you are not migrating before you start. Old mail left in place as a read-only archive is a legitimate answer.
• Run the two systems in parallel deliberately and in one direction only. Accidental parallelism is how mail goes missing.
• Move a small pilot group first, and pick people who use the system hard rather than people who are enthusiastic.

What rarely survives the copy

Test each of these on a real account before you promise anyone a date. Some will transfer perfectly, some will not, and which is which depends on the pair of systems involved rather than on any general rule.

Read and unread state, and flags. Everything arriving as unread turns a normal Monday into an unusable one for anyone with a large mailbox.

Server-side rules and filters. These often have to be rebuilt by hand. Ask people to screenshot theirs before the move, because after it they will not remember what they had.

Folder structure at depth. Deeply nested folders, folders with unusual characters in the name, and folders holding very large numbers of messages are the three that fail.

Delegate and shared access. Who can open whose mailbox, who can send on behalf of whom, and who manages whose calendar. This is permission data, not mail data, and it usually has to be recreated.

The authentication records that make your mail believable are a separate category again, and they have to be republished rather than copied. The reference description of how those records work together is the standards body's guide to trustworthy email, and a migration is the moment they are most often left half finished.

Calendar detail. Single meetings are fine. The problems are recurring series with individual exceptions, meetings whose organizer has left, room and equipment bookings, and attendee responses. Free and busy visibility across the boundary during the transition is worth testing early.

Contact groups and personal address books, as distinct from the company directory.

Signatures, automatic replies, and away messages, particularly on shared addresses where nobody owns them.

Anything stored locally. Archive files sitting on a laptop are invisible to any server-side migration and are frequently the only copy of something.

Very old or unusual items. Encrypted messages, calendar invitations from systems that no longer exist, items with enormous attachments, and messages with damaged structure will fail individually. Expect a failure list and plan who reads it.

It is worth asking the outgoing provider what their export actually contains before you rely on it. The standard applied when a person asks for their own data is a fair benchmark: the regulator's description of data portability is about receiving information in a usable form rather than merely receiving it.

Decide the scope before the schedule

The most useful decision in a mail migration is what stays behind.

Copying twenty years of mail for everyone is expensive, slow, and often pointless. The alternatives are genuinely reasonable: move the last one or two years and leave the rest reachable in a read-only archive, or move everything for a small number of people who need it and a shorter window for everyone else.

Ask three questions. Do you have a retention obligation that requires the old mail to be somewhere specific? Does anyone actually reach back beyond a year, and how do you know? And what does the old mail cost to keep where it is, versus to bring with you? A scope decision made honestly here changes the length of the project more than any technical choice, and it changes what you will pay under your new cost model.

Sequence, and what runs in parallel

The order below exists because each step depends on the previous one being finished.

1. Inventory first. Everything that sends as your domain, every system that reads a mailbox, every shared address and who works it, every delegation. The setup guide covers building this list, and a migration needs it more than a fresh installation does.
2. Build the destination completely. Accounts, groups, shared mailboxes, permissions, and policies all in place before any mail moves. Mail arriving at a mailbox that does not exist yet is the most common self-inflicted outage.
3. Pre-seed the mail. Copy the bulk of the archive while the old system is still live and still receiving. This is slow and can run for as long as it needs to.
4. Cut over delivery. The switch itself is quick. Everything before and after it is not.
5. Run a catch-up pass for the mail that arrived at the old system after the pre-seed and before the switch.
6. Keep the old system readable, in one direction, for a defined period. Forward from old to new, never both ways, and announce the date it will be turned off.
7. Close it down deliberately, with an export retained somewhere you control.

Two rules about parallel running. Only one system may be the delivery destination at a time, and any bridging between them must flow in a single direction, or you will split conversations across two mailboxes and neither will be complete. And set an end date for the old system at the start, because a system with no shutdown date never gets one.

What to tell people, and when

Migrations fail socially more often than technically.

• Tell people the date and what will change for them, in one short message, twice: a week ahead and the day before.
• Say explicitly what they must do themselves. Reconnecting a phone, re-entering a password, and rebuilding personal rules are user tasks whatever anyone hopes.
• Warn them about the specific things on the list above that you know will not transfer. Being told in advance that flags will not survive is an inconvenience. Discovering it is an incident.
• Give them one place to report problems, and staff it properly for the first three days.
• Do not cut over on a Friday, in a month end, or in the week before a deadline that matters to the business.

Move a pilot group first, chosen for how hard they use mail rather than for enthusiasm. The person with forty folders, six delegations, and a decade of rules will find every problem you have, and finding them with one person is much cheaper than finding them with everyone.

After the switch

The migration is not finished when the mail arrives. In the first two weeks, deliberately check:

• Whether every automated sender from the inventory has actually sent something since the change. Monthly and quarterly systems have not, and they need a forced test rather than a wait.
• Whether shared and role addresses are being worked, and by whom. These are the addresses nobody owns and therefore nobody notices.
• Whether calendar availability works both internally and with regular outside contacts.
• Where filtered mail is now going, and who can release it.
• Whether anyone is quietly still reading the old system because something did not move. Ask directly; people will not volunteer it.
• Whether the settings you meant to enforce actually apply to the new accounts, particularly the security controls that are easy to leave for later and then forget.

Finally, write down what went wrong. The next migration, whether it is your next provider or the next company you work for, is the same list of failures in a different order, and the notes are worth more than any vendor's checklist. That record is also the honest input to your next evaluation.

Common questions

How long should the old system stay reachable?

Long enough to cover your slowest recurring process, plus a margin. A quarter is a common answer for organizations with monthly cycles. What matters more than the length is that the end date is set at the beginning and announced.

Can we move everyone in one weekend?

Small organizations often can, and the risk is concentrated rather than reduced. Staged moves are slower and give you a chance to fix a problem before it reaches everyone. Choose deliberately rather than by default.

Do we need a migration tool or a specialist?

It depends on the volume, the number of delegations, and whether calendars matter. The honest test is whether you can afford to run the pilot twice. If a failed pilot would be an emergency rather than an inconvenience, buy help.

What about the mail people keep on their own machines?

Find it before the move, not after. Ask everyone directly whether they have archive files stored locally, then decide whether those get imported, kept as files, or left alone. Whatever you choose, choose it in advance; local archives are the single most common source of a data loss complaint months later.