Planning the cutover and domain switch

This article covers the switch that completes a migration once VaultMe has finished copying the mail. It walks through what that switch involves and what to decide and prepare for it at planning time.

What does planning the cutover involve?

Cutover is the phase of the project where your organization shifts its primary reliance from the source to the destination server: new mail is routed to the destination, and the source is then retired or restricted. It is the finale of the project, and it is a different thing from the content migration VaultMe runs. VaultMe copying mail into the destination mailboxes changes nothing about where new messages are delivered — only the cutover does that.

The cutover is yours to run from end to end. VaultMe migrates the mail; you point mail routing at the destination server, edit the DNS records that carry that routing, retire the source, reconfigure mail clients, and repair the important links inside migrated mail that no longer resolve. None of these are steps VaultMe performs, or could perform on your behalf, because they are changes to your own domain, servers, and devices rather than to migrated content.

In a Microsoft 365 to IMAP-compatible mail system migration, mail flow is the entire cutover. IMAP is a mail protocol, so email is the only content type VaultMe can migrate into the destination server, and the whole sequence comes down to one question: where does new mail land? Whatever calendars, contacts, and files live in Microsoft 365 stay where they are, since they are not migrated — there is nothing about them to hand over at cutover, and they need a plan of their own; content scope is settled in "Selecting content for migration".

Planning the cutover at this stage produces a cutover plan with three parts:

1. A clear picture of the procedure you will run. The sequence — mail keeps flowing to the source while mailboxes migrate, then routing switches, then a final sync-up migration (delta migration) sweeps up what arrived in the meantime, then the source is retired — needs to be understood well before the last batch finishes, because you are the one carrying it out.
2. The decisions that have to be locked now. Above all the domain decision: whether the domain that currently delivers mail to the source will be repointed at the destination server, or will stay where it is while users receive on a different address. Almost everything else about the switch follows from that answer.
3. The preparation staged now. Registrar or DNS access in hand, a retirement schedule for the source, and named owners for the work that outlives the switch. The point of staging it early is that the switch itself then takes an evening rather than becoming a project of its own.

What makes that sequence safe is sync-up migration: an incremental follow-up run that copies only what changed in the source since the previous run, matched through the index VaultMe keeps of every item it has already copied. That mechanism is why mail can keep flowing to the source throughout the migration, and why the gap between a mailbox being migrated and the routing being switched does not have to be squeezed to zero.

The size of the project changes how the cutover is scheduled, not what it consists of. A small migration that runs as a single big-bang batch usually cuts over in one quick window: the batch finishes, routing switches, a final sync-up follows the same evening. A larger phased rollout runs the identical sequence as a planned finale after the last batch completes, with periodic sync-ups keeping the earlier batches current until then. The two rollout shapes are described in "Choosing a migration strategy".

What cutover approach is VaultMe built for?

Mail cutovers are approached in several ways: freezing mail and cramming the entire migration into one window, arranging dual delivery so both systems receive for a period, or setting up forwarding from the source to the destination before the migration is finished. Each of those has its adherents, and none of them is what VaultMe is built around.

VaultMe is designed for a different sequence, and that sequence is also the general recommendation rather than a house preference. It has three stages:

1. Mail keeps flowing to the source while accounts migrate. Nothing about routing changes yet. Everyone carries on working where they always have, and VaultMe copies content into the destination in the background.
2. Once the accounts are migrated, mail routing is switched to the destination. From that moment, new mail is delivered to the destination rather than the source.
3. A final sync-up migration (delta migration) carries the gap. It copies everything that arrived at or changed in the source between the initial migration and the switch, so nothing is stranded on the old system.

The reason this is the right general answer, and not a VaultMe quirk, is that email is live and cannot be paused. Whatever moment routing is flipped, some mail will have reached the source after its account was copied and before the flip took effect. Every mail cutover therefore ends with a catch-up pass of some kind; the only real question is how trustworthy that pass is. VaultMe's sync-up migration is what makes it dependable, because it copies exactly the source-side changes since the previous run and nothing else.

The same three stages fit both rollout shapes. A small project runs one batch and one short cutover window. A large project runs many batches over weeks and ends in a single cutover once the last of them is done. The sequence does not change with size — only how many times the migration stage repeats before the switch. The chapter "What is the recommended cutover sequence?" walks it through step by step.

Why does sync-up make the cutover safe?

