Monitoring a migration

This article covers how to follow a batch while it runs: what the app reports about it, and what to do about what it reports.

What does monitoring a running migration involve?

Nothing is asked of you while a batch runs. Starting it was the last action the app required, and a run has no operator: there is no queue to work through, no next step to unlock, and nothing that stalls because you stopped watching.

Monitoring is therefore reading rather than intervening, and it comes down to two questions:

• Is everything going as it should?
• Is the batch going to finish on time?

Nearly everything an admin wants to know mid-run is one of those two, and this article answers both before turning to the single condition that needs you to act.

A migration is automated from start to finish and needs no supervision to run correctly, so monitoring one is optional: follow it as closely as you like, or leave it alone entirely. Where something does need a decision or an action from you — a migration left paused, for instance — VaultMe gets in touch rather than leaving you to discover it. That is uncommon, and the screen is there for when you want to know how a run is going rather than because something would otherwise go unnoticed. What that leaves for you to initiate is covered in "When should support be contacted?".

That sets how often to check: occasionally, out of interest, whenever it suits you. VaultMe emails you when the batch starts and again when it completes, and unless something along the way needs you, nothing arrives between the two.

One expectation is worth setting before you look at anything, because it accounts for most of the alarm admins feel mid-run: a healthy batch looks uneven. The user accounts in it were all started together, but each one migrates on its own schedule — some far ahead of others, some showing no visible movement for a stretch — and they finish spread out over hours or even days rather than together. Unevenness is how a run is designed to behave, not a symptom of anything, and "Is my migration going to finish on time?" starts from that.

Where a run does need something from you, it says so plainly, on the migration it concerns. That makes attention a single condition to check for rather than a state of alert to keep up, and that condition is the whole subject of "How do I tell whether something is wrong?".

Checking what actually arrived is a separate job that belongs after a migration completes rather than during it, and it is covered in "Reviewing migration results".

How do I check on a running migration?

A running batch is reported on the screen that opened when you paid for it — the same rows as before, now reporting progress instead of readiness. There is no separate surface to find for watching a run, nothing to reload, and no need to keep the page open: it updates in real time while you have it in front of you, and you can close it and come back days later.

What it is good for is the state of each migration in the batch, with a progress bar for each. Read it as a set of independent runs rather than one job advancing together — every migration started at the same moment, but each moves at the rate its own two accounts allow, and there is no combined progress figure for the batch as a whole.

Progress is reported at two levels, and the second exists because the first cannot carry everything:

• The batch screen answers how far along a migration is. Each row reports its migration's state and progress, alongside the duration estimate the pre-migration scan produced for it. That estimate is a fixed figure: it is what the scan measured before the run, and it does not move.
• A migration's details screen answers what that migration is working on. The short migration ID on the row opens it, and it reports that migration by content type rather than as a single percentage. It also carries the remaining time, which VaultMe can revise once it has seen how the accounts actually perform — the only figure in the app that moves during a run.

So there are two reasons to open a details screen: you want the per-content-type breakdown, or you want to find out why a migration has paused. It is informative rather than configurable, and it comes with one promise worth relying on — whatever state a migration is in is reported there, and where something is called for it says so.

Mid-run the app offers exactly one control: an individual migration can be paused and resumed again. The batch itself cannot be paused, nothing can be cancelled, and the accounts, content types, and organization options you chose are fixed from the moment you paid. Use the control for coordination — holding one account back while something is sorted out around it — and never for speed. Pausing and resuming does not make a migration finish sooner, and usually adds to the total run time, for the reasons explained in "Is my migration going to finish on time?".

Cancelling a batch, or changing anything inside one, is a support request rather than an action in the app. See "When should support be contacted?".

The batch screen also carries a Download reports action, and it is the one thing there that a run in progress cannot give you. A report covers a completed migration, so the first one becomes available when the first migration in the batch finishes, and reading them is covered in the migration report chapter of "Reviewing migration results".

Is my migration going to finish on time?

A run has a projected finish, never a promised one. VaultMe projects each migration's duration from what the pre-migration scan measured, then revises the projection as it observes how the accounts behave under real conditions. The answerable question during a run is therefore not whether the migration will hit a particular figure, but whether it is drifting away from the one you planned around.

Answering it is the only part of this that is app work, and it takes two readings. The estimate on the row is the scan's, and it stays put — that is the figure your schedule was built on. The remaining time on the migration's details screen is the live one. Comparing the two tells you which way the projection has moved and by how much.

