Email Migration Guide: Move Without Losing a Thing

The last time I migrated a team off Gmail and onto a new platform, we lost three weeks of archived thread history that nobody noticed until a contract dispute six months later. That mistake cost more in lawyer hours than the entire year of the new email subscription. An email migration guide that actually covers the edge cases — that's what would have saved us.

TL;DR: What You Need to Know Before You Start

• Audit your existing mailbox before touching anything — labels, filters, and folder structures migrate differently across platforms
• Export a full backup first. Always. Even if your new provider claims automatic import.
• DNS propagation takes 24–72 hours; plan your cutover window accordingly
• Contacts, calendar data, and email filters are three separate exports — most people only grab the emails
• Test with one account before migrating a whole team
• Post-migration, run a 2-week parallel period where both systems receive mail if at all possible

Step 1: Audit Your Current Email Setup

Before you export a single file, spend two hours — minimum — documenting what you actually have. Open your current client and list every folder, every label, every filter rule, and every connected app or integration. Connected apps are the killer. Slack, Zapier, HubSpot, Calendly, your invoicing software — all of them are authenticated against your current email address. If you swap providers without updating those OAuth connections, they break silently.

Pull a list of all third-party apps with email access. In Gmail, that's under Security → Third-party apps with account access. In Outlook, check Connected apps under account settings. Write them down. Every one of those needs to be re-authenticated after migration.

1. Document folder/label structure with exact names
2. Export all active filter rules (Gmail: Settings → Filters and Blocked Addresses → Export)
3. Note total mailbox size (this affects how long the transfer takes)
4. List all connected third-party apps
5. Record your current DNS records: MX, SPF, DKIM, DMARC
6. Identify your oldest archived emails — some IMAP migrations only grab 12 months by default

Step 2: Back Up Everything Before You Touch a Setting

Non-negotiable. Export your full mailbox as an MBOX or PST file depending on your current provider. Gmail users: use Google Takeout and select only Mail — the full export runs faster. Outlook users: File → Open & Export → Import/Export → Export to a File. For large mailboxes over 25GB, expect the export to take several hours or even run overnight.

According to Barracuda Networks' 2025 Email Security Trends Report, 34% of organizations that reported data loss during email migrations had skipped or abbreviated the pre-migration backup process.

Barracuda Networks, Email Security Trends Report 2025