Almost every hesitation about this approach comes down to the same fear: that leaving a gap between migrating an account and switching its mail will cost messages, or produce two of everything. It will not, and understanding why is what makes the rest of the cutover plan easy to commit to.

A sync-up migration (delta migration) is not a second migration. When VaultMe migrates an account, it builds and keeps an index that pairs every source item it copied with the destination copy it created. The initial run writes that index, and every sync-up updates it. Each sync-up then reads the source, compares what it finds against the index, and acts only on the difference:

• Items that are new in the source are copied into the destination under the same placement and organization rules the initial migration used.
• Items that changed since the last run have those changes applied to their existing destination copy, rather than being copied again alongside the old version.
• Items that were relocated in the source — a message filed into a different folder, for example — have the same relocation applied to their destination copy, as far as the destination provider allows.
• Items that are unchanged are left alone. They are recorded in the index as already migrated and are not copied a second time, so repeated sync-ups do not accumulate duplicates.
• Items deleted in the source are not deleted in the destination. A sync-up carries changes forward; it is not a two-way reconciliation.

What makes this dependable is that the matching is done from VaultMe's own index rather than from provider-side signals such as message identifiers, file names, or change feeds, which are inconsistent across systems and unreliable to compare. VaultMe knows which destination copy belongs to which source item because it created that copy and recorded the pairing at the time.

That design also explains the one mistake worth guarding against, which is that the index belongs to one migration and only that migration. VaultMe does not inspect content that is already sitting in a destination account, and it has no way of recognizing that an earlier migration put it there. Starting a new migration of the same accounts in order to pick up newer mail therefore copies everything again from scratch, and the result is a complete duplicate set. When you need to catch up, run an additional sync-up on the original batch — never a fresh migration of the same accounts.

The same index-only behavior is what makes switching first and syncing afterwards safe. A sync-up reads the source and writes to the destination; it never scans the destination looking for matches. Mail that is delivered straight to the destination after the switch was never in the source, is not in the index, and is simply not something a sync-up looks at. It cannot be touched, matched, or duplicated by a later run.

It is also what rules out one specific combination, and this one is worth committing to memory: never run source-to-destination forwarding and sync-up migrations at the same time. Forwarding delivers a copy of each new message into the destination, and the next sync-up, reading only the source, copies the very same message again — guaranteed duplicates, one pair per message. Forwarding on its own is a perfectly reasonable fallback for an admin who would rather not rely on sync-up at all. Pick one mechanism or the other; just never let them overlap.

In practice, most of this happens without being asked for. Every initial migration finishes with an automatic sync-up that sweeps up whatever changed in the source while the run was in progress, so changes made during a long migration are not lost. Beyond that, additional sync-ups are started from the VaultMe app: for individual accounts that have finished while others in the batch are still processing, or for the whole batch once every account in it is done.

One scheduling detail matters on longer projects. The index is retained for 30 days, counted from the completion of the initial migration or of the most recent sync-up, and each successful sync-up resets that window. For a small migration cut over the same weekend this never comes up. For a phased rollout running over several weeks, an early batch's index can expire before the cutover arrives — and once it does, there is no index left to sync against. The fix is routine rather than clever: run a periodic sync-up on each completed batch, roughly weekly, and every batch's index stays alive until the day you switch.

Two honest limits keep this from being oversold:

• Sync-up is a bridge, not an ongoing synchronization service. It is designed to carry a source forward from the initial migration to the cutover, and that is the job it should be planned around. It is not a way to keep two live systems in step indefinitely.
• A late sync-up overwrites destination-side edits. When a sync-up applies a source-side change to an item that was already migrated, whatever anyone changed on the destination copy is overwritten; where the destination provider keeps revision history, some of that can be recovered, and otherwise it is lost. This is the practical reason the final sync-up belongs at the cutover itself, before people start working in the destination in earnest.

The design those limits come from is in "How sync-up migration works".

What is the recommended cutover sequence?

This is the procedure you will actually carry out once VaultMe has finished, laid out at planning level: enough to schedule around and to know who does what, not a click-by-click walkthrough.

1. Migrate the accounts while mail keeps flowing to the source. Everything in scope is migrated either as a single batch or across several, depending on the rollout shape chosen earlier. Each run ends with its own automatic sync-up migration (delta migration), so changes made during the run are already accounted for.

2. On a phased or long-running project, run additional sync-ups on the batches that have completed. This does two things: it keeps each batch's index inside its 30-day retention window, and it shrinks the amount of change the final sync-up has to carry. About once a week is enough. A quick big-bang migration that cuts over within days can skip this step entirely.