That it moves at all is normal, and it is neither a fault nor something anyone can fix. Migration speed is set almost entirely by the source and destination providers: they cap how fast content can be read and written, those caps tighten and loosen as conditions change on their end, and VaultMe cannot bypass them — it simply runs as fast as they currently allow. What those limits are, why they exist, and how VaultMe works within them are covered in full in "What determines migration duration".

Drift usually shows up in the largest and most complex accounts. Item count, total size, and deeply nested structures all drive how long an account takes, and a single content type inside one can hold up that whole account. Those accounts also decide when the batch is done: migrations generally run in parallel, so a batch is not finished until its heaviest accounts are, however early the rest arrived.

No amount of time without visible progress means a migration is late or stuck. A quiet stretch is often a longer provider limit window that has to reset before work resumes, which can take hours on its own. Any threshold named here would be misleading, because it would prompt action on a run that is working as intended.

When a drift is real and large enough to matter, there is nothing to do about it inside VaultMe. There is no speed setting, no priority option, and no way around the providers' limits; pausing and resuming does not buy speed, it costs it. The response is to re-plan around the new finish. That goes easiest where the schedule keeps some reserve between the end of the run and the cutover, so a later finish can be absorbed without moving the switch itself — how much to keep there is covered in "Planning the migration timeline".

The boundary matters: late is not the same as wrong. A slow run is still a healthy run, and separating the two is a much shorter question, answered in the next chapter.

How do I tell whether something is wrong?

There is one signal, and it is deliberately narrow: a migration that has paused and says why. Everything else on the screen is a run in progress.

That narrowness matters, because the things admins most often read as trouble are not:

• A slow run, or a long stretch with no visible movement. Both are normal behavior, for the reasons explained in "Is my migration going to finish on time?".

• Accounts finishing far apart. Each migration finishes when its own content is done, so a staggered set of completions is the expected shape of a batch rather than a sign that the stragglers are in difficulty.

• A handful of skipped items. Items that cannot be copied are skipped and recorded rather than retried indefinitely, so the count may climb a little as a run proceeds. While it stays a tiny fraction of what the account holds, it is typical and largely unavoidable, and it belongs to the review after completion rather than to anything done mid-run — see the skipped items chapter of "Reviewing migration results".

  A count out of all proportion to the size of the account is a different matter. No figure marks the line, and nothing on the screen flags it, so this one is a judgment: a number that looks unreasonable for the content involved is worth raising with support while the run is still going rather than waiting to see it in the report, as described in "When should support be contacted?".

None of this is a watch you have to keep in any case. VaultMe monitors the runs itself and contacts you when something needs you, so this chapter is what to notice if you happen to look.

When you do see a paused migration, there is one move, and it is the end of the diagnosis: open that migration's details screen, where the condition is named. What to do with what it says is covered in the next chapter.

Nothing deeper than that is worth doing. Beyond the rough sense of proportion above, there is nothing to tally, no value in comparing one row against another, and nothing to be learned from reading a run for symptoms. Where the app has something to report, it reports it.

Why is a migration paused, and how is it cleared?

A paused migration is not a diagnosis you have to make. The reason is written on that migration's details screen in plain terms, and opening it is the whole of the investigation; how to reach that screen is covered in "How do I check on a running migration?".

What you do with what it says depends on one split:

• Conditions that are VaultMe's to clear. A provider limit that has to reset, a fault on a provider's side, or an operational problem in the migration itself. VaultMe already knows about these, is working on them, and clears them as soon as it can. Nothing is asked of you, and the migration continues once the condition is gone.
• Conditions that only the customer can put right. Something about the connected accounts that VaultMe cannot resolve from the outside. A lost connection is the usual one, but a destination account with insufficient storage or a service that has been switched off is the same kind of thing. The list is open-ended, because it depends on what changed in accounts VaultMe does not administer.

The route is the same either way, and it is the real answer to this chapter's question: the screen names the condition, you put right whatever is yours to put right, and anything you cannot place goes to support with the migration ID, as described in "When should support be contacted?".

One of these conditions deserves its own explanation, because it is by far the likeliest and the only one with a fixed shape. A migration needs live connections to both of its accounts — one to read from the source, one to write to the destination — and if either drops, the migration pauses until it is restored. What breaks a connection is almost always a change made on the provider side: a password reset or other credential change, a change to multi-factor authentication policy or to the verification factors of the identity behind the connection, or an administrative configuration change that affects VaultMe's access to the environment.

