Email migration copies mailboxes, folders, contacts, and calendar data from an old provider to a new one over IMAP, Exchange Web Services, or a provider-specific API. Done properly it runs in five phases — audit, prepare, migrate in batches, verify, cut over — with the bulk of the data moving before you change MX records, so there is no downtime. Budget several days for a mid-sized team, run a pilot batch first, and keep the old system live for at least 30 days afterwards.
Before anything else: check what import methods your destination provider actually supports. This constrains every other decision and is the step most guides leave until too late.
Start Here: What Can Your Destination Accept?
Most migration guides open with source auditing. That is the wrong order, because the destination determines what is possible.
A migration tool needs something to connect to. If your new provider accepts IMAP imports from a specific list of services, then a tool built around Exchange Web Services has nowhere to deliver, no matter how fast it is. Discovering this after you have bought licences is an expensive way to learn it.
Ask your destination provider three questions before planning anything else:
Which import methods are supported? IMAP, EWS, a provider API, or a built-in migration tool?
Which source platforms are supported? Some providers support a named list rather than any IMAP server.
Are calendar and contacts included, or mail only?
NevTan Mail imports existing mail over IMAP using an app password you generate at your current provider, with Google, Yahoo, and Zoho as the documented sources. There is a step-by-step walkthrough for migrating from Gmail.
If your source is not on your destination's supported list, you have three options: export to a standard format and import separately, use a third-party tool that can write to your destination, or stage the migration through an intermediate platform. All are workable. All need to be planned for rather than discovered.
What You Need Before Starting
Admin credentials for both systems. Source and destination.
App passwords at the source, if it has two-factor authentication enabled — standard credentials will not authenticate an IMAP connection.
A full mailbox inventory: user count, storage per mailbox, and every shared or resource mailbox.
DNS access to update MX, SPF, DKIM, and DMARC records.
A migration window, ideally a weekend, communicated at least a week ahead.
A pilot group of three to five users, including one heavy and one light mailbox.
A source backup before you touch anything.
Document current client configurations too. For what a destination platform should offer, see what NevTan Mail includes end to end.
Step 1: Audit Your Current Environment
Export a complete mailbox list from your current provider. Microsoft 365 admins can run Get-Mailbox -ResultSize Unlimited in PowerShell; Google Workspace offers an Admin console export; generic IMAP servers can be queried directly.
Record total data volume, since it drives your timeline more than user count does.
Flag the special cases, because these are what break bulk migrations: distribution lists, aliases, shared mailboxes, public folders, and any unusually large mailboxes. Note mailboxes belonging to departed staff that must be retained for compliance.
Use the audit as a cleanup opportunity. Most organizations find a meaningful share of mailboxes are stale. Archiving those before migrating means less data to move and fewer mailboxes to pay for.
💡 Pro Tip: Build the audit as a spreadsheet with username, mailbox size, last login, and special-case flags. It becomes your migration checklist, your batch plan, and your rollback reference in one artifact.
Step 2: Choose Your Migration Method
Three broad approaches, constrained by what your destination accepts:
Method | Works with | Trade-off |
|---|---|---|
IMAP | Almost any source and destination | Universal but slower; does not carry calendar or contacts |
Native provider tools | Specific supported platform pairs | Fast and usually free, but only between supported platforms |
Third-party migration tools | Broad source and destination support | Fastest and most granular, at a per-user cost |
On IMAP's limitation: it treats mail as messages in folders. Calendar events, contacts, and client-side rules are not part of what it moves. If those matter, plan for them separately — this is the single most overlooked part of a migration, and people notice within hours of cutover.
On transfer speeds: these vary enormously with mailbox size, message count, and how aggressively the source provider rate-limits connections. Rather than trusting any published figure, measure it yourself during the pilot. Your pilot throughput is the only number that will predict your actual migration.
On tooling cost: third-party tools generally charge per user, and for a mid-sized migration the cost is usually justified by the time saved. Confirm current pricing and — critically — confirm the tool supports your destination before purchasing.
Step 3: Prepare the Destination
Create every account before migrating any data. Match source to destination mailboxes by primary email address.
Set up aliases so mail to old address variations still arrives. NevTan Mail includes unlimited aliases and groups, so this costs nothing — see email aliases explained for how to structure them.
Configure SPF, DKIM, and DMARC on the destination — but do not touch MX yet. This is the key sequencing insight. Publishing authentication records early lets you test outbound mail from the new system while inbound still flows to the old one. NevTan Mail's guided setup generates and verifies each record.
Publish DMARC at p=none now so the observation window runs in parallel with the migration. You will need two to four weeks of reports before tightening, and starting now means it is done when the migration is. See domain authentication and why business emails land in spam.
Verify every mapping with a test message. One mismatched address can deliver an entire mailbox to the wrong person, and that is not recoverable by apology.
💡 Pro Tip: Decide your naming convention before creating a single account. Changing it later means updating signatures, invoices, business cards, and every third-party tool that knows your addresses.
Step 4: Migrate in Batches
Never migrate everyone at once.
Pilot first with three to five users, deliberately including one very large mailbox and one small one. Measure actual throughput and note every error. This tells you what the full migration will cost in time, which no estimate can.
Then batch in groups of 10 to 25, running overnight or in low-traffic windows.
Use incremental sync. Run a full initial pass, then subsequent passes that capture only what arrived since. This is what makes zero-downtime migration possible: the bulk moves while everyone keeps working, leaving only a small delta for cutover.
Work through errors before the next batch. The common ones are authentication failures (usually app password problems), oversized attachments, and messages the source has corrupted. Each is fixable, but only if you address it rather than accumulating a backlog.
💡 Pro Tip: Schedule your final incremental sync shortly before cutover. The closer it runs to the MX change, the smaller the remaining delta.
Step 5: Cut Over, Verify, Decommission
Change MX records only after the data is verified. This is the moment new mail starts flowing to the new system.
DNS propagation typically takes effect within hours but can run to 48. During this period some mail will still reach the old server, which is exactly why it stays running. Mail sent during propagation is generally queued and retried by sending servers rather than lost.
Run a final incremental sync after propagation settles, to collect anything that landed on the old server during the transition.
Verify properly, not by assumption. For a sample of users: check inbox and folder message counts, confirm calendar events and contacts arrived, open a few attachments, and check that mail sent from the new system passes SPF and DKIM in the headers.
Keep the old system live for at least 30 days. Fourteen is the commonly cited figure and it is too short — the "I can't find an email from 2022" discovery typically happens weeks after cutover, not days.
Only then tighten DMARC to p=quarantine, and later p=reject, once your reports confirm every legitimate sender is authenticated.
💡 Pro Tip: Send a company-wide message from the new system on day one. It confirms outbound delivery works and signals clearly to everyone that the move is complete.
A Worked Example
A 75-person consulting firm moves to a new provider. Total mail volume is substantial, with a handful of long-tenured staff holding far more than everyone else.
Days 1–2: Audit and prepare. They inventory all 75 mailboxes and find two oversized ones that exceed their planned storage tier, so they archive mail older than three years before migrating — removing the most likely cause of a mid-transfer failure. They create accounts, configure aliases for two shared functions and three internal distribution groups, and publish SPF, DKIM, and DMARC at p=none on the destination without touching MX.
Day 3: Pilot. Five users, including the largest remaining mailbox. They measure throughput and use that figure — not a vendor estimate — to schedule the rest.
Days 4–6: Batches. The remaining 70 users move in overnight batches. Two mailboxes fail on the first pass due to oversized attachments; both succeed on retry after archiving.
Day 7: Cutover. MX changes late on a Friday evening. Propagation completes within a couple of hours. A final incremental sync collects messages that arrived on the old server during the window. By Saturday morning everyone has their history.
Days 8–37: Safety net. The old system stays read-only for 30 days. During that period they retrieve a small number of messages users could not find. DMARC moves to enforcement once reports come back clean.
On the destination cost: at NevTan Mail's per-mailbox annual pricing, 75 mailboxes run between $75 and $375 for the year depending on the storage tier — against per-seat providers charging $72 and up per user annually. Compare current pricing for your own configuration.
Choosing Your Approach
Your situation | Approach |
|---|---|
Under 25 users, IMAP source | Native or built-in IMAP migration. Low cost, manageable complexity |
25–250 users | Third-party tool if your destination supports one; otherwise staged IMAP batches |
250+ or mixed sources | Enterprise migration platform with dedicated support; plan a multi-week project |
Regulated industries | Prioritize audit logging, encryption in transit, and preservation of retention and legal hold |
If your team is small and technically confident, a DIY migration is realistic. If you have no IT staff, budget for a managed service — the cost is usually less than the cost of a migration that goes wrong.
How It Works Technically
Migration establishes a connection between two mail systems and copies message data over a standard protocol.
IMAP is universal and moves messages and folder structures, including sent items, drafts, and custom folders. It does not carry calendar events, contacts, or rules.
Exchange Web Services and Microsoft Graph are Microsoft-specific and preserve full mailbox metadata including calendars and contacts — but both ends must support them.
The three-phase sync model is what enables zero downtime: an initial sync moving the bulk, incremental syncs capturing changes, and a final sync during cutover handling the remaining delta.
Verification works on message counts and folder structure comparison between source and destination. Expect a small number of items not to transfer cleanly — typically corrupted source messages or attachments exceeding size limits — and check the failure report rather than assuming a clean run.
Security during migration matters and is easy to neglect. You will be handling credentials for every mailbox in your organization. Keep transfers encrypted in transit, store credentials in a password manager rather than a configuration file or spreadsheet, and revoke every app password once the migration is verified — they do not expire on their own. See email security and phishing protection.
Common Mistakes
1. Not confirming what the destination accepts. Planning a migration around a tool your new provider cannot receive from is the most expensive mistake available, and it happens before anything technical starts.
2. Migrating without a source backup. If something fails mid-way with no snapshot, you are exposed.
3. Changing MX records too early. New mail arrives at the new server while historical mail is still on the old one, producing a split inbox and a confused team.
4. Forgetting calendar and contacts. IMAP does not move them. Users notice within hours.
5. Skipping the pilot. It is the only reliable way to learn your real throughput and error patterns.
6. Decommissioning too fast. Thirty days minimum. The old system is both your rollback path and your archive of last resort.
7. Not telling users. People whose mail client suddenly demands a password will assume they have been phished — which, credit to them, is the right instinct.
Frequently Asked Questions
How long does email migration take? A mid-sized migration typically runs several days from audit to cutover, with the data transfer itself taking one to three days depending on volume and how the source rate-limits connections. Cutover is a short window. Larger organizations should plan in weeks. Your pilot batch is the only reliable predictor.
Will I lose email during migration? Not if you sequence it correctly. The transfer copies rather than moves — nothing is deleted from the source. Incremental syncs catch what arrives during the process, and keeping the old system live for 30 days covers anything missed. Loss happens when people skip the final sync or change MX prematurely.
Can I migrate without downtime? Yes. The bulk of the data moves while everyone continues working on the old system. The only transition point is the MX change, and mail sent during propagation is queued and retried rather than dropped.
What happens to calendar and contacts? It depends on the protocol. IMAP does not move them; EWS and Graph do. If your path is IMAP, plan calendar and contact migration separately and verify both during the pilot rather than assuming.
Do I need to change my email address? No, provided you own the domain. Addresses stay the same — you repoint MX records and everything continues working. This is the practical argument for being on your own domain in the first place.
How much does migration cost? Highly variable. DIY with built-in tools can be free. Third-party tools charge per user. Managed services cost more again. Add internal admin time, which is usually the larger figure. Confirm current pricing directly, as rates change.
Can I migrate from multiple providers at once? Yes, with a tool supporting multiple source protocols, or by running separate batches per source. Verify each batch independently before cutting over.
What if the migration fails midway? Revert MX to the old provider, which stays live throughout. Because the transfer copies rather than moves, your source mailboxes are untouched and you can retry.
Conclusion
Migration is a sequencing problem more than a technical one. Confirm what your destination accepts, audit and clean up the source, create accounts and publish authentication records without touching MX, pilot to learn your real throughput, batch the rest, verify before cutting over, and keep the old system for 30 days.
The step that rewards patience is DNS. Publish SPF, DKIM, and DMARC early so the observation window runs alongside the migration, and resist moving DMARC to enforcement until your reports confirm every legitimate sender.
NevTan Mail handles the destination side: business email on your own domain, IMAP import from Google, Yahoo, or Zoho, guided SPF, DKIM, and DMARC verification, unlimited aliases and groups, role-based admin controls, and calendar and meetings in the inbox — with 10 mailboxes at 5 GB each free forever, so you can build and test the destination structure before committing.