3. Once everything is migrated and verified, switch mail over and run the final sync-up. This is customer-side work, not a VaultMe step.

   • Where the domain is repointed at the destination, its MX records are changed so new mail is delivered there; once the rest of the world has picked that change up, one final sync-up per batch sweeps up the tail that reached the source in the meantime.
   • Where the domain stays with the source instead, run the final sync-up per batch and let forwarding carry ongoing mail to the old addresses from there.

   The chapter "How is the domain handled at cutover?" covers both situations in detail.

4. Retire or restrict the source on your own schedule. Nothing forces this to happen at the switch. Leaving the source read-only as a fallback for a while is the sensible default; the manual follow-up chapter goes into what retiring it involves.

Only one of the mentioned sync-ups is genuinely essential, and it is the final one in step 3. The earlier passes in step 2 are an optimization — they shorten the final sync-up and keep indexes fresh on a long project, and they are unnecessary on a short one.

Read alongside the schedule, this sequence is short. It is the finale of a project whose long pole is preparation rather than execution, and it comes after the batches. Fitting it into the calendar is covered in "Planning the migration timeline".

How is the domain handled at cutover?

Organizations decide all kinds of things about domains during a migration: keep the existing one, rename, adopt a better one, or run two side by side. For the cutover itself, all of that reduces to a single question about mail: will the domain that currently delivers mail to the source be repointed at the destination, or will it stay pointing at the source? That fork decides the mechanics; any naming or rebranding decision rides on top of it and does not change them.

Moving the domain to the destination

This is the common case, and the one to assume unless something specific rules it out: the source is being retired or consolidated away, and the domain that has always delivered its mail should now deliver to the destination.

The switch comes down to repointing that domain's MX records — the DNS records that tell every other mail system where to deliver mail addressed to the domain — so that new mail lands on the destination. Mail systems cache those records for a while, so the change takes effect gradually rather than instantly; once it has settled, one final sync-up migration (delta migration) sweeps up whatever reached the source during that window. No forwarding is involved, because the domain now delivers to the destination directly.

Editing DNS records means having access to wherever the domain is administered, which is frequently a registrar account nobody on the migration team holds. Securing that access is slow, out of VaultMe's hands, and one of the most common reasons a cutover date slips, so start on it early. The broader domain groundwork — buying, adding, and verifying domains — belongs to destination readiness rather than to the cutover.

In a Microsoft 365 to IMAP-compatible mail system migration, an IMAP server addresses each mailbox by host and login rather than by a verified domain, so there is nothing to configure, verify, or assign on the domain side beforehand. The destination mailboxes already exist independently of any domain and begin receiving the moment the domain points at them.

That reduces the whole domain switch to one action: repointing the domain's MX records at the destination mail server so new mail is delivered there. Take the exact record values from the documentation of whoever operates that server rather than assuming them.

Leaving the domain on the source

Sometimes the domain is not the organization's to repoint, or the source keeps operating after the migration. Then people receive mail at a destination address instead, and the old domain carries on delivering to the source.

After the accounts are migrated, one final sync-up clears the backlog that accumulated at the source. From there, forwarding set up on the old domain carries ongoing mail to the old addresses on to the destination. The two mechanisms cover windows that do not overlap: the sync-up covers everything up to the moment it runs, and forwarding covers everything after it, so they never act on the same message. That is what separates this arrangement from running forwarding alongside sync-ups, which duplicates every forwarded message.

Treat this as the narrow fallback for a domain that genuinely cannot be repointed, rather than as an alternative worth choosing.

Keeping VaultMe connected through the switch

Whether the domain moves to the destination or stays on the source, one worry tends to surface late and is better settled now: does changing a domain break VaultMe's connection to the accounts it is migrating? It is a fair thing to ask, because the final sync-up runs after the switch and needs both sides still connected. The answer is that the switch itself is safe, and the reason comes down to what VaultMe holds on to when it connects an account, which is never simply its email address.

An account in a Google Workspace organization or a Microsoft 365 tenant carries a permanent internal identifier that its provider assigns once and never changes, and that identifier is what VaultMe connects through — not the email address or user principal name on the surface. Moving an account onto a different domain, or changing its address outright, therefore leaves the connection untouched and the sync-up that follows it works normally.

