Wrapping up the project

By the time a batch has been reviewed, almost nothing that remains happens inside VaultMe. This article covers the closing steps, the order they belong in, and who owns each one.

What does wrapping up a migration project involve?

The run is finished and the result has been checked, so what is left is short — and most of it is not work inside VaultMe. At this point the batch screen offers three things and no more: another sync-up migration (delta migration), the reports, and the invoice. Everything else happens in your own environment, in the destination accounts, and in conversations with the people who use them.

What the remaining steps do have is an order, and that order is what this article is mainly about. Each closing act gives up a fallback. Revoking VaultMe's access ends any further sync-up pass until the accounts are connected again. Retiring the source removes the only thing there is to verify against, and with it any possibility of redoing the migration. None of the steps is difficult or long on its own; the trouble comes from taking one of them before the thing it was protecting is finished.

So the default for everything below is to hold on to things for a while. Nothing expires the day the run finishes, and waiting costs nothing in VaultMe: the batch is already paid for, additional sync-up passes carry no charge, and leaving the accounts connected has no price attached either.

Two things do run on a clock, and both are worth knowing about now even though each belongs to a chapter of its own:

• The window behind another sync-up. A further pass is possible only while VaultMe still holds the index that pairs each migrated item with the copy it created at the destination, and that window is kept open by running sync-ups rather than by waiting. It is what attaches a deadline to the cutover date, which is the subject of "When is it safe to cut over?".
• Report retention. Migration reports are kept for a year after the run that produced them, and they are the only record of what became of each individual item. Downloading them is the one closing step with a date of its own against it — see "What should be saved before retention periods end?".

The division of labor over this period is worth stating plainly, because it is not the one the rest of this section established. Until now VaultMe did the work and you supervised it. From the last sync-up onward that reverses: the switch itself, the tidying inside the destination accounts, and the decision about the source are all yours, and VaultMe's part is finished. What the switch involves, and the plan it should be following, belong to "Planning the cutover and domain switch".

This article takes two things as given. The first is a result that has already been reviewed, which is covered in "Reviewing migration results". The second is that this period was budgeted for while the schedule was being built rather than discovered now — see "Planning the migration timeline".

Closed out, a project ends in a recognizable state: the destination in day-to-day use, every remaining manual item owned by someone with a date against it, reports saved somewhere outside VaultMe, VaultMe's access revoked, and the source retired whenever your organization is ready for that.

When is it safe to cut over?

The call is yours, and it is made from the review rather than from anything the app reports. A batch that reads as completed is telling you that VaultMe finished its work on every migration in it: it indexed the content in scope, processed what it found, and recorded an outcome for each item. That is a different statement from the result being right, and only the first of the two is something VaultMe is in a position to make. What completion does and does not claim is covered in "Reviewing migration results".

So the gate on the cutover is the review, and in particular the half of the review that cannot be done from your desk: the account holders opening their own destination accounts and confirming that the content they rely on is there. Until those answers are in, nothing has established that the destination is fit to become the live side. That half is covered in "Reviewing migration results".

Once the answers are in, the order of the last two steps matters more than the hour they happen in. The switch comes first and the final sync-up migration (delta migration) after it. The switch is the point where new mail starts being delivered to the destination accounts instead of the source ones. A sync-up run the day before the switch leaves a tail behind it — everything that reached the source in the hours between the pass and the switch — while one run after the switch has nothing left to miss. The reasoning behind that sequence is in "Running sync-up migrations".

Two conditions have to still hold on the day, and they are exactly the ones the closing steps below take away: both sides still connected, and the index behind the batch not yet lapsed. That is why revoking access and retiring the source belong after the final pass rather than alongside it. What else can stop a sync-up from running is listed in "Running sync-up migrations".

How much of an exercise this is scales with the project. A single small batch is reviewed and switched inside a week, and the cutover itself is an evening's work. A phased project runs one finale after its last batch rather than a cutover per wave, and by then the sequence should already be written down — the checklist for it is in "Planning the cutover and domain switch".

