Email Infrastructure Migration

What an email migration involves

Email migrations come in several forms: moving mailboxes between hosted suites or to your own server, moving sending from one platform to another, moving a self-hosted server to new hardware or a new provider, or consolidating several setups into one. Each involves data, DNS, authentication and, for sending, reputation.

The goal is simple to state: nobody loses mail, nothing breaks during the switch, and sending performs at least as well afterwards. Achieving it takes planning.

Migrations also tend to surface hidden dependencies: a printer that scans to email, a website form, an old integration sending invoices. Finding these before cutover is a large part of the work.

Common reasons to migrate

• Costs on a hosted platform no longer match your volume.
• An old server is unsupported, undocumented or unreliable.
• Your provider no longer suits your deliverability or data needs.
• Brands or teams on separate systems need consolidating.
• A hosting provider is being changed for reasons beyond email.

What needs to move

• Mailboxes and their contents, including folders, calendars and contacts where relevant.
• DNS records: MX, SPF, DKIM, DMARC, tracking, autodiscover.
• Authentication keys or new keys published with overlap.
• Subscriber lists with consent records, so you can show how each person opted in.
• Suppression lists: bounces, complaints and unsubscribes. Losing these is one of the most damaging migration mistakes.
• Templates, automations and integrations with your applications.
• Server configuration and databases for self-hosted platforms.

How we run a migration

1. Inventory: document everything the current setup does, including forgotten integrations.
2. Plan: agree a cutover date around your sending calendar, not ours, and a rollback plan.
3. Back up: take a verified full backup of the source, including databases that a file backup would miss.
4. Build and test the new environment in parallel.
5. Copy data with an initial sync, then a final sync at cutover.
6. Lower TTLs, switch DNS, and keep the old system receiving during an overlap period.
7. Warm up new sending IPs or domains gradually.
8. Verify mail flow, authentication and integrations, then decommission the old system only when you’re confident.

We communicate each step to your team in advance, including any changes staff need to make on their phones or mail clients.

Handling reputation deliberately

Domain reputation largely travels with your domain, but a new IP starts from zero regardless of your history. Moving a large volume to new IPs overnight looks to receivers like a new, unknown sender. We plan a warm-up where it’s needed, and sometimes run old and new systems side by side, shifting traffic gradually.

Planning for rollback

Every migration plan includes a way back. Until the old system is decommissioned, we keep it able to receive and, where relevant, send, and we record the original DNS values so they can be restored quickly. If testing after cutover shows a problem we can’t fix quickly, reverting is a planned step rather than an emergency.

• Original DNS records saved before any change.
• Old system kept running through the overlap period.
• Clear criteria for deciding when to roll back.
• A verified backup retained after decommissioning.

What affects timeline and cost

• Number of mailboxes and total data volume.
• Number of domains, platforms and integrations.
• Whether new IPs need warming up.
• Your sending calendar and any blackout periods.
• Condition and documentation of the source system.

Common migration mistakes

Leaving suppression lists behind. Switching MX with long TTLs still set. Decommissioning the old server before stragglers stop arriving. Forgetting a database that a file backup didn’t include. Sending full volume from new IPs on day one. Discovering a hidden integration after the old system is gone.

Related: DNS configuration, all email infrastructure services, the guide, and contact.

Frequently asked questions