NevTan Mail is secure, ad-free business email on your own custom domain, with a built-in calendar, meetings, and admin controls. Migrating email to it — or to any provider — is a high-stakes operation. A single misstep can mean lost messages, broken authentication, or days of mail landing in spam folders you cannot see into.

The good news is that migration failures are rarely exotic. The same five mistakes account for the overwhelming majority of them, and every one is avoidable with planning rather than expertise. This guide walks through each mistake, why it breaks things, and exactly what to do instead.

The most common email migration mistakes are skipping the mailbox audit, forgetting DNS records (SPF, DKIM, DMARC), ignoring mailbox size and storage limits, not communicating with your team, and shutting down the old server too early. Avoid them by auditing first, verifying DNS before you cut over the MX record, migrating in phases, and keeping the old provider live for at least 30 days as a rollback path.

What You Need Before Starting

A successful migration is mostly preparation. Before you change a single setting, make sure you have:

• Administrative access to your current email provider, your domain registrar, and your DNS host. These are often three different logins at three different companies, and discovering you lack one of them mid-cutover is a bad afternoon.

• A full inventory of every mailbox, alias, shared mailbox, and distribution list.

• App-specific passwords for each mailbox you plan to migrate, if your current provider has two-factor authentication enabled. Standard login credentials will not work for an IMAP transfer.

• A decision on your target provider and a clear understanding of its migration tooling. NevTan Mail, for example, imports existing mail from Google, Yahoo, or Zoho over IMAP using an app password you generate at your current provider — so you keep your history when you switch.

If you are setting up a professional address for the first time rather than moving an existing one, start with our guide to business email on your own domain and come back here when you have a domain ready.

Step-by-Step: How to Migrate Without Losing Mail

Step 1: Audit Your Current Email Environment

Document every mailbox, shared mailbox, alias, and distribution group in your organization before you move anything. A 25-person business and a 500-person business fail migrations for the same reason: nobody wrote down what existed beforehand.

Record three things per user: the address, the mailbox size, and any forwarding or filtering rules they have configured. Forwarding rules are the quiet killer here — a rule that silently copies mail to a personal address will keep working after migration and nobody will notice for months.

This audit is also your cleanup opportunity. Most organizations find that a meaningful share of their mailboxes belong to former employees or long-dead projects. Archive those instead of migrating them; you will move less data and pay for fewer mailboxes.

💡 Pro Tip: Use your current provider's export tools to pull a CSV of all users and their mailbox sizes. That single file gives you your total data volume, your largest mailbox, and your transfer time estimate in one go.

Step 2: Prepare Your DNS Records (SPF, DKIM, DMARC)

Email authentication is not optional. SPF, DKIM, and DMARC are DNS records that tell receiving servers your mail is legitimate, and a migration invalidates all three at once if you are not careful.

• SPF must be updated to authorize your new provider's sending infrastructure. Critically, it must also still cover every other system that sends on your behalf — your CRM, your invoicing tool, your marketing platform. This is where the distinction between transactional and marketing email matters, because those often run through separate services that each need SPF authorization.

• DKIM requires generating a new key at your new provider and publishing it as a TXT record. The old provider's key does not carry over.

• DMARC tells receiving servers what to do with mail that fails the first two checks.

Getting this wrong is the single fastest way to destroy your deliverability, because the failure is invisible from your side — your mail sends successfully and quietly lands in spam. Our guide to why business emails land in spam and how domain authentication fixes it covers each record in depth, and NevTan Mail walks you through guided SPF, DKIM, and DMARC verification during domain setup so you are not composing DNS records by hand.

💡 Pro Tip: Publish a DMARC policy in monitoring mode (p=none) a few weeks before the migration. You will get reports showing every source sending mail as your domain — including the ones you forgot about — without breaking delivery for any of them.

Step 3: Choose and Prepare Your Migration Method

Most provider-to-provider migrations run over IMAP, the standard protocol for synchronizing mail between servers. It is supported essentially everywhere and it moves folders, not just the inbox — sent items, drafts, and custom folders come across too. If protocols are unfamiliar territory, our breakdown of IMAP vs SMTP vs API explains which does what.

The practical work is credential preparation. IMAP migration authenticates as each user, which means:

• Generate app-specific passwords at your current provider for every mailbox. With two-factor authentication enabled, normal passwords will simply fail. In Google Workspace these live under App passwords in account security; Microsoft 365 has an equivalent.

• Store them properly. You are about to be holding credentials for your entire organization in one place. Use a password manager with access controls, not a spreadsheet in a shared drive — the risks are the same ones covered in our guide to email security and phishing protection.

