Reviewing migration results

This article covers how to review the results of a completed migration batch and decide where the batch stands before cutover.

What does reviewing migration results involve?

On a clean run this is a short piece of work. You download the reports, skim them, pass each one to the account holder it belongs to, and collect what comes back. It is a review rather than an investigation, and almost all of it is reading.

The review takes two parties rather than one, because the two halves answer different questions:

• Your half. Read the reports for what is only visible across a whole account: which items were skipped, and whether the pattern behind them makes sense for that account and the way it was configured.
• The account holders' half. Each holder opens the destination account and looks for the content they actually rely on. Nobody else can do this, because nobody else knows what should be there.

The run being over is also the end of what the app does for the result. There is no verification control in VaultMe, no pass-or-fail verdict on a completed migration, and nothing to confirm in the app afterwards. What VaultMe produces is a downloadable report per migration, and the review itself happens outside the app — in a spreadsheet, and in the destination accounts.

That gives the review its one hard scheduling constraint: it has to happen while the source is still live, and it has to happen before cutover. VaultMe copies content rather than moving it, so nothing was taken off the source account, and that account is the only thing there is to check the destination against. Retiring it, emptying it, or handing it back first does not merely make verification harder — it removes the ability to verify at all.

Expect the result to be good. VaultMe aims at item-level coverage of everything it indexed rather than at partial success, so the ordinary outcome is a handful of exceptions in each report and account holders who find what they came for. A handful of skipped items in an account holding tens of thousands is a normal run, not a damaged one.

The steps themselves are set out in "How are results reviewed?". Where they end is the part worth knowing up front: the batch is finished once the account holders confirm the result is acceptable, not when VaultMe reported the migration complete. Anything that looks wrong along the way, or that nobody can explain, goes to support@vaultme.com — the only route to an investigation, because no screen or report in VaultMe will say more than it already has.

Once the account holders confirm, one last sync-up migration (delta migration) usually runs immediately before the switch — see "Running sync-up migrations" — and closing the project out follows it in "Wrapping up the project".

How do I know the batch is finished?

Completion is reported at two levels, and the two move independently. Each migration in the batch completes on its own schedule; the batch reads as completed only once every migration in it has. VaultMe emails you when the batch completes, so this is not something you have to sit and watch for.

You read it on the batch screen, the same one you watched the run on, so there is nothing new to find — the statuses settle and the completion times fill in. Reading that screen is covered in "Monitoring a migration".

Because migrations finish independently, a batch spends much of its life partly finished, with some accounts done while others are still going. That is the normal shape of a run rather than a sign of a stall.

It also sets the natural unit of the review. Results belong to an account rather than to a batch, so an account that has finished can be dealt with straight away, without waiting for the rest of the batch to catch up.

For a single migration, completion is a specific claim: VaultMe indexed the content in scope for that account, attempted every item in that index, and recorded an outcome for each one. VaultMe's work on that account is finished, and nothing further will happen to it unless you run another sync-up migration (delta migration).

What completion is not is a claim that every single item arrived. Some items cannot be created at the destination at all. VaultMe records each of those with its own reason rather than a generic failure, and a small number of them is an ordinary outcome — see "Why were some items skipped?".

The outcome figures themselves live in two places, and knowing which is which saves work. On the batch screen, selecting a migration's ID on its row opens that migration's details screen, which carries the outcome counts for it, in total and per content type. The report is the only thing that names the items behind those counts.

One exception is worth closing on. Every migration has to complete or be cancelled before the batch can complete, so a migration left paused on a condition nobody intends to clear holds the batch open indefinitely; abandoning it is not the same as closing it (see "Monitoring a migration"). Cancelling is not an action in the app, so write to support@vaultme.com with the migration ID: that migration is refunded under the usual rules, set out in "Pricing and payment", and the rest of the batch carries on unaffected.

How are results reviewed?

