Choosing migration options

This article covers the migration options a project holds for each user account: what content VaultMe copies from it, and how that content is organized in the destination.

What does choosing migration options involve?

VaultMe supports the following two migration options:

• Content scope — which content types a user account migrates.
• Content organization method — how that account's migrated content is arranged in the destination account.

Neither setting needs changing on most projects. Every content type the pre-migration scan measured in a source user account is already included, and every account is already set to merge its content into the destination it was paired with, so a project whose plan matches those defaults can move straight on to payment.

Both settings belong to the individual user account rather than to the project, and two things follow from that. A project that mixes settings is entirely normal: a single batch commonly carries current staff whose accounts merge into live destinations alongside a few departed colleagues whose accounts are being archived. And nothing is set once for everything unless you set it that way — a project-wide change means selecting the whole project, which is what "Where are migration options set?" is about.

Neither setting is decided on this screen, and it is worth arriving with both answers already in hand. Content scope is worked out during planning, in "Selecting content for migration". The organization method is the app's expression of each account's disposition — active or archived — which the migration inventory records for every account being migrated; see the active-or-archive chapter of "Building the migration inventory". What happens on this screen is entering those decisions, so anything still open is worth settling before you start.

One mechanic is worth learning before you touch either setting, because it is what makes fifty accounts as quick to configure as one: a setting is changed for many accounts at once by selecting a range of cells in the grid and setting the value a single time. The next chapter covers it, and both procedures later in this article are built on it.

Everything on this screen stays editable for as long as the project is a draft. Paying is what fixes it, so a setting entered wrongly costs nothing until then — see "Paying for and starting a batch".

By the time you leave this screen, content scope should be confirmed for every user account in the project, and every account's organization method should match its disposition, active or archived.

Where are migration options set?

Each setting appears in two places: as a cell in the grid, and as a row in the details panel for whatever the grid has selected. These are one setting seen twice rather than two routes to it, so a change made in either place shows up in the other immediately. Which one you work from is a matter of what is already in front of you.

The grid's cell-range selection is the lever that makes a large project tractable. Select a range of cells in one column, set the value once in the details panel, and it lands on every user account in the range. That is what turns one setting across fifty accounts into a single action rather than fifty, and it is the shape of both procedures in this article — the file-section procedure in "How is part of a drive left out of the migration?" and the method procedure in "How should migrated content be organized in the destination?".

The details panel reads a selection rather than a single row. Where the selected accounts agree on a value it shows that value; where they differ it reads as mixed. What the panel can then act on depends on which column is selected and on the values in it: sometimes the whole range can be changed in one action, and sometimes the range has to be narrowed before anything applies. The working method is therefore to select, look at what the panel offers, and narrow the selection if it offers nothing.

One column group opens a level deeper than the rest. Files expand into one group per section of a drive, each with an include setting of its own — which is the subject of "How is part of a drive left out of the migration?". Email, calendars, and contacts have no such level, so there is nothing further to open under them.

The summary row along the bottom of the grid follows the selection, which makes it useful twice over in the same operation. With a range selected it totals only those accounts, so you can size a subset — its content, its cost, how many accounts are in each state — before deciding what to change. After the change it reports the result, which is also how a setting meant to be uniform across the project is verified without scrolling down the column reading cells.

Which content is included in the migration?

Content scope starts at everything. Email, files, calendars, and contacts are all included for every user account as soon as the pre-migration scan has measured them, so this setting only ever narrows a migration — there is nothing here to switch on.

Every content type has an include toggle of its own, and every user account has its own set of them. Each toggle appears as a cell in that content type's column group, and as a row in the details panel. What a toggle covers depends on the content type:

• Email, calendars, and contacts — a plain switch with no middle setting. The content type is either in the migration or out of it.
• Files — a roll-up, because a drive is made up of sections that are included independently of each other. Switching files off switches every section off with them, as described in "How is part of a drive left out of the migration?".

Below the section level nothing divides any further — see "What cannot be narrowed down?".

Two sets of figures sit beside the toggle, and they are easy to mistake for the same thing:

• Available content — what the scan found in the source account. It stays where it is however scope changes.
• Content to migrate — what the current scope selects out of that, in items and size. It follows every change immediately.

So an excluded content type still shows how much content the account holds, and that figure describes the source rather than what the migration will carry.

Excluding a content type then does three things at once, and only the first is obvious:

• The content type leaves the migration. VaultMe stops treating it as something to copy, and its status reports it as excluded rather than reporting how ready it is.
• Its to-dos stop counting against the project. Because the content type no longer has to be migrated, the outstanding work attached to it no longer has to be resolved. That makes excluding a genuine way out of a project that cannot otherwise be paid for, and it is offered as the last resort wherever a to-do is raised — see the chapter on resolving a to-do in "Running the pre-migration scan".
• Included content size and total price fall, and the project's account count does not. The user account is still being migrated, so it still carries its base migration fee; only the data fees behind the excluded content come off. Pricing is covered in "Pricing and payment".

Switching off a single file section reaches less far. The section's content leaves the migration and its items and size come off the included figures and the price, but files as a content type stay in the migration for that account, and any outstanding work against them still has to be resolved.

