Running the pre-migration scan

VaultMe checks every user account in a project against the migration you have configured and reports whatever stands between that configuration and a run that can start. This article explains what those checks cover, what they hand back, and how the work they raise is cleared.

What does the pre-migration scan involve?

On a small, well-prepared project the scan asks nothing of you. Item counts and sizes fill in against each user account, a price and a duration appear, and the project is ready to pay for.

What the scan does is test the feasibility of the migration as you have configured it. It is not a quality check on the content: it does not judge whether an account holds anything worth migrating, or whether its folders are tidy. It asks whether the migration you have described can actually be carried out — whether VaultMe can reach each account, whether the services behind the content types you included are switched on, how much content there is, and whether the destination can hold what is about to be written to it.

The order behind that is worth knowing, because it explains most of what the project screen then does. You state the migration you want, and VaultMe reports what stands between that and carrying it out. So a freshly configured project that comes back with a list of things to do is the normal case rather than evidence that something has gone wrong; the findings are the scan doing its job.

Two things come back from it:

• Work to do. Each check that did not pass becomes a to-do against the account it concerns, and VaultMe groups the same to-do across accounts into a pending action. Both are defined in "What is a to-do, and what is a pending action?".
• Measured numbers. Every included content type reports an item count and a size, and those figures are what the project's price and duration estimate are calculated from, as covered in "What do the price and duration figures mean once the scan has run?".

There is no button that starts the scan and nothing to schedule. It runs by itself as accounts arrive in the project and keeps running as the list grows, as "When does the scan run?" describes.

Everything it finds has to be settled before the project can be paid for, and that gate is project-wide rather than per account: one to-do anywhere holds up all of it. The chapter "Why does one unresolved to-do hold up the whole project?" explains why it works this way and what to do when it stops you.

This stage takes over where "Connecting and adding user accounts" ends, with every source account connected and paired with a destination. It finishes when every check has passed and the price you will actually be charged is on screen, at which point the project moves on to "Paying for and starting a batch".

When does the scan run?

There is no control that runs the scan. Adding a source user account starts a round of checks, and so does assigning a destination to one, so a list assembled account by account is scanned continuously as it grows rather than in a single pass once you have finished. Edits that take something away — removing an account, unassigning a destination — start nothing.

The practical consequence is worth acting on: assemble the project as early as you can. Because findings surface as accounts arrive rather than at the end, an early project gives you its to-dos while there is still time to reach the people who have to clear them.

Rounds are incremental. VaultMe scans the gap between what it already knows about an account and what it now needs, not the account from scratch. An account first scanned as a destination has had its services and its available storage established but not its content sized; adding that same account as a source later runs the extra measurement on top of what is already known instead of repeating everything. The same holds when a content type that could not be reached becomes reachable, usually after permissions are fixed — only that type is measured.

Results are cached for 24 hours, per account and independently of the rest of the project. Inside that window an account removed from the project and added back again is not rescanned, which is what makes rebuilding a lost draft cheap: the accounts return with their findings already attached rather than queueing up behind a fresh round of checks.

Reconnecting an account is not the same as rescanning it. What the cache holds is what was measured, not how the account is connected, so a new round runs only when something the project now requires is still missing.

Where you do need to force a round, select the accounts in the grid and use Re-run checks. This is for work done outside VaultMe that the app has no way of noticing — a license assigned, storage provisioned, a service switched on — where nothing about the account has changed as far as VaultMe can see.

While a round is in progress the project reports that checks are running, and each content type reports its own state. Source-side and destination-side readiness are reported separately, so an account can read as ready on the source side while its destination side is still outstanding. A count of outstanding work read while checks are still running is therefore a floor rather than a total, and more can appear as the remaining checks finish. Large accounts also take longer to measure than small ones, so on a project holding a few very large mailboxes or drives the figures arrive unevenly.

What does the scan check?

The scan is the preparation work being marked. Each concern below corresponds to something that was decided or set up before the project existed — user accounts connected with the permissions the migration needs, services activated, storage provisioned — and this is where those readiness tasks are verified against the real accounts instead of assumed. Where a finding sends you back to that work, "Getting the source ready" and "Getting the destination ready" describe it in full.

