Migration
Email Migration Checklist: Plan, Cut Over and Validate
Moving email is high-risk and routinely botched — lost messages, broken calendars, surprise downtime. This checklist walks through a disciplined migration from pre-move audit to post-cutover validation, so the move is calm and nothing is lost.
An email migration moves your mailboxes, calendars, contacts and mail flow from one platform to another — for example, off legacy Exchange and onto Microsoft 365, between cloud providers, or to self-hosted mail. Done well, users barely notice. Done badly, it loses years of records and causes downtime at the worst moment.
The difference is almost entirely planning. This checklist breaks a migration into clear phases — audit, inventory, DNS, cutover and validation — with a tested rollback throughout. Whatever platforms you are moving between, the disciplined method is the same.
In short
The phases of a safe migration
A good migration is a sequence of deliberate steps, each verified before the next.
-
Audit before you move
Understand the source environment fully — mailboxes, data volumes, rules and every sender — before touching anything.
-
Inventory everything
List every mailbox, alias, shared resource, forwarding rule and third-party sender so nothing is forgotten.
-
Plan DNS and cutover
Treat MX, SPF, DKIM and DMARC as a planned, timed cutover — not an afterthought done in a hurry.
-
Keep a tested rollback
Leave the old system available and proven until the new one is validated, so you always have a way back.
-
Validate after go-live
Confirm data integrity, send-and-receive, deliverability and authentication before you declare success.
Phase 1: Pre-migration audit
Before anything moves, understand exactly what you are migrating. A thorough audit prevents the nasty surprises that derail migrations halfway through.
- Document the source platform, versions and any quirks or customisations.
- Measure data volumes per mailbox so you can estimate migration time and plan windows.
- Record current DNS — MX, SPF, DKIM, DMARC and any custom records.
- Identify every third-party tool that sends as your domain or integrates with mail.
- Note compliance or retention requirements that affect how data must be handled.
The audit is also where you decide the destination honestly. If you are not certain Microsoft 365, Google Workspace or self-hosted is right, settle that first — migrating twice is far more costly than choosing well once.
Phase 2: Mailbox and resource inventory
A complete inventory is what stops things being left behind. The items that get forgotten are usually the shared and automated ones, precisely because no single person owns them.
- Every user mailbox, with its size and any delegated access.
- Aliases and secondary addresses attached to each user.
- Shared mailboxes, distribution lists and group addresses.
- Calendars, contacts and any shared resources such as rooms or equipment.
- Forwarding rules and filters, including hidden ones that may indicate compromise.
- Service and application accounts that send mail — monitoring, scanners, line-of-business apps.
Cross-check the inventory against the audit. Anything that sends or receives mail, or holds data, needs a decision: migrate it, recreate it, or retire it deliberately.
Phase 3: Prepare the destination and DNS
Set up the new environment and get authentication right before cutover, so that the moment mail starts flowing it is already trusted and deliverable.
- Provision users, shared mailboxes, groups and resources on the destination.
- Configure SPF, DKIM and DMARC for the new platform — including every third-party sender.
- Lower DNS TTLs ahead of the cutover so changes propagate quickly when you make them.
- Plan the MX switch as a specific, timed event with a clear go/no-go decision.
Get authentication ready early
A frequent post-migration problem is mail going to spam because DKIM was never enabled on the new platform or SPF was not updated for the new sending source. Preparing authentication before cutover, and verifying it, avoids starting life on the new platform with a deliverability problem.
Phase 4: Migrate data and cut over
With preparation done, you move the mailbox data and switch mail flow. The order and the rollback are what keep this calm.
- Migrate mailbox data with verification, confirming message and folder counts match on both sides.
- Run a final delta sync to catch mail that arrived during the migration.
- Switch MX records at the planned time to route new mail to the destination.
- Keep the source system live and reachable as a tested rollback until the move is proven.
- Communicate with users about the change and what to expect during the window.
Our commitment on a managed migration is zero data loss and no surprise downtime, backed by a tested rollback — never a fingers-crossed cutover.
Phase 5: Validate and decommission
The migration is not finished when mail flows — it is finished when you have proven everything works and only then retire the old system.
- Verify data integrity — spot-check mailboxes, calendars and contacts against the source.
- Test sending and receiving, internally and externally, from several accounts.
- Check inbox placement and confirm SPF, DKIM and DMARC pass for the new platform.
- Confirm shared mailboxes, distribution lists and application senders all work.
- Review the queue and logs for errors during the first days on the new platform.
- Only once everything is validated, decommission the source system.
Leaving validation until "later" is how problems slip through. Treat it as a defined phase with sign-off, not an assumption.
Avoid these
Common migration mistakes
Most migration disasters trace back to these avoidable errors.
-
No tested rollback
Decommissioning or breaking the source before the new platform is proven removes your safety net at the riskiest moment.
-
Forgetting authentication on the new platform
Not updating SPF or enabling DKIM for the destination means starting life on it with mail going to spam.
-
Skipping the shared and service accounts
Shared mailboxes, distribution lists and application senders are easy to forget because no one person owns them — and their loss is noticed immediately.
-
Not lowering DNS TTLs first
High TTLs mean the MX cutover propagates slowly, stretching the window where mail can split between old and new.
-
Declaring success too early
Skipping a proper validation phase lets data-integrity and deliverability problems surface days later, after the rollback is gone.
When to call a specialist
When to get expert help
Migration is high-stakes and one-shot. These are the cases where expert hands are well worth it.
-
The migration is business-critical
When losing mail or downtime is unacceptable, a planned migration with a tested rollback removes the risk you cannot afford to take.
-
You are leaving legacy Exchange
Older or hybrid environments have quirks that catch the unwary. Experience turns a fraught move into a routine one.
-
You manage many senders
Getting authentication right for the new platform across every third-party sender is exactly where post-migration deliverability problems start.
-
You have had a migration go wrong before
A previous bad experience is a strong reason to hand the next one to people who do migrations for a living.
A note on honesty
Need it handled?
Related Mailoza services
We own the migration end to end and keep the new platform healthy afterwards.
Keep reading
Related guides
A few more plain-English guides that connect to this one.
-
Microsoft 365 Email Security
Configure security correctly when migrating into a Microsoft 365 tenant.
-
Google Workspace Email Admin
DNS, deliverability and migration essentials for Google Workspace.
-
SPF, DKIM and DMARC Explained Simply
Get authentication right on the new platform so mail does not start out in spam.
Questions
Frequently asked questions
How do I migrate email without losing messages?
Audit and inventory the source fully, migrate mailbox data with verification so counts match on both sides, run a final delta sync to catch mail that arrived mid-migration, and keep the source live as a tested rollback until the new platform is validated. The verification and rollback are what protect your data.
How long does an email migration take?
It depends mostly on data volume and the number of mailboxes. The mailbox-data transfer is the slow part and can run in the background; the cutover itself is a short, planned window. A pre-migration audit measures the data so the timeline is realistic rather than guessed.
What causes downtime during a migration?
Usually a rushed or unplanned MX cutover, or high DNS TTLs that make the switch propagate slowly. Lowering TTLs in advance and planning the cutover as a timed event with a go/no-go decision keeps the window short and predictable.
Why does mail go to spam after a migration?
Almost always because authentication was not prepared for the new platform — DKIM left disabled, SPF not updated for the new sending source, or DMARC not aligned. Configuring and verifying SPF, DKIM and DMARC before cutover avoids starting out with a deliverability problem.
What is the most commonly forgotten item in a migration?
Shared mailboxes, distribution lists and application or service accounts that send mail. Because no single user owns them, they are easy to miss in the inventory — and their absence is noticed immediately after cutover.
Do I need a rollback plan?
Yes, always. A tested rollback means keeping the source system live and reachable until the new platform is fully validated. It is your safety net at the riskiest moment, and it is exactly what distinguishes a disciplined migration from a fingers-crossed one.