An IMAP server keeps no permanent identifier behind a mailbox, so VaultMe reaches each one with the host, login, and password supplied when it was connected. Repointing MX records changes where new mail is delivered, and changes nothing about the host or login VaultMe authenticates with, so the connection survives the switch untouched. What would break it is a change to the credentials themselves. A renamed login or a new host cannot be reconnected without help, because VaultMe has no way to recognize the mailbox as the same one and treats it as a different mailbox entirely; sorting that out means writing to VaultMe support before any further sync-up runs. In practice many IMAP logins are a plain username that a domain change never touches, so this often turns out to be a non-issue — confirm it with whoever operates the mail server, and avoid changing hosts or logins at cutover.

What genuinely does put a connection at risk is the other identity work that tends to cluster around a cutover: a password reset, an MFA change, a change to an account's admin configuration. Any of those can drop a connection and pause the migration until it is restored, so keep them away from the switch and the days either side of it. What a destination connection depends on, and what keeps it alive, is covered in "Getting the destination ready".

Why not rush a large migration into one weekend?

To be clear about who this is for: a single-weekend big bang is a fine plan for a small, clear-cut project, and it is the recommended one there. The problem is the same instinct applied to a large project, where it concentrates risk instead of removing it.

The anti-pattern looks like this. Not fully trusting that a sync-up migration (delta migration) can bridge the gap, an admin assumes that any interval between migrating accounts and switching mail leaks duplicates or lost messages, and reasons that the gap must therefore be squeezed to nearly nothing. Everything — the entire migration, the switch, and the finishing checks — gets crammed into one window, classically Friday evening to Monday morning, usually with no test batch beforehand.

For a large project, that plan has no grounding and is exhausting to execute:

• All the risk lands in one small window. Anything that goes wrong has to be diagnosed and fixed while the clock runs, with no room to reschedule.
• There is no test batch to calibrate against. Real per-account durations, real item counts, and any surprises specific to the environment are all discovered live, during the only window there is.
• Simultaneous load is at its maximum. Launching every account at once is exactly the condition most likely to trigger provider-side throttling, which slows the run precisely when there is no slack for it.
• Large accounts do not respect the window. A single high-item-count mailbox can run for days. In a batch that runs in parallel, the finish is set by the slowest account, not the average one.

The alternative is not more risk, it is less: migrate batch by batch across a realistic runway, and let each batch sit migrated until the shared cutover. Sync-up is what makes that gap safe, and once you trust it, staging stops feeling like exposure and starts looking like what it is — a fully supported way to spread the work out and learn from it as you go.

When is the best time to cut over?

There is a widespread belief that a cutover has to happen late on a Sunday night. It is a leftover from the habit above — from the days when the whole migration was squeezed into a single weekend, so the switch inherited the worst hour of it. With this approach the migration has already run over the preceding days or weeks, and the cutover is short: switch routing, wait for the DNS change to settle, run the final sync-up migration (delta migration), check the result. That is a brief finale, not a lost weekend, and there is no fixed rule about when to hold it.

Three things should drive the choice, and none of them is a particular day of the week:

• Low mail traffic. An evening, the end of the business day, or a weekend all mean fewer messages reach the source while the routing change is still settling, which leaves a smaller tail for the final sync-up to carry.
• Buffer before heavy use. Leave room for the DNS change to propagate, for the final sync-up to run, and for someone to verify the result before people start relying on the destination. This is more than tidiness: as covered in "Why does sync-up make the cutover safe?", a sync-up that lands after users have begun editing migrated items will overwrite those edits, so the final pass belongs before the destination is in real use, not after.
• Reachable help. You and VaultMe support should both be able to act during the window and the buffer that follows it. This is the real argument against a deep-night or holiday cutover: not that the hour is unlucky, but that nobody on your own side is awake to notice if something needs attention.

How much buffer is enough scales with the project. A small migration is comfortable with an overnight cushion — cut over in the evening, verify in the morning. A large one benefits from starting on a Friday, which buys the whole weekend before normal business resumes.

The answer is therefore less specific than people expect: any low-traffic evening with a buffer after it will do, and Friday gives the most cushion on a big project. Buffer, low traffic, and reachable support are what matter, not the name of the day.

What manual follow-up is left after cutover?

Switching the mail is not quite the end. A short list of finishing tasks stays with the customer, deliberately rather than by omission — each one requires judgment about what matters in a specific business, which is not something a migration tool can make on anyone's behalf. Knowing the list in advance is what keeps it from feeling like a series of unpleasant discoveries.

