Planning the cutover and domain switch

This article covers the end of a migration out of personal accounts: the point where each account holder stops relying on the old account and starts working in the new one, and what has to be settled in advance for that to go smoothly.

What does planning the cutover involve?

Cutover is the phase of a migration project where the customer stops relying on the source and starts relying on the destination, usually retiring or restricting the source along the way. The situation here is a business that grew up without any central administration: everyone works out of a personal user account on Outlook, and the project is migrating all of them onto new business accounts on Google Workspace. In that setup, cutover is about as small as it gets — each account holder starts working in the new account and stops using the personal one.

Most of what a domain switch usually means does not exist on this path. A personal account belongs to the person rather than to an organization, and it carries no custom domain: mail is delivered to an address on the provider's own domain, by the provider's own routing. There is no MX record to repoint, no DNS entry to edit, and no mail flow under the business's control that could be sent somewhere else. Mail keeps arriving at each personal address for as long as that address exists.

The destination side may well have a custom domain, since new business accounts usually do. That domain is stood up while the destination is being prepared rather than switched at cutover, because the personal accounts never delivered to it in the first place. There is nothing to repoint — only a domain that starts carrying mail once people are working in the new accounts. That work is covered in "Getting the destination ready".

Because nothing is being rerouted, no switchover procedure sits waiting on the source side once the migration finishes. VaultMe copies the content. Closing a personal account, turning on forwarding, and repairing a link that no longer resolves are not VaultMe steps; they belong to the account holder, who handles them on their own schedule. When the content has been copied and any late mail has been collected, the project is over.

These projects are usually small and clear-cut: a handful of accounts, all migrating at the same time, with no environment to stage and no batch sequence to design. A single quick migration is the normal shape, and the cutover is not a separate event scheduled after it. A phased rollout, weighed up in "Choosing a migration strategy", is rarely warranted at this size.

So planning the cutover here does not produce a procedure to execute later. It produces three much smaller things: confidence that mail arriving late at the personal accounts is handled, one decision per account about what becomes of it afterwards, and a short list of manual follow-up with an owner for each item. The chapters below cover them.

What happens to mail that arrives after migration?

Mail does not pause for a migration. Messages keep landing in the personal accounts while the run is in progress, and they go on landing there after it reports as finished, so the reasonable worry is that some of them never reach the new accounts at all. The two halves of that problem have different answers: mail that arrives while the migration is running is taken care of without anyone doing anything, and mail that arrives afterwards needs one small decision per account.

The run itself needs no plan at all. Every migration ends with a sync-up migration (delta migration) that VaultMe starts automatically, copying into the destination account everything that changed in the source account since the initial run began — mail that arrived in the meantime, and changes to mail that was already there. By the time a migration shows as complete, the mail that landed while it was working has already been swept up.

What settles the question for good is not a VaultMe step at all: it is forwarding, turned on inside the personal account. A personal account that is staying open can forward everything still sent to the old address on to the new business account, so the old address goes on working indefinitely with nobody watching it. An account that is going to be closed can forward for a stretch first, giving the people who still write to it time to learn the new address. Either way the setting lives in Outlook rather than in VaultMe, so it is the account holder who turns it on — worth asking for while the holder is still engaged with the project rather than months later.

Forwarding is not always in place the moment a migration finishes. A holder may be unreachable, or the decision about the account may still be open, and in the meantime mail is accumulating where nobody is reading it. That gap is what an additional sync-up is for: run one on the migration that already ran and it collects everything that has arrived since, at no separate charge. It works at batch level rather than on one account singled out of the batch — while some accounts are still processing, it covers the ones that have finished, and once every account is done it covers the whole batch. The same run doubles as a last sweep shortly before the old accounts are closed for good.

