Planning the cutover and domain switch

This article covers the cutover — the customer-side switch that completes the project once VaultMe has finished — and what has to be decided and staged for it now, while the migration is still being planned.

What does planning the cutover involve?

Cutover is the phase of the project where the customer shifts primary reliance from the source to the destination: routing mail there, then retiring or restricting the source once nothing depends on it any more. It is the finale of the project, and it is worth separating firmly from the migration itself. VaultMe copying content into the destination is not the cutover; it is what makes the cutover possible. The two happen at different times, and only one of them is VaultMe's.

That division of labor is the first thing to be clear about, because it decides who has to plan what. VaultMe migrates content. Everything the cutover itself consists of belongs to the customer: routing mail to the destination, editing DNS records wherever the domain is administered, retiring or restricting the source, reconfiguring mail clients, and repairing the important links that pointed at source items. None of these are steps inside VaultMe, and none of them happen automatically when a migration finishes.

Planning at this stage does not mean carrying any of that out. It means producing a cutover plan with three parts:

1. A clear picture of the procedure you will run. The sequence is short and it is always the same, so knowing it now is mostly a matter of reading it once and recognizing where it lands in the schedule.
2. The decisions that have to be locked now. The domain decision above all — whether the domain that currently delivers mail to the source will be repointed at the destination or stay where it is — because almost everything else about the switch follows from it.
3. The preparation that can be staged now. Access to the registrar and DNS records, a temporary domain where one is needed, a schedule for retiring the source, and named owners for the follow-up work. Staged early, the switch itself becomes a short, quiet event once the batches finish.

Mail is the heart of all of it, and for a simple reason: mail arrives in real time. Where new messages are delivered is what makes the cutover a sequence at all, rather than an announcement — it dictates the order of the steps and the moment they have to happen in. Cutover covers more than mail, since drives, files, calendars, and contacts change hands too, but for those there is no routing to switch and the handover is mostly a matter of people starting to use the destination. The chapters below therefore lead with mail; "What happens to drives, files, calendars, and contacts?" picks up the rest.

What keeps that sequence clean is sync-up migration (delta migration) — the follow-up run that copies whatever changed in the source since the previous run. It is the reason accounts can be migrated well before the switch without anything being lost in between or arriving twice, and it is what the chapters below are built on.

How much of this is genuine work scales with the project. A small, clear-cut migration cuts over in a single quick window, often the same evening the batch finishes. A large phased rollout treats the cutover as a planned finale after the last batch completes, with sync-ups keeping the earlier batches current until then. The sequence is identical in both cases; only the number of batches ahead of it changes. If the rollout shape is not settled yet, it is decided 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 Google Workspace to Microsoft 365 migration, the domain can be set up on the destination well in advance, while the source is still receiving mail on it. Each provider proves ownership of a domain with its own separate DNS record, so verifying it on the destination takes nothing away from the source, and both can hold the same domain at the same time. It is worth saying plainly, because the opposite is widely assumed: nothing has to come off the source first.

Mail is never in doubt while both hold it, because delivery follows the MX records and those point at one system only — until the cutover, the source. The destination can therefore sit fully configured and waiting, with nothing to unassign and no window in which neither side holds the domain.

That makes for an unusually undramatic cutover. Destination accounts are provisioned on the real domain during destination readiness, so nothing about them changes on the day, and the switch itself is the MX repoint plus the final sync-up.

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.

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 emails, files, calendar items, and contacts.
• 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-adds the account, or has their mail profile re-created, so their client connects to the destination instead of the old system. 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. Sharing arrangements on migrated files also have to be re-established, since permissions do not follow content into a new environment. What to ask of end users, and when, is covered in "Preparing stakeholders and end users".

What happens to drives, files, calendars, and contacts?

Everything above is about mail because mail is the only content type with a delivery route to switch. Files, calendars, and contacts have no equivalent: nothing is being delivered to them from outside, so there is no record to repoint and no propagation to wait for. Their cutover is simply that people stop opening the source and start working in the destination instead — a communication exercise rather than a technical one.

