How to Migrate Business Email Without Losing Messages or Causing Downtime
An email migration is not just an MX-record change. Mailboxes contain business history; DNS controls new delivery; devices, applications and websites store old credentials; and cached routes can send mail to both systems during transition. A safe migration plans all of them.
1. Inventory users and dependencies
List active users, aliases, shared addresses, forwarding, groups, mailbox sizes, calendars, contacts, archives and delegates. Identify scanners, website forms, CRM tools, invoicing systems and applications that send through the old provider. Remove departed users only after retention obligations and business ownership are resolved.
2. Define success and responsibility
Set the cutover window, project owner, support contact, rollback criteria and acceptance tests. Decide which historical data will move and which will be archived. Notify users about password, device and interface changes without sending secrets by email.
3. Prepare the destination
Create and license mailboxes, aliases and shared workflows. Verify the domain using the destination provider’s record. Apply MFA and recovery controls. Configure retention, spam and mobile policies before importing real data.
4. Copy historical data first
Use the provider’s supported migration method—often IMAP for mail or a platform-specific tool for mail, calendars and contacts. Run an initial bulk copy while the old service remains live. Record failures by mailbox and retry safely. Google and Microsoft both document staged migration options; follow the source and destination limits.
5. Prepare DNS
Lower relevant TTLs sufficiently in advance. Document existing MX, SPF, DKIM, DMARC and verification records. Create the new provider’s DKIM keys. Plan SPF as one valid policy rather than two competing records. Start DMARC conservatively if authentication alignment has not been observed.
6. Cut over new mail
Change MX to the destination and update the sending authentication records exactly as documented. Do not change nameservers merely to change email unless the complete zone is being moved intentionally. Keep the old service accepting mail during the cache period.
7. Run a delta migration
After cutover, copy messages delivered to the old system since the initial pass. Some migrations need several deltas. Confirm counts and investigate errors rather than treating “completed” as proof every item moved.
8. Test real flows
- external sender to each representative mailbox;
- outbound mail to major external providers;
- replies, attachments and aliases;
- shared mailbox send-as and permissions;
- website forms, scanners and application mail;
- SPF, DKIM and DMARC results in received headers;
- mobile and desktop clients;
- password reset and business-critical notifications.
Avoid the dual-delivery trap
During DNS caching, some senders may still use old MX answers. That is why the old service remains active and a delta copy follows. Do not delete old mailboxes immediately. Equally, do not leave indefinite split delivery without monitoring; it creates fragmented histories and missed messages.
Aliases, mailboxes and shared inboxes
An alias is another address routed to a mailbox, not a separate archive or login. Shared addresses such as accounts@ may need a real shared mailbox with delegated access. Recreate behaviour, not just address strings. Read the alias and mailbox guide.
Calendars, contacts and delegates
IMAP moves messages, not necessarily calendars, contacts, tasks, room resources or delegation. Inventory each data type and use a platform-specific migration where required. Recreate sharing deliberately; copying permissions blindly can retain access for former staff.
Large mailboxes and throttling
Providers impose connection and transfer limits. Start large copies early, batch users and avoid aggressive retries that trigger throttling. Report progress by mailbox, bytes and errors. A successful sample does not prove a multi-user migration fits the window.
Rollback limits
Changing MX back does not merge mail already delivered to the new system. A rollback must explain how both sets are retained and reconciled. Preserve access to both providers and decide based on delivery integrity, not interface familiarity.
Protect deliverability
New sending infrastructure may have different authentication and reputation. Update SPF and DKIM, monitor DMARC, avoid sudden bulk campaigns and keep lists lawful and clean. The email deliverability guide covers diagnosis.
When to retire the old system
Wait until DNS caches have expired, final copies are complete, applications are changed, tests pass and users confirm access. Export required records, follow retention policy and cancel only after written approval. Keep migration logs without storing message content unnecessarily.
Migrate with Hoster
Compare Hoster business email plans by mailbox, alias and collaboration needs. For multiple users or a mail-critical cutover, contact Hoster with mailbox counts, source platform, sizes and required shared workflows before changing DNS.