What follows is a review sequence rather than an app procedure. Exactly one step happens inside VaultMe — the download — and everything after it happens in a spreadsheet and in the destination accounts.

1. Confirm that the batch and every migration in it read as completed.

   An account that has finished can be reviewed while others are still running. Only that account's own report has to wait for it.

2. Optional: select a migration's ID on the batch screen to open its details screen, and read the outcome counts there, in total and per content type.

   This is the fastest first look, and on a small batch that came through cleanly it is enough to move straight to step 4.

   It gives you counts only. The items behind them are named nowhere but the report.

3. Select Download reports on the batch screen.

   You get one report per migration, delivered as a single ZIP archive. A migration that has not completed has nothing to contribute to it yet.

4. Skim each report sheet by sheet, reading the sections at the top of each one — the items VaultMe could not copy, and the ones it copied with a change.

   What you are looking for is the pattern rather than every row: whether what is there looks ordinary for that account, or whether something repeats in a way that suggests a single cause.

5. Send each account holder their own report, together with a specific ask and the warnings that prevent false alarms.

   Each workbook is named for its migration and carries that migration's short ID, the same one shown on its row on the batch screen, so you can match report to account without opening it. Inside, the two placement columns name the source and destination addresses in their headers. What to ask for, and what to warn about first, is in "How do account holders confirm their own results?".

6. Collect what comes back and work down it.

   What comes back usually has nothing to do with whether the migration was complete. Most of it is usability: somebody cannot find content that is sitting in the account. The most common concerns, including those that look like a genuine problem at first, are listed below.

7. Close the review out once the account holders confirm that the result is acceptable.

   Their confirmation is what finishes the batch, not the completion VaultMe reported at the end of the run.

The most common concerns, whether you raise one or an account holder does, are these:

• The item counts do not match. A difference between the source and destination figures is normal in either direction. See "Should the source and destination item counts match?".
• The destination uses a different amount of storage. Also expected in either direction, and no more a verification instrument than counts are. See "Why does the destination use a different amount of storage?".
• Content appears to be missing. Most content reported missing is not missing, and there is an order worth working through before concluding otherwise. See "What if something is missing?".

Where a concern is not answered by any of those, write to support@vaultme.com with the migration ID and the specifics. Working out why something looks wrong takes experience with the two providers involved, so support can take a look rather than leave you guessing.

Whatever the outcome, do one thing before you close the project out: keep copies of the reports somewhere outside VaultMe. Each one is kept for a year after the run that produced it and then deleted, and saving them is part of wrapping up — see "Wrapping up the project".

How is the migration report organized?

The report is a downloadable Excel workbook that VaultMe builds for every migration, and its whole design follows from what it is for. It lists every item VaultMe indexed, one flat row each, with plain columns and no merged cells, so it can be searched, sorted, and filtered in a spreadsheet. It exists to answer two questions about one item somebody remembers: where did it end up, and why is it not there. It is not written to be read start to finish, and nobody should try.

Because both questions are asked about a remembered item, the report identifies items the way a person recognizes them rather than by provider or internal identifiers — a name or subject, the folder or label it was filed in, a date, and whatever else separates two items that share a name, such as a sender, an organizer, an owner, or a size.

The structure is layered the same way in every report. What varies between two reports is which layers are populated, because both the sheets and the columns follow the content types in scope and the pair of providers involved.

• One workbook per migration. It covers one source account and one destination account. There is no combined workbook for a batch, and nothing in a workbook reports on the batch it came from.
• One sheet per content type in scope — email, files, calendars, contacts.
• Sections by outcome within each sheet, exceptions first. Each section is introduced by a banner row naming the outcome and color-coded on a traffic-light scheme: red for items that could not be migrated, yellow for items that arrived with some transformation or loss, green for items that migrated successfully. A section appears only when it has rows, so a sheet opens on the rows worth reading rather than on thousands of successful ones. Every row also repeats its own outcome in its first column, which means sorting and filtering the sheet do not depend on the banner rows.
• A further grouping where a content type has sections of its own. Files are grouped by the areas of the source drive they came from, each under its own sub-banner. These are the same sections the content type was scoped by when the migration was set up, described in "Choosing migration options", and the grouping earns its place because where content sat at the source changes how its outcome should be read: an item the account owned outright and an item it merely had access to are not the same result.
• Columns in bands. The outcome first; then identity and classification; then placement at the source and at the destination, as two columns each naming its own account address in its header; then a single detail column at the end.