Sweeping the same account a second and a third time sounds like a recipe for duplicated mail, and that fear is the usual reason admins avoid sync-ups altogether. It is misplaced, and the reason is an index. VaultMe records every source item it copies together with the destination copy it created for it, and each sync-up works from that record rather than guessing from message IDs or subject lines, so an item that already migrated and has not changed is never copied twice, and an item that is new in the source is never missed. What does defeat it is starting a fresh migration for an account in order to pick up newer mail. A new migration carries no such record, and VaultMe does not inspect what is already sitting in a destination account, so the entire account is copied again alongside the copy that is already there. The wider model is described in "How sync-up migration works".

The other way to end up with duplicates is to let forwarding and sync-up overlap on the same account. Forwarding delivers a copy of each message straight to the destination, and a later sync-up copies that same message from the source without knowing the forwarded copy exists, so anything that arrived while both were active lands twice. Batch-level scope is what makes this a practical problem, because forwarding gets turned on account by account: if most holders have set it up and one has not, a batch-wide sync-up would duplicate mail for everyone who has. That lagging account is a case to hand to support — write to support@vaultme.com, who can run a sync-up for a single account.

The sync-up fallback also has a shelf life. It stays available for 30 days after an account's most recent run, and each completed sync-up restarts that window. On a project that migrates and cuts over inside the same week this never comes up, but it does mean an account cannot sit untouched for months and then be given a final sweep on the way out.

What manual follow-up is left after cutover?

A migration copies content into the new accounts; it does not finish the switch for the people who use them. Four small jobs are left over, and none of them is a sign that something went wrong.

• Links that point back at the old accounts. Links inside migrated emails, files, calendar items, and contacts are preserved exactly as they were written. VaultMe does not rewrite them to point at the migrated copies, because keeping content faithful to the original takes priority over patching references. A link that addressed something in a personal account therefore still addresses it after the migration, and stops resolving once that account is out of use. Expect a few of those and plan a pass to review and repair the ones that matter by hand.
• Mail apps on desktops and phones. New mail reaches the new account on its own, but the mail apps people already have set up still point at the old one. Each holder either adds the new account alongside the old one or re-creates the mail profile from scratch.
• Verification, and the old accounts themselves. VaultMe copies rather than moves, so every personal account is left exactly as it was, with nothing deleted and nothing rearranged. That makes the result easy to check — the two sides can simply be compared — and it means each personal account can stay in place as a fallback for as long as its holder finds it useful. Closing it is the holder's call and can wait.
• What end users pick up. Anything VaultMe could not place automatically is left in a clearly marked TODO area in the new account, for someone to review and file by hand, and sharing has to be re-established on content that was shared out of the personal accounts. Most of this falls to end users, because only they know which parts of their own content matter. See the chapter on what end users do at cutover and after it in "Preparing stakeholders and end users".

A checklist for the cutover

Everything above reduces to a handful of things to settle before the migration runs:

1. Put forwarding first for late mail. Asking each holder to forward the personal account to the new address is the durable answer. The migration's own automatic sync-up migration (delta migration) covers the run, and an additional sync-up on the same migration covers the gap until forwarding is on — never a new migration, which would copy everything a second time.
2. Decide what becomes of each personal account. Keep it open with forwarding to the new address, or close it after a spell of forwarding or a final sweep. The decision belongs to the account holder; the project plan only needs to record it.
3. Treat a destination domain as destination readiness. If the new accounts use a custom domain, setting it up is part of "Getting the destination ready". There is no source-side switch to pair it with, because the personal accounts never delivered to that domain.
4. Decide who owns the follow-up. Broken links, TODO-area items, and mail apps to reconfigure mostly fall to end users, since only they know what matters to them. Settle whether they get instructions or someone works through it with them.
5. Keep the old accounts as a fallback. Compare source and destination to confirm the result, leave each personal account in place while its holder still wants it, and let the holder close it on their own schedule.

With the cutover settled, the preparation still to do is the schedule the project runs on and the people it touches — see "Planning the migration timeline" and "Preparing stakeholders and end users".