Migrate email to 365: run a small pilot so mail is not missed

You have a weekend cutover on the calendar. Mailboxes, DNS, and a list of people who cannot lose a single invoice. Someone already asked if you can "just flip it tonight." That stuck feeling is common. Migrating email to Microsoft 365 is a sequence, not a switch. Pick the method from the source system, then prove it on a small group before you touch MX.

• Ask what you are leaving. Exchange on-premises, Gmail, IMAP, or another Microsoft 365 tenant each need a different path.
• Ask who must not be surprised. An executive mailbox and a 10GB mailbox belong in the pilot, not in the last batch.
• Ask when mail can still arrive on the old side. That is data drift. Preload old mail, then run a final delta sync.
• Ask when DNS actually changes. Lower the MX TTL days ahead. Do not discover a cached record on Sunday night.

If the plan still feels thin, stop guessing from a vendor PDF. Email Systems Scientist covers Microsoft 365 moves across NSW. Sydney offices can start with email help across Sydney. Central Coast sites can use email help on the Central Coast.

How do I migrate email to 365? Choose the method by source

The method you pick decides how much data survives and how much downtime the office absorbs. Microsoft's mailbox migration guidance lays out five broad paths. Each one trades speed against fidelity.

• Cutover migration: Moves all mailboxes at once. Fits a smaller organisation. Brings mail, calendar, and contacts in one pass when the source is Exchange.
• Staged migration: Moves mailboxes in batches over days or weeks. Suits a larger Exchange environment that needs to control the pace.
• Hybrid migration: Some mailboxes stay on-premises while others sit in Microsoft 365. Use it when you need coexistence, not a one-off flip.
• IMAP migration: Pulls mail from Gmail, an on-premises IMAP server, or another IMAP system. It will not bring calendars, contacts, tasks, or folder permissions.
• Cross-tenant migration: Moves content between two Microsoft 365 tenants. Common after a merger or a split. Identity mapping has to happen before any content moves.

Microsoft's mailbox migration guidance is the official map. It also spells out IMAP's limits. If speed matters most and the mailboxes are small, cutover usually wins. If coexistence or fidelity matters more, hybrid or staged is the safer bet. If you are leaving Gmail, assume you will patch calendars and contacts by hand, or with extra tooling.

If mail already lives in Microsoft 365 and Outlook itself is the problem, that is a different job. Start with Outlook not receiving emails. Copier scan-to-email after the move is also separate. That setup sits in scan to email 365.

What should be on your pre-migration checklist?

Most cutover headaches start as skipped homework, not as a bad click on the day. Work through this before you book a weekend.

1. Inventory every mailbox. Record size, litigation holds, retention, shared mailboxes, and any delegated or resource accounts. A mailbox on a legal hold behaves differently. It can fail quietly if you do not flag it.
2. Confirm tenant and licensing. Enough Microsoft 365 licences, allocated, not sitting in a quote. If you sync identities from an on-premises directory, Entra ID Connect needs to be healthy first.
3. Plan DNS and MX timing. Verify the domain in Microsoft 365 well before cutover. Drop the MX TTL to a low value, often 300 seconds, at least 24 to 48 hours before the switch.
4. Harden admin access. MFA on every administrative account. Recheck service account passwords. Confirm firewalls and connectors will not block migration traffic.

The migration window is a security risk, not only an operations one. Attackers watch tenant changes. Admin attention is split. Unusual sign-ins are easier to miss. Australian Cyber Security Centre advice on email security is blunt about that chaos. Treat the cutover weekend as a period of extra watch, not a period of extra hope.

Pro Tip: Reduce your MX TTL a full 48 hours before cutover, not the night before. Caches further up the chain do not always honour the new TTL immediately. You do not want to learn that on migration day.

How long does a mailbox move take, and how do you stop data drift?

Duration depends on mailbox size, item count, and how hard Microsoft throttles the connection. The sequence below is what keeps a move from turning into a scramble.