Restoring a connection is support-assisted. There is no reconnect control on the batch screen or anywhere else in the app, so the first step is writing to support; VaultMe takes part in the reconnection and resumes the migration once it is done. The legwork is yours, and it depends on how that account was connected in the first place, because an account has to be reconnected by the same method it came in through:

• An account connected with resource-level authorization repeats its connection link: send that account's link again and have the account holder open it and authorize access as they did originally.
• An account connected through admin authorization is reconnected through a temporary project. Create a new migration project with the same source and destination configuration, connect the same environments, add the affected accounts to it, and discard that project once the connection is restored. It exists only to carry the reconnection; nothing migrates in it and nothing is paid for. The two methods themselves are covered in the resource-level authorization chapter of "Choosing a connection method".

A paused migration does not sit forgotten, and it does not sit indefinitely either. VaultMe reaches out when one has been paused and nothing has been done about it, and no migration stays resumable forever: a paused migration can no longer be resumed thirty days after it stopped. That limit sits far beyond any realistic delay — it is reachable only if the contact about the pause went unanswered for a month.

The cost of a pause is smaller than it looks. Paused is not lost: the migration resumes from where it stopped rather than starting over, and nothing already copied is copied again.

None of this should come up on a run that was set up properly and left alone while it went. The conditions above almost all trace back to something changing in a connected account mid-run, and avoiding that is what the next chapter covers.

What should end users avoid while a migration runs?

This is a word of caution rather than an operational step, and one that should already have been handled: what end users are asked to avoid while their account migrates is settled before the batch starts rather than during the run, and is covered in "Preparing stakeholders and end users". It appears here because mid-run is when admins tend to check it again.

• End users should keep working in the source exactly as usual. A migration copies content rather than moving it, so normal activity in the source neither disturbs the run nor risks the content.
• They should stay out of the destination until their own account's migration completes. This is the one rule worth repeating, because working in a destination account that is still being filled is what causes the most avoidable trouble.
• They should not rearrange content that has already arrived. VaultMe replicates the structure it expects in the destination, and moving items out of it leaves the migration reconciling two versions of the same arrangement.
• They should not start a source-side cleanup or reorganization mid-run. Large-scale tidying belongs before or after a migration, not while it is copying a structure that is being rewritten underneath it.
• They should not change passwords or multi-factor authentication settings, or authorize new third-party apps, on a connected account. These are the changes that break a connection.

Two of these carry a consequence worth naming, because neither is visible at the time:

• Edits in the destination. These create reconciliation work: VaultMe may re-synchronize content it has already migrated or rebuild the structure it expected, which reduces throughput and pushes out the finish.

  They can also be undone later. When a sync-up migration (delta migration) applies a source-side change to an item, whatever was done to the destination copy in the meantime is overwritten, and whether that can be recovered from revision history depends on the destination provider. Sync-up passes are covered in "Running sync-up migrations".

• Credential and multi-factor authentication changes. These leave the migration paused and needing a support-assisted reconnection, as described in "Why is a migration paused, and how is it cleared?".

The rules have an expiry, and it is per account rather than per batch: they hold until that user account's own migration completes, not for the length of the whole run. Once an account is done, its holder can start using the destination normally even while other migrations in the same batch are still going.

When should support be contacted?

The expected answer inverts here. Most contact about a running batch goes the other way: VaultMe monitors the runs and writes to you when something needs you, so an admin who has heard nothing since the start email is, as a rule, fine.

There are three reasons to write in first:

• A named condition you cannot put right yourself. The details screen says what is wrong, but it is not something you can act on, or you are not certain whether it is yours to act on.
• A batch you need cancelled, or something in it changed. Neither is available in the app, so both are requests rather than actions.
• Anything on the screen that this article does not account for. Questions like this are welcome, and support can help you make sense of it — there is no need to work it out alone.

What to send is the whole of the ask: the batch ID or the migration ID, and what needs doing. Those short IDs — one for the batch, one for each migration in it — are what support works from. Screenshots of what you are looking at can be helpful. Write to support@vaultme.com.

Cancelling is worth one more line, because it is the request with a cost attached. It is not an in-app action, and its commercial consequence landed when you started the batch rather than now — a paid batch that had not yet started was still eligible for a full refund, while a started one is not. The policy is set out in the cancellations chapter of "Pricing and payment".

Once the last migration in the batch completes, the job changes: there is nothing left to watch, and what remains is verifying what arrived, which is covered in "Reviewing migration results".