Running sync-up migrations

A sync-up migration carries changes made at the source into the destination after a migration run has finished. This article covers the additional passes you run yourself on a batch that has already migrated.

What does running a sync-up migration involve?

Very little. VaultMe runs the first sync-up migration (delta migration) automatically at the end of every migration, so the changes made at the source while the run was going are already in the destination before anyone reads the result. Anything beyond that first pass is one control on the batch screen and a confirmation — nothing to configure, nothing to select, and no second setup to work through.

An additional pass exists for the gap between two dates: the day a migration finishes and the day the customer actually switches over to the destination. The source stays in daily use across that gap, so mail keeps arriving and files keep being edited, and none of it is in the destination, because the run copied each account as it stood when VaultMe indexed it. A pass brings that later change across, which is what makes it possible to finish a migration weeks before the switch and still hand over a current destination on the day.

Passes are run over a batch rather than over one account you single out. The control takes every migration in the batch that is no longer processing, so a batch that is partly through can have a pass run over the accounts that have already completed, and a batch that is fully through gets a pass over all of it.

A pass of reasonable size carries no separate charge. Sync-up is part of what the batch was already paid for rather than a run billed on its own, and how that sits in the wider pricing model is covered in "Pricing and payment".

What happens inside a pass is a subject of its own, and this article leaves it there: how VaultMe recognizes which items changed, why an item that has not changed is never copied a second time, and what limits a single pass are covered in "How sync-up migration works".

Running a pass also assumes a result you have already looked at. Reading what a run produced comes first and is covered in "Reviewing migration results", while the last pass of all belongs to the end of the project and is covered in "Wrapping up the project".

When should a sync-up be run?

Of all the sync-up migrations (delta migrations) a project runs, the one that matters most is the last: the pass run once the customer has actually switched over — mail routing pointed at the destination where the customer controls it, and the account holders working in the destination from then on. Everything that reached the source before that moment is still only at the source, and this is the pass that brings it across. Running it after the switch rather than before is the whole point, because a pass run the day before leaves a fresh day of content behind it.

Before that one, passes are optional, and how many are worth running follows the length of the project:

• A short project needs none. Where a batch is migrated and cut over within a few days, the automatic pass and the final one cover the whole of it, and a pass in between would find little to copy.
• A long or phased project benefits from periodic passes. Where weeks separate the run from the switch, a pass every so often keeps the destination roughly current, so the final one has an ordinary amount of work to do rather than a season's worth. It also keeps alive the index a later pass depends on — see "What can stop a sync-up from running?".

However many the project needs, each one is a manual act. Nothing in VaultMe schedules a pass, none starts on its own after the automatic first one, and no setting makes them recur, so run as few as the project genuinely calls for.

One timing rule holds whatever the shape of the project: run passes before end users settle into the destination, not after. When an item changes at the source, VaultMe rewrites the destination copy it created from the source version, and anything anyone did to that copy in the meantime is overwritten. While people are still working at the source and only looking at the destination, that costs nothing. Once they are working in the destination for real, a pass can undo what they have done there.

Where these passes fall relative to the switch itself is a planning decision rather than an app one, and "Planning the cutover and domain switch" covers it. Once the cutover is done, stop. Sync-up is there to bridge the gap between the run and the switch, and passes run past that point become steadily more conflict-prone, because by then the destination is the account people work in and the source is the one standing still.

How is an additional sync-up started?

An additional sync-up migration (delta migration) is started from the same batch screen the run itself was started from, and there is nothing to set up on the way.

1. Open the batch from your workspace's migration history.

2. Select Sync Up.

   The control is available once the batch has migrations that are no longer processing, and it takes all of them together. A pass for one account on its own is not something the app does; if you need one, write to support@vaultme.com.

3. Read the confirmation panel and confirm.

4. Follow the pass while it runs.

   Watching a pass is the same job as watching the original run, and "Monitoring a migration" covers it.

Each completed pass rebuilds the migration report for every migration it covered. Only the most recent report can be downloaded, but a rebuild is cumulative rather than a record of the pass that produced it, so the newest report is the complete one and nothing from an earlier version is lost — the report chapter of "Reviewing migration results" covers how to read it.

What does a sync-up copy, and what does it leave alone?

A sync-up migration (delta migration) copies what has changed in the source since the previous run, and only that. Four cases cover everything a pass does:

• New items at the source. Anything created since the last run is copied into the destination and placed by the same rules the original run used, so it arrives where content from the same place arrived the first time.
• Items that changed at the source. Where an item VaultMe already copied has been edited, the edit is applied to the copy in the destination. The same goes for an item that has been filed somewhere else since the run, and for details such as a name or a status, as far as the destination provider can represent them.
• Items deleted at the source. The copy in the destination stays. A pass does not mirror deletions, so clearing something out of the source after the run does not clear it out of the destination.
• Edits made in the destination. These are the ones to know about, because a pass can overwrite them. When a source item changes, its destination copy is rewritten from the source version, and any change made to that copy at the destination is lost. Where the destination keeps a version history for the item, the earlier state can sometimes be recovered from it. For a file, Google Drive's version history is the place to look.

The shape behind all four is worth holding on to: change flows one way, from source to destination, and a pass is not a reconciliation of the two sides. VaultMe reads the source, works out what differs from what it copied before, and writes that difference. It never reads the destination to work out how to make the two match. That is also why content that arrived in the destination directly — mail delivered there after routing was switched, or anything an account holder created there — is never touched by a pass.

How VaultMe knows which items changed, why a pass never duplicates what is already in the destination, and what the design gives up in exchange are covered in "How sync-up migration works".

What can stop a sync-up from running?

A sync-up migration (delta migration) depends on what the run before it left behind, which gives it conditions the original run did not have. In practice, three things get in the way.

• A connection that has dropped. A pass reads the source account and writes into the destination account, so both connections have to be live, and a pass cannot be started while either is broken. A connection that lapsed quietly in the weeks after the run is the usual reason a pass does not go through. It is the same condition that pauses a migration mid-run, and the paused-migration chapter of "Monitoring a migration" covers how it is cleared.

  If a pass was started before anyone noticed, it has to be stopped before anything else can happen, and stopping it is support-assisted: write to support@vaultme.com. Once the connection has been restored, the pass is started again for the batch exactly as before.

• An index window that has lapsed. VaultMe keeps the index a pass works from for 30 days after the most recent completed run, whether that was the original migration or the last pass, and a pass completed inside that window starts the clock again. Once it lapses there is no pass left to run: later source-side changes have to be handled by hand from the source, because migrating the same accounts again produces a second copy of everything rather than filling the gap. On a project that will run for months, keeping that window open is the reason to run periodic passes at all.

• An unusually large volume of change. Where the amount of change at the source goes far beyond what a pass is meant to carry, VaultMe support can cancel that pass rather than let it run.