A few things about the rows are worth knowing before you read one.

• Containers get rows of their own, alongside the items inside them: a folder, a label, a calendar, and a contact group each appear as an item in their own right.
• Containers VaultMe created at the destination that had no source counterpart appear too, and carry no source placement, because there was nothing at the source for them to correspond to. The dedicated container the separate method creates is one — what that method produces is described in "Choosing migration options". So is any container VaultMe added to hold content the source structure had no place for, a TODO area among them — see "What is in a TODO area, and what happens to it?".
• Where a provider allows one item to sit in several containers at once, the placement cell lists them all, one per line. For example, a Gmail message carrying four labels reports four lines.
• The leading segment of a path is bracketed where it names the provider's own top-level area rather than something VaultMe built, and it is rendered as that provider names it, so it can appear in the account's own language. Where the root could not be determined it is reported as unknown, which is ordinary for source content the account reached through sharing rather than owned.
• Dates are the items' own timestamps, carried to help identify them. The report is not a log of when VaultMe processed anything.
• Every date column declares its timezone in its own header, and it is the same offset throughout the workbook: the workspace's, inherited from the admin account used to sign in. It is not the source account's, not the destination's, and not the reader's, so every report in a batch reads in your timezone however widely the accounts are spread.
• Sizes are plain byte counts, and blank for containers.

The detail column is where the report earns its keep. It is empty on most rows, and on the rest it is written for a person rather than for matching against an error catalog: it names what happened to that item and, where it matters, which side it happened on. For a skipped item the aim is a specific reason rather than a generic failure. For an item that arrived with a transformation, it names the transformation — a format conversion, or a name or path changed enough to affect how the item can be recognized.

What the report deliberately does not carry matters as much as what it does.

• No summary. There are no totals, no per-outcome counts, no roll-up sheet, and no verdict on whether the migration went well. Counts come from the app instead; anything finer you derive from the rows yourself.
• No content. Message bodies, file contents, and anything else held inside an item never appear. The workbook carries identifying, placement, and outcome fields only.
• No cross-migration view. Nothing in it reports on the other migrations in the batch, or on anything migrated into the same destination account earlier.

VaultMe rebuilds the report after each sync-up migration (delta migration) run, and only the most recent one is available to download. Nothing is lost by that, because each rebuild is cumulative: it adds items newly discovered at the source, updates modified items to their latest state, and covers the whole migration rather than the pass that produced it. The latest report is always the complete one. The first report you can download already includes the automatic sync-up that follows the initial run, so even the earliest copy accounts for changes made at the source while the migration was going.

The flip side of a cumulative rebuild is that nothing in the workbook marks which items a given pass added or changed. A report answers what became of an item; it never answers which pass handled it.

Each issued report is retained for one year from the end of the run that produced it, and then deleted. Where reports are stored and how the retention windows work is covered in "Where migration data is stored and how long it is kept".

One last thing about the report explains why the rest of this review is split the way it is: the same rows serve two very different readers. You scan them across a whole account looking for patterns, while each account holder searches them for the one item they cannot find — see "How do account holders confirm their own results?".

Why were some items skipped?

A skip is not a hole in VaultMe's coverage; it is a recorded outcome. VaultMe determined that the item could not be created at the destination, retried it where a retry could have helped, and then wrote a specific reason onto its row rather than a generic failure.

