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 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.

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?

In a Microsoft 365 to IMAP-compatible mail system migration, email is the only content type VaultMe can migrate, and a user account's mail is included as soon as the pre-migration scan has measured it. There is nothing to weigh up here, because the only thing this setting could do is take an account's mail out of the migration — which would leave that account still in the project, still billed its base migration fee, and with nothing at all to copy.

So the choice this screen appears to offer is really a choice about the account itself. An account whose mail should not migrate is taken out of the project rather than emptied — see the chapter on changing the list in "Connecting and adding user accounts". For what this screen cannot narrow down at all, see "What cannot be narrowed down?".

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.

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.

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?

In a Microsoft 365 to IMAP-compatible mail system migration, email is the only content type VaultMe migrates, and it does not divide. An account's mail migrates whole, and no part of a mailbox can be selected on its own — not by where it sits, not by when it arrived, not message by message.

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".