Reviews
Part of Business email works as the master key to almost every other account
Business email migration: scope and sequence
A practical guide to business email migration: define what moves, test message and calendar details, sequence the cutover, and verify the new system.
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.
Even when message counts match, what can break is everything attached to the messages: the rules that sorted them, the permission that let an assistant open a director's calendar, and the recurring meeting that moved by an hour.
The read and unread state told someone what they had already dealt with. This page is about that second category, where 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.
Test These Before Promising a Date
- Read and unread state, and flags
- Server-side rules and filters
- Folder structure at depth
- Delegate and shared access
- Authentication records republished
- Calendar detail and exceptions
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 Internet Engineering Task Force (IETF) publishes standards for email authentication, including SPF, DKIM, and DMARC. These DNS records must be configured for your sending domain rather than copied as mailbox content; check them at cutover.
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 General Data Protection Regulation (GDPR) provides a right to data portability for data subjects when its conditions apply; it is not a general U.S. business-email export guarantee. The UK Information Commissioner's Office (ICO) guidance on research provisions and exemptions concerns a separate UK-specific context, not a general export standard.
Decide the scope before the schedule
The most useful decision in a mail migration is what stays behind.
What Stays Behind
Do you have a retention obligation for old mail?
Keep old mail where it is
Move a shorter window
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 old mail to be somewhere specific? For example, broker-dealers have recordkeeping duties under the Securities Exchange Act; whether a particular requirement applies, and where records must be kept, depends on the business and the records. Confirm applicable requirements with counsel or your organization's records lead. Does anyone actually reach back beyond a year, and how do you know? What does 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.
Migration Sequence
- Inventory first
- Build the destination completely
- Pre-seed the mail
- Cut over delivery
- Run a catch-up pass
- Keep old system readable one direction
- Close it down deliberately
- 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.
- 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.
- 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.
- Cut over delivery.The switch itself is quick. Everything before and after it is not.
- Run a catch-up passfor the mail that arrived at the old system after the pre-seed and before the switch.
- 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.
- Close it down deliberately, with an export retained somewhere you control.
Two rules for parallel running. Only one system can be the delivery destination at a time. Bridge them in a single direction. Otherwise, conversations split across two mailboxes and neither is complete.
Set an end date for the old system at the start. A system with no shutdown date never gets one.
What to tell people, and when
Migrations fail socially more often than technically.
What to Tell People
- Date and changes, twicea week ahead and the day before
- What they must do themselves
- Which items will not transfer
- One place to report problems, staffed three days
- Avoid Friday, month end, and deadline weeks
- Move a pilot group of heavy mail users first
Move a pilot group first. Pick people who use mail hard, not enthusiasts. The person with forty folders, six delegations, and a decade of rules will find every problem. One person finding them costs far less than everyone finding them.
The pilot also exposes the account administration decisions that are cheap to fix now and costly once everyone is live.
After the switch
The migration is not finished when the mail arrives. In the first two weeks, deliberately check:
First Two Weeks After Switch
- Every automated sender has sent something
- Shared and role addresses are being worked
- Calendar availability works internally and externally
- Filtered mail destination and release
- Anyone quietly still reading the old system
- Security controls actually apply to new accounts
- 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. For moves involving Microsoft Exchange Online or Google Workspace, compare available native migration options with third-party tools such as MigrationWiz by BitTitan, Google Workspace Migrate, and Quest On Demand Migration. Support depends on the source and destination, so verify the current product documentation and test the data types you need in a pilot. 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.