Two things locate any given check. The first is which side it examines: source and destination are checked and reported separately for each content type, which is why one side can pass while the other still has work outstanding. The second is what it is scoped to — the account as a whole, or one content type within it — and that scope is what decides which resolutions you are offered, as "How can a to-do be resolved?" describes.

Beyond that, every check addresses one of five concerns:

• Access. Whether VaultMe holds the permissions it needs on the account. This is anticipated by connecting each account with the full set of permissions VaultMe asks for, and resolved by reconnecting the account where it was not — the common ways that happens are covered in "Connecting and adding user accounts".
• Availability. Whether the service behind a content type exists and is switched on for the account at all. VaultMe establishes this by reaching for the service with the access it already holds, and reports the content type as unavailable when it cannot.
• Measurement. Whether the content has been scanned and sized. There is nothing to prepare here, but there is something to allow time for on large accounts, because the price, the duration estimate and the capacity concern all wait on the figures. See "What do the price and duration figures mean once the scan has run?".
• Capacity. Whether the destination has enough storage for what is about to be written to it. This is anticipated by provisioning destination storage ahead of the migration rather than during it.
• Readiness. The roll-up of the others for one account and one content type. This is the state you see in the grid without expanding anything.

Availability reports a symptom rather than a cause, and it is worth knowing that before you start on one. A missing license, API access switched off, and a service disabled at the organization or the account level often look identical from outside the account, so VaultMe reports that the content type could not be reached and leaves you to work through the candidates on the provider side.

The first three concerns build on one another in that order. Without access, VaultMe cannot tell whether a service is available, and a content type that is not available cannot be measured. A check that is blocked therefore tends to leave the ones behind it with nothing to report yet, rather than reporting them as needing action too — which is why clearing one access to-do often resolves several unknowns at once.

Every account in a project is subject to the same set of checks, and that is what makes a count comparable from one account to the next: two accounts each reporting two to-dos have the same amount of work outstanding, whatever it turns out to be. Which concerns apply at all depends on the pair being migrated — a destination with no storage constraint raises nothing under capacity — but within one project the set does not vary from account to account.

Finally, the scan measures rather than reads. It counts and sizes content, and it collects no file names, message subjects or item identifiers; the figures are all that is kept from a round. What VaultMe touches, both at this stage and during the run itself, is covered in depth in "What data VaultMe processes during migration".

What do the price and duration figures mean once the scan has run?

The measured figures appear in the project's summary strip: the item count and size of the content included in the project, Total price, and Approximate duration.

Every figure in the project up to this point has been built from guesses — an account count, a rough idea of how much mail each holds. These are calculated from content VaultMe has measured in the actual accounts, which makes this the first point in the project where the price you will be charged is known rather than approximated. Reaching it costs nothing: setup and scanning are free, and payment comes only when you convert the project into a batch.

How the figures arrive is worth understanding, because they do not all appear together:

• The price does not wait for a destination. A scanned source account is enough for it to appear, so a project can report a price while some rows still have no destination assigned to them.
• The price accumulates in two parts. An account's base fee counts from the moment the account is added to the project, and its data fees follow when its scan completes. A freshly added account therefore raises the price before it raises the content figures, which is expected rather than a miscalculation.
• The duration appears on the same trigger as the price. One scanned source account is enough, and no destination is required.
• Both stay blank until something has been measured. An empty project, or one whose accounts are all still being scanned, reports neither.

The content figures follow what is included in the migration rather than how many accounts the project holds, and the two are reported separately for exactly that reason. Excluding a content type for an account lowers Included content size and Total price and leaves Project size untouched, because that account is still being migrated — just with less of its content.

That relationship is what to reach for when a price comes back higher than you expected. The answer is almost always scope, and the project screen is where scope is changed: which content types are included, and for which accounts. "Choosing migration options" covers that decision, and content scope stays editable for as long as the project is a draft.

The totals also follow the selection. Select a range of accounts in the grid and the summary reports on that range rather than on the whole project, which is how you size a group before deciding what to do with it — what one department will cost, or how long the ten largest accounts will take.

What the price is made up of and when payment is due are covered in "Pricing and payment". For what drives the duration figure and how far to trust it as a schedule, see "What determines migration duration".

What is a to-do, and what is a pending action?

The two terms are a distinction of scope and nothing else:

• A to-do is one check that did not pass, against one user account.
• A pending action is that same to-do gathered across every account that has it, so the condition can be dealt with once instead of account by account.