After the switch, stop running sync-ups. The destination is the live side from that point, and a pass that carries a source-side change onto an item somebody has since edited at the destination overwrites that edit. The final pass is the last one for a reason.

What manual work is left in the destination?

This chapter is a register rather than a set of instructions: what is typically still outstanding once a migration is done, and who owns each item. None of it should be a surprise at this stage, because every one of these items was foreseeable while the project was being planned and should already have a name against it — see "Planning the cutover and domain switch".

• Items parked in a TODO area. Content that migrated but could not be placed where it belonged is left in a clearly marked area inside the destination account rather than dropped or filed on a guess. It arrived; what it needs is filing, and the account holder is the only one who will do it, because nothing later moves those items — not VaultMe, not a subsequent sync-up. What these areas hold and how to work through them is covered in "Reviewing migration results".
• Links embedded in migrated content. VaultMe preserves links exactly as they were written instead of rewriting them to point at the destination, because rewriting them would alter the content it was asked to copy. The consequence is that links aimed at the source stop working at cutover, and stop working permanently once the source is retired. Reviewing the few that matter is worth the time; reviewing all of them is not.
• Skipped items that are still wanted. A skipped item is a terminal outcome for that item under the configuration that produced it, so neither a re-run nor a later sync-up revisits it. Anything worth recovering is recovered by hand from the source, which means doing it while there is still a source — see "Reviewing migration results".
• Re-sharing, client reconfiguration, and the holders' own tidying. Content shared from the source has to be shared again from the destination, mail clients and mobile devices have to be pointed at the new account, and each holder has their own small pile of arranging to do. This is end-user work, and the groundwork for it was laid during preparation — see "Preparing stakeholders and end users".
• Shared-drive content. A shared drive is migrated inside the file migration of a connected user account that had access to it, so what it held arrives in that account rather than in a shared drive of its own at the destination. Placing it where it belongs is manual, and it needs an owner and a date like everything else on this list. Where it lands is covered in "Connecting and adding user accounts".

Your own part in this is small and administrative: give each item an owner, and give the list a closing date. That date carries more weight than it looks, because retiring the source waits on this list — see "What happens to the source afterwards?".

On a small, clean batch none of this is a workstream. It is a short note to a handful of account holders, and most of them will have nothing to do.

How is VaultMe's access revoked?

Revoking access is the closing step that is awkward to undo, so the order matters here more than the mechanics do: revoke after the last sync-up migration (delta migration), never before it. With no live connection there is no further pass, and getting one back is real legwork rather than a click — accounts have to be reconnected by the same method they were connected with originally. What a lost connection costs is set out in "Running sync-up migrations".

Where revocation happens is worth stating plainly, because admins tend to look for it in the wrong place: not in the app. VaultMe has no control that disconnects a workspace's accounts in bulk, and the list of connected accounts you are looking at there is not where access ends. It is withdrawn on the provider's side instead.

Where a whole environment was connected, the grant is withdrawn once, in that environment's own administration console, and doing so ends VaultMe's access to every account that was connected through it. This is the usual route, and the reason revocation is normally a single act rather than one per account.

An account that was connected on its own, by opening a connection link, is revoked through the provider's own controls for that account, by whoever authorized it in the first place — usually the account holder. That makes it a request per account rather than a single action, which is worth knowing before the closing steps are scheduled.

What revocation does is end VaultMe's ability to read from the source accounts and write to the destination accounts, and that is the whole of it. Migrated content stays in the destination accounts, the migration reports stay downloadable for the rest of their retention window, and the workspace's record of the batch stays where it is. What revocation reaches is covered in "How VaultMe protects migration data", and what a connection was in the first place in "How VaultMe authentication works".

It also does not empty the VaultMe workspace. Connected accounts accumulate there across projects and cannot be removed, so the list still names every account you ever connected, revoked or not. That turns out to be useful rather than untidy, for the reason "What carries over to the next batch?" explains.