The third of those points is where excluding is most often misread, so it is worth stating plainly: excluding a content type does not postpone it. There is no way to come back for it afterwards and add it to what this batch delivered. The only route is to migrate that same user account a second time, in a new batch that is paid for in full — base migration fee included — on top of what this one already cost. Leave a content type out because it genuinely should not migrate, not on the assumption that it can be picked up later for the price of the content itself.

How is part of a drive left out of the migration?

Files are the one content type that does not arrive as a single block. Google divides a user account's file storage into the following sections:

• My Drive — the files the account owns itself.
• Shared with me — files someone else owns and has given the account access to.
• Shared drives — files a Google Workspace organization owns rather than any one person, reachable by every account granted access to the drive.

Each section is included or excluded on its own, and the include toggle for files as a whole is a roll-up that switches every section at once. An ellipsis control beside that toggle is the only thing that distinguishes a roll-up from a plain toggle; a content type with no sections carries the toggle alone.

The reason to open that list is the sections holding content the account does not own. They are frequently larger than everything the account owns itself, and they call for a decision rather than a glance.

Files someone else has shared with the account raise a question of whether the business needs them at all. An organization whose work lives in files shared by customers and partners will want them; plenty of organizations will not. Where they are included, several accounts each bringing their own copy is normal rather than waste, because the files one account has been given are not the files the next one has been given. This is the planning-level decision covered in the shared-files chapter of "Selecting content for migration".

Shared drives take two decisions rather than one: whether they migrate at all, and then, if they do, which user accounts carry them across. The second decision is the one that gets missed. A shared drive is reachable by every account granted access to it, and every one of those accounts starts out with it included, so left alone each of them copies the same files into its own destination and the project pays for every copy.

The toggle covers the section as a whole, so an account either brings every shared drive it can reach or brings none of them — individual drives cannot be picked out. The arrangement to aim for therefore splits the project into two groups of accounts:

• A small set, often a single account, keeps the section switched on. What matters about the set is that its access covers every shared drive that should migrate, between them.
• Every other account in the project has the section switched off, whatever it has access to.

Each shared drive then arrives once rather than once per account with access. Which accounts make up the first group is not decided here, though: it belongs with the inventory, alongside the other resources that migrate through a connected user account rather than as rows of their own — see the chapter on non-user-account resources in "Building the migration inventory".

Sections are switched off like this:

1. Select the cells in the file content type's include column for every user account the change is for.

   The details panel then reports the values those accounts share and reads as mixed wherever they differ, so a range that turns out to be uneven can be narrowed before anything is applied.

2. Open the section list from the ellipsis control beside the include setting in the details panel.

3. Switch off the sections that should not migrate.

   The list reports items and size for each section alongside the total that the sections still switched on leave included, so the size of the decision is visible while you make it.

4. Confirm the outcome on the project summary strip and on the grid's bottom summary row.

   Included content size and total price follow the change immediately, which is the quickest confirmation that it landed on the accounts you meant.

The same per-section toggles can be reached in place instead of through that list, by expanding the file content type's group down to the section level in the grid or in the details panel. Both routes set the same thing.

How should migrated content be organized in the destination?

Which method a user account needs follows from a decision that belongs to planning rather than to this screen: whether the account is active or archived. Building the migration inventory is where that decision is made and written down for every account being migrated — see the active-or-archive chapter of "Building the migration inventory".

The two dispositions — active and archived — map onto the two methods:

• The merge method — for an account whose holder will keep working in the destination. Arriving content blends into the destination account they already use, as described in "What does the merge method produce?".
• The separate method — for an account whose content is being preserved and kept findable rather than worked in. Everything lands in a dedicated place of its own, as described in "What does the separate method produce?".

The method is chosen once per user account and governs all of that account's content together. An account cannot merge its mail and separate its files: VaultMe applies the method to each content type independently, but the choice is not offered at that level.

Merge is the default for every user account in the project, so the separate method only ever applies where it has been set. On an archive project, where every account or nearly every one belongs on separate, that is a change to make across the whole project in a single pass rather than account by account:

1. Select the cells in the Method column for the accounts the change is for, or the whole column to change every account in the project.
2. Open the method setting from the details panel, which opens Choose Content Organization Method.
3. Choose Merge with existing content or Separate from existing content, and select Apply.
4. Confirm the result on the grid's bottom summary row, which counts user accounts by method.

A project that ends up with both methods in it is perfectly legitimate, and it is the shape of many real batches. Select only the subset of accounts the change is for and nothing outside that range moves. Afterwards the bottom summary row is where the split is read at a glance, without going down the column account by account.

As with everything else on this screen, the method stays editable for as long as the project is a draft, and payment is what fixes it — see "Paying for and starting a batch".

What does the merge method produce?

Merge writes migrated content into the containers the destination user account already has — its folders, labels, or sections, depending on the content type. The account therefore ends up with a single blended structure rather than a migration parked beside what was already there.

The point of that is continuity. Someone moving their working life to the destination and carrying on there needs the destination to resemble the source as closely as it can, so that where they used to look for something is where they still look for it. Merge is what produces that, and it is why the method suits every account with a person still working behind it.