A pending action is not more serious than a to-do. It is wider, and that is the whole of the difference: a pending action reported against forty accounts is not forty problems of a graver kind, it is one condition that forty accounts happen to share.

A to-do is usually narrower than an account. Most are scoped to a single content type within one account, so an account can be perfectly healthy for its mail and blocked for its files. A to-do covers the whole account only when what it is about belongs to the account rather than to one content type — the connection to the account itself, for instance, which everything else depends on.

There are two ways into the same work, and both are normal:

• Top down, from the project status, which reports how many pending actions are outstanding and opens the list of them. This is how you find work you did not already know about, and it is described in "How is the same to-do cleared across many accounts at once?".
• Bottom up, from a row in the grid that caught your eye. VaultMe then tells you how many other accounts share the same to-do, so an admin who started with one account learns straight away that it is really a pending action. That route is covered in "How are to-dos found and cleared in the app?".

How can a to-do be resolved?

Every to-do has exactly two kinds of resolution, and VaultMe always offers both: satisfy the requirement, or take the thing that needs it out of the migration. There is no third outcome, and nothing can be left undecided — a to-do you have not settled one way or the other still holds up the project, as "Why does one unresolved to-do hold up the whole project?" explains.

The order they are offered in is deliberate. The ways to make the content migrate come first, and the way to stop needing it comes last. VaultMe presents both and chooses neither, because which one is right is a judgement about the migration rather than about the app.

What you are weighing is a trade between two costs. Fixing costs coordination: reaching an account holder, redoing a connection, provisioning storage, waiting on a change someone else has to make. Narrowing costs content — whatever you exclude will not arrive at the destination, and nobody will find it there later.

What the last option can be depends on the to-do's scope:

• A content-type-scoped to-do can be resolved by excluding that content type for that user account. Everything else about the account still migrates, which makes it a smaller decision than it first sounds: an account whose calendars cannot be reached can still migrate its mail, files and contacts.
• An account-scoped to-do has nothing narrower to drop. The choice is to satisfy the requirement or to take the account out of the project altogether. Removal is not offered where the to-do is raised; select the row in the grid and use Remove in the action bar instead.

Excluding reaches wider than the to-do that prompted it. It dismisses every issue tied to what was excluded, not only the one you had open, so a content type excluded because its service is switched off stops raising anything about permissions or storage for that type either.

The consequence of all this is that no project is ever permanently stuck. Because anything that raises a to-do can also be dropped, a project can always be brought to a state where it will run. The worst case is not a project that cannot migrate; it is a project that migrates with less in it than you originally planned.

Excluding content is also a pricing decision, which is easy to miss at the moment you are using it to clear a to-do: it lowers the included content size and the price without changing how many accounts you are paying for, as "What do the price and duration figures mean once the scan has run?" sets out. Content scope stays editable for as long as the project is a draft, so a content type excluded to get past a to-do can be put back if the underlying problem is solved before payment.

Who has to be involved in resolving to-dos?

What decides how long a to-do takes is rarely the to-do itself. It is who can clear it, and whether that person is you.

• You, inside VaultMe. Excluding a content type, removing a user account, re-running the checks. These are immediate, they involve nobody else, and this is the only group with no waiting in it.
• You, in the provider's own administrative console. Whatever is controlled centrally for the environment an account belongs to: licensing, switching a service on, raising a storage allocation. This needs administrative access to that environment and sometimes a purchase, so it takes an afternoon rather than a minute. "Getting the destination ready" covers the destination-side work of this kind.
• The account holder. Whatever sits inside the account and cannot be reached from a console. Connecting the account is the common case, since a connection link has to be opened, signed in to, and confirmed back — see "Connecting and adding user accounts". Deleting content from a mailbox or drive with no storage left is another.

Which of the last two groups a to-do falls to is decided by what you control centrally, not by which concern it belongs to. The same capacity finding is your own job where a quota can be raised from a console, and the account holder's job where the only way to free storage is for them to delete content or buy more.

The account holder group is the long pole on every project, and it behaves differently from the others. Nothing notifies you when someone has completed their part: there is no message when a connection link is used, and no marker against the account. That work is chased rather than awaited, so start those to-dos first, tell people plainly what you need from them, and work through whatever you can settle yourself while you wait.

Why does one unresolved to-do hold up the whole project?