On a phased project, hold the environment grant until the end of the project rather than the end of a batch. Later waves are still drawing on it, and revoking after one wave means connecting the environment again for the next.

When to revoke is a judgment call, and the answer is deliberately not the same afternoon as the cutover. Do it once ongoing support from VaultMe is no longer wanted — after the destination has carried real use long enough that nobody is still turning up gaps, and after the last sync-up anyone might ask for has run. Leaving a connection in place for a few weeks costs nothing; taking it away early costs a connection restoration before anything further can run.

What should be saved before retention periods end?

There is one action in this chapter: download every migration report and keep the files somewhere outside VaultMe. A report is the only place an individual item's outcome is recorded — where it ended up, or what stopped it — and neither the app nor the destination account answers that question later. How a report is organized, and what it will and will not tell you, is covered in "Reviewing migration results".

The reason to do it now rather than eventually is that reports are kept for a year rather than indefinitely. The year is counted from the end of the run that produced the report, so for a batch that ended with a sync-up the clock starts at that final pass rather than at the original migration. A year outlives the project by a long way, which is why this is never urgent — but it does end, and the record ends with it. Retention for reports and for VaultMe's own operational logs is set out in "Where migration data is stored and how long it is kept".

One download per migration is enough, and it should be the last one. Each sync-up rebuilds that migration's report, only the most recent version is offered for download, and a rebuild covers the whole migration rather than the pass that produced it — so the copy taken after the final pass is the complete one and supersedes anything saved earlier.

It is worth separating the other clock from this job, because the two are easily confused. The index that makes another sync-up possible expires too, but it is not a record anyone can keep, export, or download; it is internal machinery, and the only thing that extends it is running another pass. What that means in practice is in "Running sync-up migrations".

Worth pulling in the same sitting: the batch's invoice, downloaded from the batch screen, which is what whoever keeps your books will ask for. How invoices work is covered in "Pricing and payment".

That tends to raise an obvious follow-up question, so it is worth answering here. Once the temporary migration data, the index, and the reports are gone, what stays with VaultMe is a high-level record of the transaction — when the migration ran, between which accounts, how much content it moved, and what was paid. It holds no content and nothing derived from content, such as file names or message subjects, and it is described in "Where migration data is stored and how long it is kept". Earlier deletion of migration-related data can also be requested, which is covered in "Where migration data is stored and how long it is kept".

What happens to the source afterwards?

Nothing, unless your organization does it. VaultMe copied content out of the source accounts rather than moving it, changed nothing there while it worked, and offers no feature for emptying, restricting, or retiring a source. Whatever was there before the migration is still there afterwards, arranged the way it always was.

That is what makes the source the cheapest insurance the project has, and the argument for retiring it in stages rather than in one act. Make it read-only first, so nothing new accumulates there and nobody is quietly working in two places. Withdraw licenses next, once the destination has carried real use for a while. Decommission last, when nothing has been raised for long enough that you would be surprised to hear anything now.

Four things should be true before it goes: the review is closed, the account holders have answered, the manual follow-up list has been worked down, and nothing is left that might need redoing — see "How is a migration redone if something went wrong?".

The reason to be deliberate about it is that retiring the source takes three things away at once, and all three are invisible until they are gone:

• The only thing there is to verify against. VaultMe never inspects the destination and never re-reads the source to compare the two, so checking whether something arrived means looking at the source. With the source gone, a question about missing content has nowhere to be answered.
• Any further sync-up. A sync-up migration reads the source, so no source means no pass, whatever the index still holds.
• Any redo. Re-migrating starts from source content, which makes retiring the source the point where that option closes permanently.

The other side of the argument deserves a sentence, because keeping the source forever carries a cost of its own. After the last sync-up the two sides are fully independent: nothing flows between them, and nothing at the destination reflects a later change at the source. A source left running is therefore a second live copy that people can go on using, splitting work across two systems without anyone deciding to — which is exactly what making it read-only prevents.