• Links inside migrated content may no longer work. VaultMe preserves embedded links exactly as they were written, without rewriting them to point at the migrated destination copies, because rewriting content is not something a faithful copy does. Links that pointed at source items therefore go stale once the source is retired. This is expected behavior rather than a migration failure, and the response is to review and update the ones that matter — links inside migrated messages, email being the only content type in scope for a Microsoft 365 to IMAP-compatible mail system migration.
• Mail clients have to be pointed at the destination. Routing decides where new mail is delivered, but it does not reconfigure anything installed on a desktop or a phone. Each person re-creates their account settings with the destination server's details, the IMAP host above all, so their client connects to the new mailbox instead of the old one. Worth including in what end users are told rather than leaving them to work out why nothing new is arriving.
• The source is retired on your schedule. Stop new mail reaching it, then downgrade or remove licenses, and decommission it once you are confident. Because VaultMe copies rather than moves, the source stays completely intact throughout, which gives you two useful things: you can verify the result by comparing the two sides directly, and you can keep the source read-only as a fallback for as long as it takes to be sure. Note any legal or retention obligation that requires the source to be preserved regardless.
• End users own a few tasks of their own. Anything VaultMe could not place automatically is left in a clearly marked TODO area in the destination for someone to review and file by hand. What to ask of end users, and when, is covered in "Preparing stakeholders and end users".

A checklist for planning the cutover

The chapters above describe the procedure you will carry out on the day. This is the shorter question of what to settle and stage now, while the project is still being planned, so that the switch is quick and uneventful once the batches finish.

1. The domain decision is locked. Settle whether the domain that delivers to the source moves to the destination server or stays where it is, since the rest of the switch follows from it — see "How is the domain handled at cutover?". For a domain that moves, line up the preparation now: secure registrar or DNS access, which is the single most common reason a cutover slips; write out the target MX record values in advance, taking them from the destination server operator's documentation; and consider lowering that record's TTL a few days ahead so the change propagates quickly when you make it.
2. The cutover window is chosen. Place it in the batch schedule first — one window at the end for a big bang, a finale after the last batch for a phased rollout — and carry that position into the project schedule, which is built in "Planning the migration timeline". Then pick the moment itself: low mail traffic, with enough buffer after it for propagation, the final sync-up migration (delta migration), and a verification pass. See "When is the best time to cut over?".
3. The source-retirement plan is decided. Because VaultMe copies mail rather than moving it, the source is still intact when the cutover finishes, which makes it a useful fallback. Keep it read-only first, then suspend the source user accounts or remove their licenses, and decommission only once you are confident nothing is missing. Note any legal or retention hold that rules out deletion, since it decides how long the source has to stay in place regardless of the migration.
4. People and mail clients are planned for. Routing decides where new mail is delivered, but desktop and mobile mail clients keep talking to the old server until the destination IMAP host is entered in each client's account settings. Decide now how that happens — pushed centrally, walked through one at a time, or handed out as instructions — and fold it, along with the announcement of the switch itself, into the communication plan covered in "Preparing stakeholders and end users".
5. Follow-up ownership is decided. Links inside migrated mail that point at source items and stop resolving, and messages left in the destination's TODO area for manual review — most of it falls to end users, since only they know which parts of their own mail matter. Decide whether they get instructions and work through it themselves, or someone goes through it with them account by account. What does not work is assuming someone will notice — see "What manual follow-up is left after cutover?".
6. The procedure is understood. Whoever runs the cutover should know the sequence before the day arrives: migrate the mailboxes while mail still flows to the source, sync up, switch the routing, run the final sync-up migration, then retire the source. See "What is the recommended cutover sequence?".

One instinct is worth resisting on a large project: cramming the migration and the cutover together into a single weekend because any gap between migrating a mailbox and switching its mail feels dangerous. That gap is exactly what sync-up is for, and closing it by force concentrates every risk in the project into two days, as "Why not rush a large migration into one weekend?" sets out. Stage the batches over a realistic runway and let the final sync-up close the gap for you.

With the window chosen and the domain decision made, the cutover plan feeds the two pieces of planning that remain. The cutover window is one of the fixed points the rest of the schedule is built around, so carry it into "Planning the migration timeline". The announcement, the client reconfiguration, and the tasks end users pick up after the switch belong in "Preparing stakeholders and end users".