Before reading anything into it: some skipped items are normal on any real migration. A handful across an account holding tens of thousands of items is a healthy run and needs no explanation at all.

Two surfaces answer two different questions about skips, and going to the right one first saves work. The migration's details screen gives you the count, in total and per content type, which is enough to decide whether to look any further. Only the report says which items and why — see "How is the migration report organized?".

What is worth reading is the pattern rather than the count.

• Scattered one-offs across content types are ordinary item-specific constraints. Individual items run into individual limits, and there is nothing behind them to chase.
• A cluster — the same reason repeated, or everything from one folder, one content type, or one account — usually has a single cause behind it, and that is worth a look.

The reasons themselves are open-ended — they are written per item and follow what the providers actually do — but nearly all of them are one of three things.

• The destination refuses the item. Something on the destination side will not accept it, and VaultMe has no way around that.
• The source cannot serve the item. VaultMe indexed it, but could not get a usable copy out. A file the account could see but whose sharing settings did not permit copying or re-sharing is the usual example. Google Forms are another: Google provides no way to export them, so they cannot be recreated outside a Google account at all.
• It depended on something that did not migrate. Where an item only makes sense as a reference to another item, it goes when that other item does not arrive. A shortcut to a file that was out of scope, or that could not be copied, has nothing left to point at.

The honest part is that a skip is terminal. The reason describes what happens to that item under the configuration that produced it, so re-running the same migration reproduces it. A sync-up migration (delta migration) does not revisit it either, because a sync-up copies what changed at the source and a skipped item has not changed — see "Running sync-up migrations". And there is no retry control anywhere in the app.

So what is actually left is a decision rather than a fix: work out which of the skipped items matter, and handle those by hand from the source account while it is still live. Download the file and upload it to the destination, save the message, or capture in some other form whatever cannot be exported at all. This is one of the reasons the review has to finish before cutover.

Support earns its place in two cases: a large or clustered set of skips, and a reason that makes no sense against what you know about that account. Write to support@vaultme.com with the migration ID and the rows themselves rather than a description of them.

One boundary is worth stating plainly. A skipped item is in the report by design: it is accounted for, whatever anyone decides to do about it. Something missing that is not in the report is a different question — see "What if something is missing?".

What is in a TODO area, and what happens to it?

A TODO area is where VaultMe parks items that migrated but could not be placed where they belonged. Arriving and being placed are two separate outcomes, and a TODO area is the gap between them: the item is in the destination account, but automatic placement could not finish the job on it.

VaultMe works this way because a visible parking area is recoverable and a silent best guess is not. An item filed somewhere plausible but wrong is indistinguishable from one filed correctly, and nobody ever goes looking for it. An item in a parking area announces itself.

The shape is simple. There is one area per content type, created only where that content type actually has something to park, and it sits wherever the migration's content organization method puts it — see "Choosing migration options".

Naming varies by destination provider and by content type, usually with TODO somewhere in it, so read the destination account rather than expecting a particular name.

Working through one starts in the destination account, not in the report. The area is easy to spot, and most of what is in it can be read and filed straight from there, because the item is right in front of the person doing the filing. The report is worth opening only where an item cannot be identified and placed by looking at it.

The job belongs to the account holder, and nothing else will move those items. VaultMe does not return to a TODO area later, and a sync-up migration (delta migration) does not touch it.

The reassuring part is that leaving the area exactly as it is costs nothing. The items are in the account, they turn up in search like any others, and they are as usable where they sit as they would be anywhere else. Filing them is tidying rather than recovery — worth doing where the structure matters to how someone works, and fine to skip where it does not.

That is also the thing to say plainly when you hand the work over, because a parked item reads like a failed one: it arrived. What it needs is filing.

How do account holders confirm their own results?

This is the half of the review that cannot be done from your desk. Only the person who used the source account knows what should be in the destination one — which items matter, what they were called, and what the account has to look like for them to work in it.

