Planning the cutover and domain switch

This article covers what the cutover comes down to when the destination is a personal account, and the small amount of planning it still needs.

What does planning the cutover involve?

Cutover is the phase of a migration project where the customer shifts primary reliance from the source to the destination. In practice that means one thing here: the account holder starts working in the destination account and stops using the old one. VaultMe's part of the project ends with the content, so the switch itself is yours and the account holders' to make.

In most migration projects that phase is dominated by mail routing. The organization owns a domain, mail addressed to that domain is delivered to the source, and the cutover is the moment its MX records — the DNS entries that tell other mail systems where to deliver mail for a domain — are repointed at the destination. In a Google Workspace to Gmail migration, that step does not exist. A personal account stands on its own: there is no organization behind it and no custom domain attached to it, so there is no record to repoint, no propagation to wait out, and no switchover window to schedule. A custom domain that still delivers mail to the source is not switched over as part of this either; the destination account receives at its own address, and mail sent to the old addresses is handled by forwarding rather than by a routing change.

What that removes is the entire post-migration operation that a cutover usually is. There is no flip to rehearse and no moment when mail changes course, so the destination account simply holds the content once the migration finishes, and using it is a decision the account holder makes on any day that suits them. For all practical purposes the project is complete when the migration is complete.

Two loose ends outlive the run. Mail keeps arriving at the source account after its content has been copied, which is covered in "What happens to mail that arrives after migration?", and a short list of things nobody can repair automatically is left behind, covered in "What manual follow-up is left after cutover?". Both are the customer's rather than VaultMe's: VaultMe migrates content, and it does not close the source account, set up forwarding, or work through the follow-up that comes afterwards.

Projects with a personal destination also tend to be small and clear-cut, so there is rarely a rollout to stage — the accounts in scope go in a single batch and are done, which is what "Choosing a migration strategy" recommends at that size. Planning at this stage therefore does not produce a procedure to run later. It produces one decision, what happens to each source account afterwards, and a short list of follow-up work with someone's name against it.

What happens to mail that arrives after migration?

Mail does not pause while a migration runs. Messages keep landing in the source account during the run and go on landing there afterwards, so the reasonable worry is that anything delivered after VaultMe started reading is stranded in the old account. 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 decision per account.

The run itself needs no plan. Every migration ends with a sync-up migration (delta migration) that VaultMe starts automatically — an incremental pass that copies whatever changed in the source account since the preceding run — so messages that landed while the initial migration was still working through the mailbox are collected at the end rather than missed.

What settles the question for good is not a VaultMe step at all: it is forwarding, turned on inside the source account. An account that is staying open can forward everything still sent to the old address on to the destination, so the old address goes on working with nothing left to run and nothing to remember. 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 it is arranged by whoever has access to the source account rather than in VaultMe.

Forwarding is not always in place the moment a migration finishes. Whoever has to set it up may be unreachable, or the account's future may still be undecided, 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, so a sync-up for a single account is a request to support@vaultme.com. The same run doubles as a last sweep shortly before an account is 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 pairs every migrated source item with the copy it created in the destination account, and a sync-up consults that index instead of guessing from message contents, names, or provider-side change signals, so items recorded as migrated and unchanged are not copied again while anything new since the last run is. That is what makes a second or third pass a top-up rather than a repeat of the whole mailbox, and the wider model is described in "How sync-up migration works". What does defeat it is starting a new migration in order to pick up newer mail: an index belongs only to the migration that created it, and VaultMe never inspects what is already in the destination account, so a fresh migration treats every message as new and copies the entire mailbox a second time.

The other way to end up with duplicates is to let forwarding and a sync-up overlap on the same account. A sync-up copies from the source without regard for what forwarding has already delivered, so anything that arrived while both were active lands in the destination account twice. Batch-level scope is what makes this a practical problem, because forwarding gets turned on account by account: if most accounts are already forwarding and one is not, a batch-wide sync-up would duplicate mail for all the rest.

Sync-up is built to bridge the gap between the migration and the point where the account holder is settled in the destination, not to keep two accounts aligned indefinitely. Each pass has to run within 30 days of the one before it, because that is how long VaultMe keeps the index, and every run refreshes it. There is a second reason not to lean on them: once the account holder is working in the destination, a later pass that re-applies a source-side change to an item it already copied overwrites whatever was done to that copy in the meantime.

What manual follow-up is left after cutover?

VaultMe copies content faithfully, but a few things cannot be carried across automatically. None of them are complicated, and none of them mean the migration went wrong — they only need to be expected, and to have someone attached to them.

• Links that point back at the source. VaultMe preserves links embedded in migrated content exactly as they were written and does not rewrite them to point at the copies it created. So a link inside a migrated message, file, calendar entry, or contact that referred to something in the source still refers to the source, and some of those links stop working once the source account is closed. This is expected behavior rather than a migration failure, so plan a pass over the ones that matter and update them by hand.
• Checking the destination against the source. VaultMe copies content instead of moving it, so the source account is left exactly as it was. That makes verification straightforward — open both and compare what matters most — and it makes the source a fallback for as long as it is worth keeping. Nothing forces the pace: the source account can stay untouched and be closed whenever whoever controls it decides.
• Tasks that belong to the account holders. Some of the finishing work can only be done by the person using the account, such as re-establishing sharing with the people who had access before, and pointing mail clients at the destination account. What to tell account holders, and when, is covered in "Preparing stakeholders and end users".

A checklist for the cutover

Nothing on this list is time-critical, and none of it has to be rehearsed. It is simply what to settle now so that finishing the migration is all that finishing the project takes.

1. Put forwarding first for late mail. Forwarding the source account to the destination address is the durable answer. The migration's own automatic sync-up migration (delta migration) covers the run, and an additional sync-up of the same migration covers the gap until forwarding is on — never a new migration, which would copy the whole mailbox a second time.
2. Decide what happens to each source account. Either keep it open with forwarding to the destination address, or close it once forwarding is in place or a final sync-up has cleared the tail.
3. Decide who owns the follow-up. Links that stop working, and the tasks only the account holder can do, such as re-establishing sharing and pointing mail clients at the destination — settle who works through them rather than assuming someone will notice.
4. Keep the source as a fallback until it is not needed. Compare the two accounts, confirm the content arrived, and close the source on whatever schedule suits the people who hold it.

With the cutover settled, the planning that remains is the schedule the whole project sits in, covered in "Planning the migration timeline", and the people it affects, covered in "Preparing stakeholders and end users".