Delta vs Cutover Migration: When Each One Actually Matters

Two migrations of the same 300 mailboxes can take very different shapes depending on whether you plan for a single cutover window or a bulk move followed by a delta sync. The first design assumes you have a long weekend; the second assumes you do not, and works backwards from a short cutover window measured in minutes rather than hours. This post explains how each pattern works in practice, when each is the right call, and how modern migration tools implement delta sync without making the project harder.

The two strategies, briefly#

Cutover migration moves everything in a single window. You schedule downtime, stop new mail flow to the source, run the migration, validate, then point mail at the destination. Users come back to a fully populated destination mailbox after the window closes.

Delta sync migration moves the bulk of mail first, while the source is still live and receiving new messages. Then one or more incremental passes catch up the messages that arrived during the bulk move. Finally, a brief cutover switches mail flow and runs a last delta pass to catch the very last batch of messages.

The classification compared to the cutover vs staged vs hybrid terminology that Microsoft uses for Exchange migrations: cutover here roughly maps to Microsoft's cutover. Delta sync overlaps with staged and hybrid but applies more broadly because it is not Microsoft-specific terminology. Most IMAP-based migrations today are some flavour of delta sync, even if the documentation does not call them that.

Why cutover used to be the default#

For most of email migration's history, cutover was the natural pattern because tools could only do cutover. The migration ran, you waited, it finished or failed. Re-running it meant re-doing the whole move, with duplicates if the tool was not careful about deduplication.

Three things changed:

1. Mailboxes got bigger. A 20 GB mailbox does not finish in a 2-hour window. A 100 GB mailbox does not finish in any reasonable window.
2. Tolerance for downtime shrank. Modern businesses do not accept "email is offline for the weekend".
3. Tools got smarter about state. Tracking which messages have already been migrated, by UID or Message-ID, became standard.

The result is that delta sync is the default for any migration above a small handful of mailboxes, and cutover survives mainly as the right answer for genuinely small projects.

How delta sync works under the hood#

Delta sync needs the migration tool to answer one question reliably: "for this folder, what messages are already at the destination?" Get this right and you can run as many incremental passes as you want without creating duplicates.

The common implementation uses a combination of:

• IMAP UIDs as the primary state. The tool records the highest source UID it has seen for each folder. The next pass fetches only messages with UID greater than that mark.
• Message-ID headers as a deduplication safety net. If a UID changes (for example, if a message is moved between folders on the source), the tool can match by Message-ID to avoid re-copying.
• A state file or database on the migration host that holds per-folder, per-mailbox checkpoint information.

The result is a tool that can be stopped and restarted, run incrementally, and run as many times as you like without creating duplicate messages.

What can go wrong with delta state#

The state file is critical. Lose it and the next run becomes a cutover all over again, with potential duplicates from messages that were already copied. Treat the state file like any other operational data:

• Back it up to a separate location after each successful pass.
• Version it. If the tool changes schema, you want to be able to roll back.
• Keep it on the same workstation across all delta passes if possible. Moving it between machines invites consistency bugs.

When cutover is the right answer#

Despite delta sync being the default, cutover is still the simpler and correct choice in several situations.

Small mailbox counts#

Below about 50 mailboxes, the bookkeeping of delta sync (multiple passes, state preservation, cutover scheduling) outweighs the time saved by shortening the cutover window. A weekend cutover is fine.

Predictable mailbox sizes#

If all mailboxes are under 5 GB, cutover for the whole tenant finishes in a few hours of parallel work. Delta sync exists to help with the long tail; if you do not have a long tail, you do not need it.

Acceptable downtime tolerance#

Some organisations genuinely do not need email to be live overnight on a Saturday. If your customer can accept a 6-hour mail-flow pause, cutover removes a lot of project complexity.

Highly stable source mailboxes#

If the source mailboxes are essentially archive accounts that rarely receive new mail, delta sync provides little benefit because there is no delta worth syncing.

The decision tree is: how big is the project, how much downtime can the business tolerate, and how live is the source mailbox traffic. If all three answers are small, cutover. Otherwise, delta sync.

When delta sync is the right answer#

The opposite cases:

• Large mailbox counts (more than 50 to 100), where parallel cutover still does not fit in a reasonable window.
• Large per-mailbox sizes (more than 10 GB average), where individual mailboxes do not fit in a short window.
• Low downtime tolerance, where the business needs mail flow restored in minutes after cutover, not hours.
• 24/7 mailboxes, where any cutover window will leave a noticeable gap.
• Distributed users, where there is no global "quiet time" for everyone.

For an MSP doing a 500-mailbox migration for a global customer, delta sync is almost always the right answer because all four conditions above usually apply at once.

The typical delta sync project shape#

A clean delta sync project has a recognisable shape:

1. Pre-stage (often days or weeks before cutover): provision destination tenant, create users, set up identity, configure mail flow but do not switch.
2. Bulk move (a few days before cutover): the first big migration pass. Moves 95–99% of historical mail. Source is still live and receiving new messages.
3. Delta passes (between bulk move and cutover): one or more incremental passes that catch up the messages that arrived during the bulk move.
4. Cutover window (the actual switch): short, often under an hour. Final delta pass while mail flow is briefly paused or routed through both systems, then DNS switch.
5. Post-cutover (the days after): monitoring for stragglers, delivery problems, and any users with edge cases.

The wider project plan that wraps around this is covered in the email migration project plan post. The complete email migration guide covers the end-to-end pattern at the same level.

How many delta passes do you need?#

Usually one or two between bulk move and cutover, plus a final pass during the cutover window itself.

The first delta pass after the bulk move catches a few days of accumulated new mail. The second pass, run closer to cutover, catches the most recent few hours. The cutover-window pass catches the last few minutes.

More passes do not hurt, but they have diminishing returns. The bulk of mail moves in the first pass; subsequent passes are progressively smaller and faster.

Mail flow during a delta sync window#

A subtle question: where does new mail go between bulk move and cutover?

Three patterns:

• Source-only: mail flows to the source as normal. Delta passes pull new messages forward. This is the simplest pattern and works for most projects.
• Dual delivery: mail is delivered to both source and destination via mail flow rules. The destination accumulates mail naturally; delta sync handles only historical messages. More complex, but enables a faster cutover.
• Source with relay: mail is delivered to source, then relayed to destination by a forwarding rule. Functionally similar to dual delivery but configured differently.

Source-only is the default for IMAP-based migrations because it does not require any mail flow gymnastics. The trade-off is that delta passes have to keep up with incoming mail; otherwise the gap grows.

The cutover window itself#

Even with delta sync, there is still a cutover. Mail flow has to actually switch at some point. The question is how long that switch takes.

A clean cutover with delta sync looks like:

1. Pause new mail to source by lowering MX TTL beforehand and then changing MX records.
2. Wait briefly for in-flight messages to drain to source.
3. Run a final delta pass to pull anything that arrived in the last minute or two.
4. Confirm destination is current with a quick sample check.
5. Test sending and receiving from a few accounts on the destination.
6. Announce that cutover is complete to users.

This whole sequence often fits in 30 to 60 minutes. The actual mail flow downtime, where users cannot send or receive, is measured in minutes rather than hours.

The MX TTL setup is important. Set the source TTL to a low value (300 seconds or less) at least 24 hours before cutover, so DNS propagates the new value before you make the actual change. Otherwise downstream resolvers will keep sending mail to the old MX for whatever TTL was originally cached.

Real-world examples#

Example one: 30 mailboxes, weekend cutover#

A small consultancy moves 30 mailboxes from a self-hosted IMAP server to Microsoft 365. Average mailbox size 4 GB. The team accepts a Saturday cutover. They run a single 8-hour migration starting at 9am Saturday with 8 mailboxes in parallel. Done by 4pm with time to spare. Mail flow switched at 5pm. No delta sync needed; the cutover window was long enough.

Example two: 280 mailboxes, business-hours sensitivity#

A regional accounting firm moves 280 mailboxes from Workspace to Microsoft 365 ahead of quarter-end. Average mailbox size 12 GB. They cannot tolerate more than 30 minutes of mail flow downtime because they receive client emails throughout the working day, including over weekends during quarter-end. They use delta sync:

• Bulk move over a Thursday-night to Saturday-morning window. About 96% of mail moves.
• First delta pass Saturday afternoon catches Thursday-Saturday new mail.
• Second delta pass Sunday morning catches Saturday-Sunday morning new mail.
• Cutover Sunday at 6pm: MX TTL was lowered to 300s on Friday. Final delta pass takes 12 minutes. MX swap takes effect within minutes. Total mail flow downtime: about 18 minutes.

Example three: 1,500 mailboxes, global business#

A multinational moves 1,500 mailboxes spanning three continents from one Microsoft 365 tenant to another after an acquisition. Average mailbox size 18 GB. There is no global quiet window. They use delta sync over a four-week project window:

• Week 1: pre-stage. Identity, mail flow, destination tenant setup.
• Weeks 2 to 3: bulk move in batches of 200, working through regions.
• Week 3 to 4: rolling delta passes per region as each region approaches its local cutover.
• Cutover happens region by region over a weekend, with the global MX swap during the lowest-traffic 90-minute window the team can find.

Each regional cutover takes about an hour; total mail flow downtime per user is roughly 30 to 45 minutes depending on their region.

How most modern tools implement delta sync#

The mechanics are similar across major migration tools, with variations:

• Mailbox Taxi uses IMAP UIDs and Message-ID as the dedup keys. Each delta pass fetches only messages above the last-seen UID per folder and validates against the destination before appending. State is held in a local database on the migration workstation.
• Microsoft Native Move (for Microsoft 365 tenant-to-tenant) uses provider-native state tracked inside the Mailbox Migration Service. Delta is handled automatically; you trigger the move and complete when ready.
• Various third-party SaaS tools generally use a combination of UID, internal IDs, and their own state stores.

The differences mostly affect operational details (where state lives, how you trigger delta passes, what happens if a pass fails partway through) rather than the underlying pattern.

For Microsoft 365 specifically, the Office 365 migration guide covers the destination-side specifics including how Native Move handles delta state.

When delta sync goes wrong#

Three common failure modes:

State file corruption#

If the migration tool's state database gets corrupted (disk full, abrupt shutdown, file system issue), the next pass cannot tell what has already moved. Modern tools handle this by falling back to a destination-side scan, but the scan is slow and risks duplicates if dedup is imperfect.

Prevention: back up the state file after each pass. Run the migration host on reliable disk.

Source-side UID changes#

Some providers occasionally renumber UIDs (Yahoo has been known to do this; some less-maintained IMAP servers do it under load). When UIDs change, the tool's checkpoint becomes meaningless and it has to re-scan from the start.

Prevention: rely on Message-ID as a secondary key. Use a tool that handles UID changes gracefully.

Folder restructuring on the source#

If a user reorganises folders on the source between delta passes, the tool may see "new" folders that contain "new" messages, even though the messages are actually existing ones that moved on the source.

Prevention: communicate to users that the source mailbox should not be reorganised during the migration window. Run delta passes close together to minimise the chance of this happening.

Choosing the right strategy for your project#

A practical decision flow:

1. How many mailboxes? Under 50, lean towards cutover. Over 200, lean towards delta sync. In between, look at the other factors.
2. Average mailbox size? Over 10 GB, lean towards delta sync. Under 2 GB, cutover is fine.
3. Downtime tolerance? Under 30 minutes, delta sync is necessary. Over 4 hours, cutover is possible.
4. Mail flow pattern? 24/7 mailboxes need delta sync. Office-hours mailboxes can do cutover.
5. Operational maturity? First-time migration for the team? Cutover is simpler. Experienced MSP? Delta sync is routine.

If you are an MSP running migrations regularly, the MSP email migration playbook covers the operational pattern that turns delta sync into a repeatable practice rather than a project-specific decision.

What both strategies share#

Whichever strategy you pick, the underlying mechanics of the actual mailbox move are the same. IMAP fetches messages, appends them to the destination, preserves flags and timestamps, validates counts. The strategy is about scheduling and state, not about the move itself.

That means the choice between delta and cutover is not really about the tool's capabilities; almost any modern tool supports both. It is about how you sequence the work to fit the customer's downtime budget and mailbox profile. Get the sequencing right and the move itself is the easy part.