What each holder needs is their own report and a short, specific ask. Send the report itself rather than a summary of it: the workbook is a searchable instrument, and summarizing it removes the one thing that makes it useful at the moment somebody cannot find an item.

Warn them before you ask, because nearly every false alarm comes from something nobody told them.

• Where the migrated content actually is. The content organization method decides that, and it is either a dedicated new place created for the migration, with the structure the account had at the source recreated inside it, or content blended into what was already in the destination account. The separate method is the single biggest cause of "everything is missing", and what each method produces is set out in "Choosing migration options".
• Item counts will not line up. They are not the thing to check, in either direction — see "Should the source and destination item counts match?".
• Storage used will differ. Also not a signal — see "Why does the destination use a different amount of storage?".
• Links inside migrated content still point at the source. VaultMe preserves embedded links exactly as they were rather than repointing them at migrated copies, so they keep working while the source is live and stop working once it is retired. That is by design, and holders should flag the links that matter so they can be updated by hand.
• Anything changed at the source after their migration ran is not in this report. It comes with the next sync-up migration (delta migration) instead — see "Running sync-up migrations".
• A TODO area may exist, and what is in it arrived. It is not a list of failures — see "What is in a TODO area, and what happens to it?".

What to ask for is targeted rather than exhaustive. Nobody can check an account item by item, and asking for that produces either silence or a false all-clear. Ask each holder to look for what they actually rely on: recent work, the handful of items that matter most, and the structure they work in day to day. Where something is not where they expect it, ask them to search the report for it rather than judging by eye.

Word the ask so that the answers are usable. Ask specifically what they cannot find, with the item's name or subject and roughly when it is from, so that it can be looked up. A reply saying that some old mail seems to be missing cannot be acted on by you or by support.

One caveat follows from that, and it is the reason to search by name before searching by date: every date in the report is stated in a single timezone for the whole workbook — the workspace's, taken from the admin account used to sign in — so an item's date can sit hours away from what the holder sees in their own account. A search on the date alone can miss.

Give the ask a deadline, and say why it has one. The source account stays live until the review closes, and cutover waits on it, so an open-ended request quietly holds up the whole project. What has to be true before you can cut over is covered in "Wrapping up the project".

Calibrate the effort to the project. For a handful of accounts, a note each and a day or two is the whole exercise. For a large project, send one wave per batch, and let the first wave shorten the ask for everyone after it: once you know which questions came back, the next note can answer them in advance.

None of this should arrive cold. End users are told during preparation that they will be asked to check their own accounts afterwards, and the groundwork for that is in "Preparing stakeholders and end users".

Should the source and destination item counts match?

Not necessarily. A difference between the two figures is common, and on its own it does not mean that anything went wrong — though it can, which is why it is worth knowing where a difference legitimately comes from before drawing a conclusion from it.

Most differences come down to one of these.

• The interface the figures are read from. What a count means depends on the content type and on the screen reporting it, so two accounts holding the same content can show different totals with nothing wrong on either side. Gmail is the clearest case: it reports a conversation count or a message count depending on whether Conversation View is switched on for that account. Switch it off on both sides, refresh both, and compare messages rather than conversations.
• Skipped items. Every content type, files included. Whatever was skipped never reached the destination, and the report names each of those items with its own reason — see "Why were some items skipped?".
• Content shared with the source account. In cloud file storage, what an account owns and what was merely shared with it often sit side by side in the same view, so a source figure read off the screen counts both. How much of the shared part comes across depends on the migration's own settings, described in "Choosing migration options", so this one can move the figure a long way.
• Content that was never in the connected account's cloud. VaultMe indexes what the connected account exposes in the cloud and nothing else, so content a person can see but the account does not hold in the cloud never arrives. Mail that a desktop client downloaded and removed from the server is the classic case: only a local copy remains, and it is not discoverable. So are contacts and calendars kept only on a handset, and files sitting in a different cloud or a different account than the one that was connected. This is the one most likely to produce a large unexpected gap.
• Duplicate copies at the destination. Occasionally the destination provider ends up holding an item twice, from its own timing rather than from anything in the source content. It adds to the destination figure, and the effect is small.