That does not make them exempt from the timing, though. A final sync-up migration (delta migration) still matters for them, and for the same reason it matters for mail: anything an account holder created or changed in the source after their account was migrated is only carried across by that sync-up. It is also why the final pass belongs before people begin editing in earnest, rather than after — a sync-up applying a source-side change will overwrite whatever was changed on the destination copy in the meantime.

One category needs a named owner rather than an announcement. VaultMe never writes directly into a SharePoint document library: content headed for one is migrated through a connected user account that has access to it, so it lands inside that account instead of the shared structure it is meant to end up in. Putting it where it belongs is a separate manual step after the migration, and it is the step most likely to sit unowned, because it is nobody's personal content. Decide now who does it. How these resources are picked up on the source side is covered in "Building the migration inventory".

The other thing that does not follow content across is sharing. Permissions and collaboration arrangements are re-established by the people who own the content, in the destination, after migration — including access for collaborators outside the organization, which is the part most often forgotten. Preparing end users for that is covered in "Preparing stakeholders and end users".

A checklist for planning the cutover

The chapters above describe the procedure you will run on the day. This one is about what to settle and stage now, so that when the batches finish the switch is a short evening's work rather than a scramble. Run it top to bottom:

1. The domain decision is locked. Move or stay is settled, and where the domain is being repointed at the destination, its groundwork is lined up: the domain bought and verified wherever that can be done in advance, access to the registrar and DNS records secured, the target records written out ready to apply, and — optionally — the records' time-to-live lowered a few days beforehand so the change takes effect faster on the day. Unsecured registrar access is the single most common reason a cutover date slips, so treat it as the long-lead item it is. What the decision commits you to is covered in "How is the domain handled at cutover?".
2. No temporary domain is needed — confirm it. The same domain can be verified and live on the destination while the source carries on receiving mail on it, so destination accounts should be provisioned on the real domain from the start. This item is a check rather than a decision: confirm the domain is already configured on the destination side and that accounts carry their real addresses. Why the two sides can hold the domain at once is explained in "How is the domain handled at cutover?".
3. The cutover window is chosen. Two things decide it. First, where it sits relative to the batch schedule: a single window for a big bang, a finale after the last batch for a phased rollout, which is worked out in "Planning the migration timeline". Second, a moment with low mail traffic and enough buffer after it for propagation, the final sync-up migration (delta migration), and a verification pass. What makes a window a good one is covered in "When is the best time to cut over?".
4. The source-retirement plan is decided. Read-only as a fallback first, then licenses downgraded or removed, and decommissioning only once you are confident. Note any legal or retention hold that keeps the source alive regardless of the schedule.
5. The non-mail handover is planned. End users know to start using the destination for files, calendars, and contacts, and someone is named to place document library content where it belongs after the migration.
6. People and clients are planned for. Reconfiguring mail clients falls on end users, and it needs to be asked for rather than assumed; fold it, and the switch announcement itself, into the communication plan in "Preparing stakeholders and end users".
7. Follow-up ownership is decided. Important links that will break, items left in the destination's TODO area for manual review, and sharing that has to be re-established — most of it falls to end users, since only they know which parts of their own content matter. Decide whether they get instructions and work through it themselves, or someone goes through it with them account by account. The work itself is described in "What manual follow-up is left after cutover?".
8. The procedure is understood. You know the sequence you will run: migrate, sync up, switch, final sync-up, retire. Each step is set out in "What is the recommended cutover sequence?".

If one thing is worth carrying out of this article, it is that a large migration does not have to be forced into a single anxious weekend. That instinct comes from not trusting sync-up migration to keep the earlier batches current, and keeping them current is exactly what it is engineered to do. Migrate at a comfortable pace, run periodic sync-up migrations, and leave the switch as the short final step it deserves to be.

With the cutover approach settled, the remaining preparation is scheduling it and getting people ready for it: "Planning the migration timeline" turns the batch structure and the cutover date into a calendar, and "Preparing stakeholders and end users" covers what everyone involved needs to hear before any of it happens.