The schedule itself, and any legal or retention hold that governs it, are your organization's to set, and they were settled during planning rather than now — see "Planning the cutover and domain switch".

How is a migration redone if something went wrong?

A redo is almost never the answer, and that is worth establishing before anything else. The problems that prompt the question each have a route of their own, and none of those routes is a re-run: an item skipped with a reason is handled by hand from the source, content that appears to be missing is usually somewhere else in the destination, and content that arrived but landed in the wrong place is filed rather than migrated again. All three are covered in "Reviewing migration results".

Nor is a sync-up migration (delta migration) a repair. It revisits what changed at the source since the last run; it does not revisit what VaultMe could not do the first time, because those source items have not changed — see "Running sync-up migrations".

So before treating a redo as the answer, write to support@vaultme.com with the batch ID and two or three specific examples: an item's name or subject, and the account it belongs to. A redo is a new batch, priced like any other, which makes it worth establishing that one is genuinely needed.

The fact that shapes everything else about a redo is that VaultMe does not inspect what is already in the destination accounts before writing to them. It does not detect content an earlier migration placed there, whether that migration was one of its own or another tool's, and it does not resume or merge with it. Migrating the same accounts again therefore writes a second, independent copy of everything rather than filling in the gaps left by the first attempt. The earlier copy has to be cleared out of the destination accounts by hand before the new run starts, and that clearing, rather than the migration, is the real work in a redo.

Procedurally the redo itself is unremarkable: a fresh project with the same accounts, a new batch, paid for in the usual way. It is quick to stand up for anyone who kept the account list outside the app, because the source and destination pairs paste straight in — see "Connecting and adding user accounts".

What makes a redo possible at all is exactly what the closing steps take away: an intact source to read from, and live connections on both sides. That is the strongest argument for the staged retirement in "What happens to the source afterwards?", and for not revoking access on the afternoon of the cutover.

What carries over to the next batch?

On a single-batch project this chapter is the end of the work. On a phased one it is the hand-back: the wave just closed out leaves things behind that the next wave starts from, and one thing it deliberately does not.

Three things persist in the workspace once a batch is done:

• The connected accounts. Every account that has ever been connected stays in the workspace, which means the expensive half of setting up a wave is already done for any account that took part in an earlier one. A later wave drawing on accounts that are already there needs no connection legwork at all — no environment to connect, no links to send, no account holders to chase.
• Every batch, with its history. Batches stay listed with their sizes, statuses, and timestamps, and each one still opens onto the migrations inside it, so a finished wave stays readable long after it ran.
• The invoice details. Whatever was entered for an invoice is stored on the workspace rather than on the batch, so it comes back prefilled on every invoice after the first and is changed only by overwriting it.

What does not persist is the project. A project under configuration lives in your browser rather than in the workspace, only one exists at a time, and paying for it clears it and frees the slot. For a phased rollout that sets a cadence rather than a limit: each wave is configured after the previous one has been paid for, and waves cannot be staged in advance — see "Creating a migration project".

Which leaves one artifact genuinely carrying the project forward, and it is not in the app: the account list kept outside it, as source and destination pairs. Kept current as accounts are added, dropped, and reassigned along the way, it is what turns the next wave's setup into a paste, and what makes a lost draft or a colleague picking the work up a non-event. How it is used is covered in "Connecting and adding user accounts".

The other thing worth carrying forward is what the finished wave taught you: how long the accounts actually took against the estimate, and whatever surprised you. Written back into the plan for the remaining waves — a batch resized, a difficult account moved later, a content type handled differently — that is worth considerably more than remembering it as a story. Where it belongs is "Choosing a migration strategy".

Once the last wave is closed out, nothing further is asked of you in the app. The batches stay in the workspace for as long as you want to look at them, and the project is over.