Where a difference still looks too large for any of these to explain, pin it to something concrete rather than to the total: take an item that should be at the destination and is not, look it up in the report, and check the source account for it. A named item can be traced from end to end; a shortfall of four thousand cannot.

If that does not settle it, write to support@vaultme.com with the migration ID and those specific examples.

Why does the destination use a different amount of storage?

Because that is what migrations do. Destination storage usage is expected to differ from the source, in either direction, and it is no more a verification instrument than item counts are. No real migration lands on an exact match.

What makes the figure useless as a signal is that it is not one effect but several, pushing in different directions at the same time.

• Repackaging. Destinations rebuild content through their own storage model rather than storing the bytes handed to them, so logically identical content can occupy a different amount of storage. The one exception is binary files in cloud file storage, which destinations accept as opaque byte streams and keep at their original size. Everything else is reprocessed, and the effect is most visible on email and documents.
• Skipped items. What was not migrated is missing from the destination total, and this contributor is not proportional to the number of items involved: a single large skipped file moves the figure noticeably, while thousands of skipped messages barely register at all. A storage gap therefore says nothing about how much content is affected — see "Why were some items skipped?".
• Content shared with the source account. Content the source account only had access to consumed no storage against that account's own quota, while the destination account owns its copy outright and pays for it in full, so the destination can legitimately exceed the source by the entire volume of it. Where shared content is in scope, this is the effect most likely to leave a destination looking unexpectedly large.
• Duplicate copies at the destination. Rare, provider-side, and purely additive.

The difference holds even where a match would be most reasonable to expect. Two accounts in the same provider family are not a byte-for-byte transplant of one another either.

So neither direction is evidence of anything. A destination that is smaller is not evidence of loss, and one that matches is not evidence of success. Item-level outcomes come from the report and nowhere else — see "How is the migration report organized?".

There is one genuinely actionable consequence, and it belongs to planning rather than to this review: destination capacity should be provisioned with a margin over the figure measured at the source rather than matched to it, because several of these effects push the requirement upward. That work is covered in "Getting the destination ready".

What if something is missing?

Start from the likeliest answer: most content reported missing is not missing. Work down the checks below in order and stop at the first one that explains it — they are ordered by how often each turns out to be the answer.

1. Somewhere else in the destination account. The content organization method decides where migrated content landed, a TODO area holds whatever could not be placed automatically, and a name may have been adjusted to fit the destination's own naming rules, which changes what a search for the original name finds.
2. In the report, as a skipped item with a reason. Then it is accounted for, and what it needs is manual handling from the source rather than another run — see "Why were some items skipped?".
3. Out of scope. A content type or an account taken out of the project during setup was never indexed, so nothing about it will appear anywhere in the results.
4. Never in the connected account's cloud. Mail a client pulled down and removed from the server, items living only on a device, content in a different cloud or a different account than the one connected — none of it was discoverable, so none of it was ever indexed.
5. Created or changed at the source after the run began. Then it is not lost; it comes with the next sync-up migration (delta migration) — see "Running sync-up migrations".
6. None of the above. Write to support@vaultme.com, naming the account and quoting the item's identifying details from the report — its name or subject, its date, and where it sat at the source.

Re-running the migration is not a repair, and it is worth knowing why before anyone proposes it. VaultMe does not inspect what is already in the destination account, so a second run does not fill gaps: it writes a second copy of everything it copies, on top of the first. Redoing a migration properly starts with clearing the earlier copy out of the destination, which is covered in "Wrapping up the project".

Whatever turns out to be genuinely missing is still sitting in the source account, which is the whole reason this review happens before cutover. Anything VaultMe could not bring across can be dealt with by hand while both accounts are still there.