1. Run the pilot first. Choose five to ten representative users. Include at least one executive mailbox and one large mailbox, over 10GB, so you catch issues that only show up at scale.
2. Pre-stage historic mail. Start moving older mail days, or weeks, before cutover. Throttle it so it does not choke the network or trip Microsoft's rate limits.
3. Run a final delta sync. Freeze non-essential mailbox housekeeping. No bulk folder reshuffles. No mass rule changes. Then run an incremental pass for anything that arrived since the last copy.
4. Cut over MX records. Point MX at Microsoft 365 at a planned, low-traffic time, usually outside business hours.
5. Verify in four directions. Internal to internal, internal to external, external to internal, and a reply that leaves and comes back. If all four pass, mail flow is actually working.
6. Test Outlook and Autodiscover on at least one fresh machine that has never seen the old system.
7. Keep the old system live for 30 to 60 days as a fallback. Do not decommission on Monday morning.

Plan around throttling rather than fighting it. Assume roughly half the theoretical throughput. Watch error rates, not raw volume. That one change in expectation saves a lot of panic on migration weekend.

Data drift is the real threat. Mail arriving mid-move that a single-pass copy simply misses. Pre-staging plus a final delta sync exists for that reason. Speed is not the win. Completeness is.

Pro Tip: Ask any migration vendor for a throughput figure in gigabytes per hour based on your actual mailbox sizes, not a generic average. That number is what turns "a few days" into a date you can plan around.

Do you need third-party migration software?

Native Microsoft tools cover most straightforward moves. Some jobs still need extra software, or a specialist watching the batch.

• Cross-tenant moves with complex metadata. Folder permissions, categories, and custom properties often need dedicated tooling to survive the jump.
• Large archives. PST files, legacy on-premises archives, and public folders frequently exceed what native tools handle cleanly.
• Mixed sources. Gmail, IMAP, and Exchange into one tenant at the same time is orchestration, not three separate weekend jobs.

If you go down that path, ask about throttling strategy, delta sync, reporting detail, and bad-item tolerance. Those four answers tell you whether a slow link or a handful of corrupt items will stall the whole batch. Microsoft's own orchestrator is worth checking against licensing before you shop externally.

Newcastle and Hunter offices that would rather have the inventory done with them can start from email help in Newcastle rather than guessing the batch size from a CSV.

What causes email migrations to fail?

Most failures sit on a short list. Catch them early and the fix is usually small.

• DNS split-brain. Old MX still cached somewhere on the internet. Confirm the TTL was actually lowered ahead of time.
• Throttling. Jobs crawl under Microsoft's rate limits. Reduce concurrent threads. Watch error rates, not volume.
• Corrupt or oversized items. A handful of bad items stall a batch. Set a sensible bad-item tolerance. Zero tolerance sounds tidy until one calendar attachment blocks forty people.
• Folder mapping mismatches. Folders duplicate or nest in the wrong place. Usually a remap pass, not a full redo.
• LegacyExchangeDN bounce-backs. Replies to old emails bounce with an IMCEAEX error. Add the old LegacyExchangeDN as an X500 proxy address on the new mailbox so reply paths survive.

Once mail flow is stable, fix the client side. Rebuild affected Outlook profiles rather than patching an old one. Test Autodiscover on a machine that has never touched the previous system. If new mail still will not show after the move, work through Outlook not receiving emails before you reopen the migration job.

What we see on visits

The biggest risk is not an hour of downtime. It is mail that arrived during the copy and never made it across. That is why preload and a final delta sync matter more than raw speed.

On the user side, Autodiscover tested before cutover day is what stops a ticket surge on Monday. Freeze rules in the final sync window. Tell people what will look different. Then keep the old system live long enough that a missed shared mailbox is recoverable, not a post-mortem.

We start with mailbox count, source system, and any compliance holds. The method comes from those facts. Not from whichever migration blog was open first. More on scope sits on the Microsoft 365 and business email page.

PC Scientist can help with the Microsoft 365 move

Some of this is inventory and a remote pilot. Some of it is a cutover window that needs someone watching mail flow while staff keep working. That is a fair reason to stop. Email Systems Scientist can look with you, remotely first if that is enough, or onsite if the old server or the DNS change needs a visit.

Tell us the mailbox count, what you are leaving, and whether anyone is on a legal hold. We will say whether a remote session will do, or whether a visit makes more sense. Call 0493 563 381, or pick your area below.

Sources

These pages help when you want the official wording:

• Mailbox migration - Microsoft Learn
• Email security - Australian Cyber Security Centre