Store the backup in two places. Not one. An external drive plus cloud storage (not the same cloud you're migrating away from). Paranoid? Yes. Wrong? No.

Step 3: Choose Your Migration Method

There are three main paths, and each has real tradeoffs.

IMAP-to-IMAP Transfer

The most common method. Tools like imapsync (open source, runs locally) or commercial services like MigrationWiz connect to both accounts simultaneously and move messages folder by folder. IMAP transfers preserve read/unread status and folder structure but do not preserve sent timestamps accurately in all cases — messages often arrive with the migration date, not the original send date. That's a metadata problem that bites you during legal discovery or compliance audits.

PST/MBOX Import

Download your backup, upload it to the new provider. Slower, more manual, but you maintain better control over what gets moved and when. Most enterprise providers — Microsoft 365, Google Workspace — support bulk PST import through their admin portals. This method works well for historical archive migration where you're not trying to move active mail in real time.

Native Migration Tools

Both Google Workspace and Microsoft 365 have built-in migration consoles designed to pull from specific source platforms. The Google Workspace Migration for Microsoft Exchange (GWMME) tool is genuinely solid for Exchange-to-Workspace moves. Microsoft's Exchange Admin Center handles migrations from other Exchange environments natively. These purpose-built tools handle calendar and contacts migration in the same pass — which saves a lot of headaches.

Step 4: Migrate Contacts and Calendar Data Separately

Most people focus entirely on email and realize three days post-migration that their entire contacts list or shared team calendar didn't make it. Contacts export as a VCF or CSV. Calendar data exports as ICS files. These are separate exports, separate imports, and they need to be done deliberately.

1. Export contacts: Google → contacts.google.com → Export (VCF or CSV); Outlook → File → Open & Export → Import/Export
2. Export calendar: Google → calendar.google.com → Settings → Export; Outlook → File → Open & Export
3. Import contacts into new provider before migrating email (reduces bounce issues if you use contact-based filtering)
4. For shared team calendars, coordinate with all attendees — recurring events often need to be re-created manually
5. Verify calendar timezone settings in the new environment immediately after import

Step 5: Update DNS Records and MX Settings

This is the step most guides gloss over, and it's where migrations actually break. Your MX records tell the internet where to deliver mail for your domain. Changing them incorrectly, or too early, means incoming mail goes to the wrong server during the switchover window. The order matters.

1. Lower your MX record TTL to 300 seconds (5 minutes) at least 24 hours before migration — this makes DNS changes propagate faster when you flip
2. Set up MX records on the new provider but don't activate them yet
3. Complete the mailbox data migration
4. Update SPF record to include the new mail server
5. Add the new provider's DKIM key to your DNS
6. Switch the MX records to point to the new provider
7. Monitor mail flow for 48–72 hours before decommissioning old mailboxes
8. Update DMARC policy after confirming DKIM and SPF pass on the new provider

Skipping the DMARC update post-migration is one of the top reasons migrated domains end up flagged as spam sources within the first 30 days.

Postmark Email Deliverability Benchmark, 2026

What Happens to Your Email Filters During Migration?

Email filters do not migrate automatically between different providers — ever. This surprises people every single time. If you have 40 Gmail filters routing newsletters, client domains, and internal notifications to specific labels, none of that logic exists on your new platform. You rebuild it from scratch.

The audit you did in Step 1 pays off here. Export your Gmail filters as an XML file, then use that as a reference document to recreate the rules in your new environment. It's tedious. There's no shortcut. What you can do is treat migration as an opportunity to rationalize your filter setup — most people have filters that fire for senders they no longer communicate with.

This is where an AI-native email tool changes the math considerably. Icebox's smart classification engine handles the heavy lifting of email routing automatically — instead of manually recreating 40 filter rules, the AI learns your communication patterns and sorts incoming mail into the right categories within the first few days of use. Competitors like Superhuman and Spark Mail require the same manual filter rebuilding process as native Gmail or Outlook. It's a real differentiator if you're landing on a new platform and starting fresh.

Step 6: Run a Parallel Period Before Full Cutover

If your situation allows it — and for teams, it almost always does — keep the old system receiving and forwarding mail for at least two weeks after the DNS switch. Set up auto-forwarding from the old provider to the new one. This catches anything that missed the DNS propagation window and gives you a safety net for the first sprint.

For individual users migrating personal accounts, two weeks of parallel operation is still worth it. The friction cost is low; the protection is high.

Post-Migration Checklist

• Send a test email from an external address and confirm delivery
• Verify DKIM signature passes using MXToolbox or mail-tester.com
• Re-authenticate all connected third-party apps
• Recreate or import email signature in the new client
• Notify key contacts of any address changes if the domain changed
• Confirm mobile device mail apps are pointed to the new server settings
• Check spam folder on the new system for the first week — deliverability hiccups are common
• Archive or delete the old mailbox only after 30 days of stable operation

How Long Does an Email Migration Take?

A single user with a 5GB mailbox using IMAP transfer: two to four hours of active work, spread over two days to account for DNS propagation. A team of 50 migrating from Google Workspace to Microsoft 365 with calendar and contact data: plan for two to three weeks end-to-end, including the parallel period. An enterprise migration of 500+ users with compliance archiving requirements: typically three to six months with a dedicated migration project plan.

Those timelines assume no major surprises. Surprises that add time: oversized mailboxes that hit IMAP rate limits, accounts with corrupted PST files, domains with complex multi-server MX configurations, and any mailbox with over 10 years of email history (which tends to have orphaned folders and legacy encoding issues).

Choosing the Right Destination Platform

The migration process is roughly the same regardless of where you land, but the destination matters for what comes after. Microsoft 365 and Google Workspace are the enterprise defaults — mature ecosystems, extensive admin controls, and well-documented migration paths from most source platforms. Notion Mail is newer and worth evaluating if your team lives in Notion already, though its migration tooling as of Q3 2026 is still catching up. HEY has a deliberate anti-legacy-email philosophy that makes it genuinely difficult to import historical mail — that's a feature to them, a problem for anyone with compliance requirements.

If your main pain point is inbox overload rather than the underlying mail server, layering an AI assistant on top of wherever you land is worth evaluating independently of the migration decision. Icebox works on top of existing mail infrastructure — you don't need to change your MX records or redo DNS to use it — and its multilingual support (22 languages) makes it particularly useful for distributed international teams where the rest of the team is using a different primary language than your admin staff.

The One Thing Most Email Migration Guides Get Wrong

They treat migration as a one-time technical event. It's not. The technical move is maybe 30% of the work. The other 70% is behavioral: getting your team to actually use the new system the way it was designed, rebuilding your workflow triggers and automations, and training the AI or filter rules to match your actual communication patterns. I've watched three separate company migrations where the technical execution was flawless and adoption failed because nobody planned for the human side of the switch.

Build a 30-day post-migration adoption plan alongside your technical migration plan. Block time for filter rebuilding, signature setup, and connected-app re-authentication in the week immediately after cutover. Schedule a 30-day check-in to assess whether deliverability, productivity, and team satisfaction are where you expected them to be.

If you're moving to Icebox or evaluating it as an AI layer for your post-migration inbox, the blackhole and quarantine features are worth testing in that first 30-day window — that's when the junk mail that followed you from your old domain shows up in force, and having automated spam interception in place from day one saves real time. Start your free trial at icebox.cool and connect it to your newly migrated inbox before the noise catches up.