Nothing already in the destination is replaced, overwritten, or deleted. Migrated items are added as new entries alongside what is there, so existing destination content survives the migration untouched even where it sits in the same place as arriving content.

Underneath, four rules do the work:

• Containers are matched, then written into. VaultMe looks for a destination container corresponding to each source container and writes that container's content into the match, which is what blends the two structures instead of stacking one on the other.
• Provider containers are matched by internal identity rather than by the name on screen. An inbox is recognized as an inbox whichever language the interface is set to, so the source and destination accounts do not have to agree on their interface language for the match to work.
• Name collisions are resolved by adjusting the arriving item. Where an item would conflict with something already in the destination container — most often by carrying the same name — VaultMe changes the arriving copy, typically by adding a numeric suffix, so the result is unique. It never resolves a collision by replacing what is already there.
• Anything needing manual follow-up is kept out of the blend. Items VaultMe could not place automatically go into a container of their own at the top level of the destination account rather than mixing into the matched structure, which is what makes them findable afterwards. VaultMe calls that a TODO area, and what lands there is covered in "Reviewing migration results".

One caution follows from the first of those rules. Merge matches containers, not items: VaultMe does not inspect what is already in the destination to work out whether an item is a copy of something an earlier migration delivered. Running the same source into the same destination a second time therefore duplicates rather than resumes, whether that earlier attempt was made by VaultMe or by anything else. Redoing a migration means removing the earlier content first — see the chapter on redoing a migration in "Wrapping up the project".

What does the separate method produce?

Separate keeps migrated content clearly apart from whatever the destination user account already holds. Rather than matching the destination's own containers — its folders, labels, or sections, depending on the content type — VaultMe creates one dedicated container for the migration, named from the source account's own identifier, usually its email address, and replicates the source structure inside it.

Not every content type has folder-like structure to hang a dedicated container from. Where there is none, VaultMe marks the migrated items instead, with a naming prefix or an equivalent marker, to the same end. Separate is therefore a principle applied to each content type in whatever way that content type allows, not one folder holding everything the migration brought.

What the method buys is worth being concrete about:

• Nothing merges. Migrated content does not touch the destination account's existing structure at all, so there is no way for it to complicate what is already in use there.
• Everything is in one place. Whoever needs something out of the migrated content later has one place to look, and can tell at a glance which source account it came from.
• It can be undone in one move. Because the whole migration sits inside one container, removing it is a single deletion rather than an exercise in telling migrated items apart from pre-existing ones.

What it costs is the daily working experience. A dedicated container is not a layout anyone wants to work in, and a destination account on separate reads as two parallel structures — the account's own, and the migration beside it. That is precisely why the method belongs to archiving rather than to accounts with someone still working behind them: a departed holder's content kept for continuity or legal reasons, parked in a destination where nobody works day to day.

The consolidation that usually goes with archiving depends on it. Several source user accounts can be assigned to a single destination account, which keeps destination licensing down when the content of a dozen departed colleagues has to be kept but none of them needs a seat of their own. Merge would interleave those dozen migrations past telling apart; separate gives each source account a container of its own inside the shared destination. How that pairing is set up is covered in the chapter on assigning destinations in "Connecting and adding user accounts".

Two details of the result are worth knowing in advance, because both are visible and neither is a fault:

• Provider containers arrive with English names. The ones recreated inside the dedicated container carry fixed English names whatever language the source account's interface was set to, so a migration out of a non-English account arrives with English names in its structure.
• The TODO area sits inside the migration container. The items VaultMe could not place automatically go there rather than at the top level of the destination account, which follows from the whole point of the method: nothing lands outside the container. What ends up in a TODO area is covered in "Reviewing migration results".

What cannot be narrowed down?

How far this screen narrows a migration depends on the content type.

• Files divide by section. Whole sections of a drive can be left behind, as described in "How is part of a drive left out of the migration?". Inside a section nothing divides further: no selecting individual folders, and no selecting individual files.
• Email, calendars, and contacts do not divide at all. Each of them migrates whole for every account it is included for, and no part of a mailbox, a calendar, or an address book can be selected on its own — not by where it sits, not by when it arrived, not item by item.

This is a deliberate design choice rather than a missing control, and both the reasoning behind it and the practical alternative below belong to planning — see "Selecting content for migration".

If a project genuinely has to be smaller, the lever is on the source side rather than in the app. Ask account holders to clear out their own accounts before the run and move what is no longer needed to trash, because content in trash is not migrated. That works where a scope setting cannot: it puts the decision with the person who knows which content still matters, item by item, instead of asking you to guess at a cut-off.

The organization method is not a set of knobs either. How migrated content is matched to what the destination already holds, how name collisions are resolved, and where items needing manual follow-up are placed all follow from the method, and none of them is separately configurable. The choice is between two whole behaviors.

Finally, the content types VaultMe does not migrate at all are not a scope setting and never appear on this screen as something switched off. They are simply outside what a migration carries, and they need accounting for separately — see the chapter on what cannot be migrated in "Selecting content for migration".