• Revoke them afterwards. App passwords do not expire on their own. Retiring them once the migration is verified closes the door behind you.

Transfer speed depends on mailbox size, message count, and how aggressively your old provider rate-limits IMAP connections. Plan for hours rather than minutes per large mailbox, and expect the first sync to be the slow one.

💡 For very large mailboxes, consider a migration tool that supports delta sync. You run an initial bulk transfer while everyone keeps working, then a final incremental sync at cutover to catch anything that arrived in the meantime.

Step 4: Check Storage Limits Before You Transfer

This is the mistake that turns a smooth migration into a stalled one halfway through. Every provider has storage allocations, and a mailbox that exceeds its destination allocation will fail — usually after transferring most of the way, wasting hours.

Compare your audit's mailbox sizes against your new plan before you start. If several users are carrying a decade of attachments, you have three options: increase their storage allocation, archive historical mail to separate storage before migrating, or migrate a limited window (the last 12 or 24 months) and keep the archive elsewhere.

Pricing models vary considerably here, so check the specifics. NevTan Mail's pricing includes up to 10 mailboxes with 1 GB each free, with additional storage charged per GB per mailbox per year — which makes it straightforward to size correctly upfront, but does mean a 40 GB inbox is a decision you make deliberately rather than discover mid-transfer.

Step 5: Execute in Phases

Do not migrate your entire company in one night. A phased rollout limits the blast radius of any single failure and lets you fix your process before it affects everyone.

Start with a pilot group of three to five technically comfortable users. Monitor them for 24 to 48 hours and check specifically for missing folders, broken attachments, calendar events that did not carry across, and mobile devices that will not re-authenticate. Once the pilot is stable, move the rest of the team in batches of 10 to 20.

The pilot is not just a technical test. It tells you which parts of your user instructions were unclear, which is worth more than any checklist you write in advance.

💡 Pro Tip: Schedule batches during off-peak hours. With users across time zones this gets awkward, but a batch that runs while people are actively working generates support tickets that a weekend batch never would.

Step 6: Verify, Communicate, and Decommission

After each batch, verify mail flow properly rather than assuming it works. Send test messages in both directions with an external account. Check that calendar invitations are accepted and appear correctly. Confirm mobile sync. Verify that mail sent from the new system passes SPF and DKIM — most webmail clients will show authentication results in the message headers.

Communication matters as much as the technical work. Send each group a short, jargon-free note before their migration explaining what will happen, when, and what they need to do on their end. Send a second note afterwards confirming completion and where to get help.

Then leave the old server running for at least 30 days. This is your safety net. When someone discovers they are missing a critical thread from three years ago, you want that to be a five-minute retrieval rather than a backup restoration.

💡 Pro Tip: Set an automatic reply on the old system for the first week or two, letting any stragglers know you have moved. Our guide to out-of-office automation covers how to write auto-replies that are genuinely useful rather than noise.

A Realistic Example

Consider a 40-person consulting firm moving from an existing provider to NevTan Mail.

Their IT lead starts with the audit: 40 mailboxes, and a wide spread of sizes with a handful of long-tenured staff carrying far more mail than anyone else. Two of those exceed the storage she plans to allocate, so she archives everything older than three years to separate storage before migrating — which also removes the largest risk of a mid-transfer failure.

Next, DNS. She updates SPF to authorize the new provider while preserving the entries for the firm's CRM and invoicing tool, generates and publishes a new DKIM key, and sets DMARC to p=none three weeks ahead so she can see the reports before anything changes.

She generates app passwords for each mailbox, stores them in the company password manager, and runs a pilot with four users on a Friday afternoon. By Monday the pilot is clean apart from two people needing to re-add the account on their phones — which she folds into the instructions for the next batch. The remaining 36 users move in three batches over two days.

The old provider stays active for 45 days. In that window she retrieves a small number of messages that users could not find in the new system. Total downtime: zero.

Nothing in that sequence is technically advanced. The phased approach and the overlap period did the work.

How to Choose Your Migration Strategy

The most important variable is not the tool. A well-planned migration with a basic tool beats a poorly planned one with an expensive tool, every time. If cost is a factor in choosing your destination provider, our cheap business email guide for startups compares what you actually get at different price points.

Why These Mistakes Break Things

Email is not a single database you can copy. It is a collection of protocols (SMTP, IMAP, POP3) and authentication standards (SPF, DKIM, DMARC), coordinated through DNS records that the entire internet reads independently.