Paying for a project is what converts it into a batch, and the conversion takes the project whole. A batch cannot be created from a subset of a project's user accounts, so Schedule migration stays unavailable while anything is outstanding anywhere. One to-do, against one content type, on one account, holds up every other account in the project.

The thing admins reach for at this point — migrate the accounts that are ready now and deal with the rest later — is not available inside one project. There is no way to carve the ready accounts out and run them while the others wait.

What that actually calls for is a smaller project. Take the accounts that are not ready out of it, migrate the rest, and build the next project for the remainder once they are ready. This is not a workaround: it is how a phased rollout runs in any case, as the chapter on splitting a rollout into batches in "Choosing a migration strategy" describes. Rebuilding a project around a different set of accounts is quick if you kept your account list outside the app, which "Connecting and adding user accounts" covers.

The reason the gate works this way is that a batch is a single commitment: one payment, one run, one set of results. What you are charged, what starts when you start it, and what the report covers afterwards are all defined against the batch as a unit, and that unit is the project you paid for.

So there are exactly two ways past this point: make every account in the project ready, or make the project smaller.

How are to-dos found and cleared in the app?

On most projects there is nothing to find. One or two to-dos across ten user accounts are visible the moment the page loads, and clearing them means opening one and choosing an option. None of the machinery for working at scale is needed, and the chapter "How is the same to-do cleared across many accounts at once?" can be left until a project is big enough to warrant it.

The little you need to know about the project screen to work through them: the grid gives one row per source account, its columns are grouped per content-type pair, and each of those groups collapses to a single status cell. That cell is where a to-do shows, as a count of the checks in that group that did not pass in place of reporting the content type as ready.

1. Find the row whose status cell for the affected content type reports a to-do count.

   The summary row at the bottom of the grid counts how many accounts are in each state, which is the quickest way to tell whether you are dealing with one account or thirty before you start.

2. Select the cell and read what the details panel reports about the check.

   It states the condition in a sentence or two. Hovering the cell in the grid shows the same explanation, so you can scan several rows without selecting each one.

3. Select View steps.

   The popup explains the condition more fully, including why it typically happens, and reports how many other accounts have the same to-do.

4. Choose an option.

   The options that make the content migrate come first, and the option that drops the content from the migration is last. What you are choosing between is covered in "How can a to-do be resolved?".

5. If the option required work outside VaultMe, complete it, return to the popup, and use its re-check control.

   The steps for that outside work are described in the popup itself, with the values you need.

6. Confirm.

   The cell returns to reporting the content type as ready, and the count of outstanding to-dos for the account drops — which is the quickest confirmation that the fix landed.

The re-check control in the popup is deliberately narrow: it re-runs only the check that popup is about, usually for a single content type. It is not the same thing as Re-run checks in the grid's action bar, which starts a full round for whichever accounts are selected — see "When does the scan run?" for when you want that instead.

Occasionally a finding is an unexpected error rather than a recognized condition, and it arrives with no options of its own because there is no standard route out of it. These are rare. Re-running the checks sometimes clears one; where it does not, it needs VaultMe's help rather than yours, so write to support@vaultme.com with the project and the account in question.

Once nothing is outstanding, the project can be paid for, which is where "Paying for and starting a batch" takes over.

How is the same to-do cleared across many accounts at once?

On a project of a hundred user accounts, a to-do buried in one row is not something you will find by scrolling, so the grid is the wrong place to start. Start from the project status instead. It exists so that one outstanding item anywhere in a large project is visible without hunting for it, and it reports how many pending actions are waiting.

Selecting it opens the checklist, which is the work queue for the whole project. It lists everything not yet settled — the checks that need action, and the ones still running or waiting to run — and leaves out only the checks that have passed. Every entry is therefore either something to act on or something to wait for, and the panel empties as they clear; once it is empty, the project is ready to pay for. A Show all checks toggle adds the checks that passed, if you want to see what has been covered.

Each entry names a check and how many accounts have to-dos against it, and carries a control for reaching them. Selecting that option does two things at once: it filters the grid to exactly those accounts, and it brings the check's own column into view. The second matters as much as the first, because a content-type group is collapsed by default and the column carrying a given check is not on screen until the group is expanded. The filter is the grid's ordinary one and appears as a removable chip, so clearing it restores the full list and undoes nothing.