When you migrate, you are re-pointing the world to a new server. DNS propagation is not instantaneous — MX record changes typically take effect within hours but can take considerably longer to reach every resolver globally. Change your MX record before the new mailboxes exist and inbound mail has nowhere to land. Leave SPF pointing at your old provider and receiving servers see your new mail as a spoofing attempt.

That last failure mode is the dangerous one, because it is silent. Your mail sends. Your team sees no error. Meanwhile a portion of it is being filed as spam or rejected at the gateway, and you find out when a customer says they never got your quote. This is exactly the pattern described in our guide to why emails go to spam and how to fix it, and a migration is the most likely moment for a business to trigger it.

The transfer itself carries a separate concern: you are moving your organization's entire correspondence history across the internet. Ensure the connection is encrypted in transit — see email encryption for business for what to look for, and note that NevTan Mail encrypts all traffic between your browser and the service with TLS.

The 5 Mistakes, Summarized

1. Skipping the mailbox audit. You cannot plan a migration around data you have not counted. This is what produces "missing" mailboxes and forgotten shared folders after the fact.

2. Forgetting to update SPF and DKIM. The fastest route to the spam folder. Your new provider must be authorized in SPF, and a new DKIM key must be published — the old one does not transfer.

3. Ignoring mailbox size and storage limits. Oversized mailboxes fail late in the transfer, after you have already spent the time. Compare sizes against your new plan before you begin.

4. Turning off the old server too soon. The old system is your rollback path. Decommissioning it 48 hours after cutover leaves you with no recovery option. Keep it for 30 days minimum.

5. Poor user communication. People panic when their email changes without warning, and panicked users create their own workarounds. Clear instructions before and after each batch prevent most support tickets.

Frequently Asked Questions

How long does an email migration typically take? It depends on data volume, message count, and how heavily your old provider rate-limits transfers. A small business with 20 mailboxes can often complete in 24 to 48 hours; a large organization with terabytes of mail may need a week or more. The initial bulk transfer is the slow part — a final delta sync to catch new messages is usually much faster.

Can I migrate to NevTan Mail without downtime? Yes, if you sequence it correctly. Keep your old provider active throughout, transfer the data in the background while people continue working normally, verify the results, and only then update your MX records. A phased rollout further reduces the risk of a company-wide disruption. NevTan Mail supports importing existing mail from Google, Yahoo, or Zoho over IMAP.

How does IMAP migration actually work? The migration tool connects to your old mail server as each user and copies messages, folders, and metadata to the new mailbox. Because it authenticates per mailbox, you need credentials for each one — and with two-factor authentication enabled, that means app-specific passwords rather than normal login passwords.

Do I need to update my SPF and DKIM records? Yes, without exception. If you do not, your mail will fail authentication checks and land in spam or be rejected outright. Your new provider supplies the exact values to publish. A DMARC policy on top of these gives you visibility into whether authentication is passing.

What happens to my old emails after I migrate? They are copied, not moved — nothing is deleted from the old server unless you delete it yourself. Keeping the old account active for at least 30 days after cutover means anything missed during transfer is still recoverable.

How do I migrate my calendar and contacts? Calendar and contact data are handled separately from mail and are the most commonly forgotten part of a migration. Verify both during your pilot phase rather than assuming they came across. NevTan Mail syncs meetings with your own Google Calendar, and keeps tasks, notes, and calendar alongside the inbox once you are set up.

What should I do if emails are missing after migration? Check the old server first — if it is still live, you can export the missing items and import them. A delta sync will also identify and copy anything the initial transfer skipped. If the old server is already decommissioned, you are into backup restoration, which is precisely why the 30-day overlap exists.

Should I migrate everything, or just recent mail? That depends on your storage allocation and any compliance obligations. Migrating a recent window (12 to 24 months) and archiving the rest separately is a reasonable approach for most businesses, and it substantially shortens the transfer.

Conclusion

Email migration has a reputation for being a nightmare, but the failures are predictable. Audit before you move. Fix DNS before you cut over. Check storage limits before you transfer. Tell your team what is happening. Keep the old system as a safety net.

NevTan Mail is built to make each of those easier. Domain setup is guided through SPF, DKIM, and DMARC verification rather than left to you and a DNS console. Existing mail imports from Google, Yahoo, or Zoho over IMAP. Every connection is TLS-encrypted, role-based admin controls determine who can manage domains and billing, and there are no ads and no data selling on any plan. Calendar and meetings are built in, so you are moving to a workspace rather than just a mail server.

For a full picture of the platform before you commit, read what NevTan Mail is and how it works, see why teams are moving to modern webmail, or browse everything on the NevTan Mail blog.

Ready to start? Set up your domain with NevTan Mail and plan your migration properly — your future self will be glad you did.