Clearing the same to-do everywhere at once

1. Select the project status to open the checklist.

2. Pick the entry you want to work on.

3. On that entry's line reporting the to-dos, select the option to review the affected accounts.

   The grid narrows to those accounts, the check's column comes into view, and the first of the narrowed rows is already selected.

4. Read what the details panel reports about the check.

5. Select View steps.

   The popup's banner confirms how many other accounts share the issue.

6. Choose an option, tick Apply to all affected, and confirm.

   The action button names the number of accounts it will act on before you use it, so the width you are applying a resolution at is always readable. Do this only where the same resolution is right for every affected account — including when that resolution is excluding a content type.

7. Clear the filter and reopen the checklist.

   The entry is gone once the re-checks have completed.

Clearing the same to-do for some of the affected accounts

Where the right answer differs across the accounts one pending action covers — some to be fixed, others excluded — apply each resolution to its own subset.

1. Reach the affected rows through the checklist as above, so that only they are in the grid.

2. Select the range of cells the one resolution applies to.

3. Check the details panel, which reports how many accounts are selected and how many to-dos they hold between them.

4. Select View steps.

   The popup now acts on the selection, and its action buttons name that count rather than the full one.

5. Choose an option and confirm, leaving Apply to all affected unticked.

6. Repeat from step 2 for the remaining accounts with the other resolution.

Working through a project with several different to-dos

1. Open the checklist from the project status.

   It lists one entry per check that needs action, with account-level connection checks first and then a group per content-type pair.

2. Work the entries from the top, in the order the checklist lists them.

   That order is useful rather than arbitrary: connection and access findings sit at the top, and clearing them lets the checks that were waiting behind them report for the first time.

3. Resolve one entry at a time, by either of the two routes above depending on whether a single resolution fits every affected account.

4. Reopen the checklist after each round of fixes.

   The counts move as re-checks complete, and the project status follows them.

Reducing scope instead of fixing

1. Open the steps popup for the to-do and take the last option.

2. Confirm what it removes.

   For a content-type-scoped to-do it excludes that content type for that account and leaves the account's other content types migrating. An account-scoped to-do has no such option, because there is nothing narrower to drop than the account itself: select the row in the grid and use Remove instead. Either way, excluding dismisses every issue tied to what was excluded, not only the to-do you opened the popup for.

3. Apply it at the width you need, with Apply to all affected or a cell selection, exactly as in the two routes above.

4. Check the effect on the project's figures.

   The included content size and the price fall; the account count does not, because the account is still being migrated.

A content type can also be excluded directly with its include toggle, in the grid or in the details panel, without going through a to-do at all — see "Choosing migration options". The route through the popup exists so that excluding is offered as an answer at the moment the problem is raised.

What does a clean scan not guarantee?

A clean scan means the migration can start. It does not mean that every item will arrive at the destination.

The reason there is any remainder at all is a difference in timing. The scan measures a snapshot of each user account and settles the question of feasibility: whether this migration can be carried out as configured. The run happens afterwards, against accounts that are still in use, through provider behaviour that only shows itself under sustained load. Everything that could be known in advance has been checked and cleared by the time the batch starts; what is left is the part that could not be.

Three things surface only once the run is under way:

• More content than was measured. Accounts stay in use while a project is prepared and while it runs, so a migration routinely discovers items the scan never saw, and the estimates move with them.
• Capacity turning out tighter than projected. Content does not occupy the same amount of storage at the destination as it did at the source. Most of it is reformatted and repackaged by the destination provider rather than copied byte for byte, so its size there can be higher or lower — files held in cloud file storage are the one kind stored as-is. A destination that measured as having sufficient storage can therefore still run short, and this holds even when both sides are the same provider.
• Item-level failures. Individual items that cannot be copied: corrupted items, items a provider refuses, occasional errors affecting a group of them at once. VaultMe retries whatever looks recoverable and reports the rest as skipped items with the reason for each, rather than stopping the run over them. "Reviewing migration results" covers how to read those.

None of this is predictable beforehand, and none of it is a shortcoming of the scan — a question that cannot be answered until the run happens is not a check that was skipped. VaultMe has its own tools for both halves of it: "Monitoring a migration" covers reading a run while it is in progress, including estimates that move and accounts that finish at different times, and "Reviewing migration results" covers verifying the outcome once it is done.