Selecting content for migration

Content scope is the set of content types VaultMe migrates from each account in the migration inventory. This article covers how to settle it, account by account, before the migration is set up.

What goes into selecting content for migration?

For most projects this is a confirmation rather than a decision. VaultMe migrates four content types — email, files, calendars, and contacts — and one migration carries all of them in a single pass, so selecting content usually comes down to confirming that every account in the inventory takes all four, and moving on to the next decision.

The single pass is worth stating plainly, because it is easy to assume that a migration means mail alone, or files alone. One VaultMe migration copies an account's mail, its files, its calendars, and its contacts together, and the four usually run alongside each other inside that migration rather than one after another.

Including everything in one migration is also the most economical way to run the project. Migrations are billed per migrated user account, and each batch is billed and paid for separately, so migrating mail for a set of accounts in one batch and their files for the same accounts in a later batch means paying for those accounts twice — and running the coordination and the communication around the run twice as well. Phasing content types does not reduce what a project costs; "Pricing and payment" covers how the billing works.

The decision also rides on work already done rather than starting a new exercise. Content scope is another column on the same list of accounts assembled in "Building the migration inventory", filled in per account, and for most projects filled in identically for all of them.

Three things are yours to settle:

1. What each content type covers. A working sense of what email, files, calendars, and contacts each include, so the choice is an informed one rather than a reflex.
2. Which file areas are in scope. Files are the only content type with a real sub-selection, and the shared areas among them need a deliberate call.
3. What will not come across. A record of everything VaultMe cannot migrate, so that nothing important is silently assumed to be on its way.

What content types can VaultMe migrate from Google Workspace?

VaultMe migrates four content types from Google Workspace: email, files, calendars, and contacts. A migration can include any combination of them, and the recommendation for nearly every project is to include all four in one migration.

• Email. All the mail the account holds — messages with their attachments, and the labels they are filed under, replicated in the destination as faithfully as the destination provider allows.
• Files. Everything the account holds in Google Drive, with its folder structure replicated in the destination. Files are the one content type where the choice is more than in or out: email, calendars, and contacts are all-or-nothing, while files arrive in separate areas that are chosen individually, as "How are shared files handled?" describes.
• Calendars. The calendars the account holds in Google Calendar, and the events in them.
• Contacts. The contacts the account holds in Google Contacts, along with the groups they are organized into.

Each of the four is decided per account, not once for the whole project, though in practice the same answer applies to nearly every row on the list.

How are shared files handled?

Files behave differently from email, calendars, and contacts, because they do not arrive as one undivided pile. An account's files sit in separate areas, and those areas are included or left out independently, in any combination:

• The account's own files. Everything in My Drive, including items that sit in no folder at all.
• Files shared with the account. The files and folders in the "Shared with me area", owned by other people inside or outside the organization.
• Shared drives. The shared drives the account can reach.

The account's own files rarely need a decision: they are the reason files are in scope at all, and practically every migration includes them. The shared areas are where the planning sits.

Files shared with the account

Whether to bring these along is a genuine judgement call, and an easy one to skip past. Nobody in the organization owns them and they take up none of its storage, so they slip out of view exactly when scope is being set. They can still be precisely the content the business runs on: where clients, partners, or contractors share files rather than send them, those files have to stay reachable long after the source account is gone. Nothing in VaultMe can decide this. How much they matter is specific to how the organization works, so it is worth asking the people who would notice if they went missing rather than assuming either way.

A few things about how VaultMe treats them are worth knowing before making that call:

• The copy belongs to the destination account, not to whoever shared the original. Each shared file is copied into the destination account as a new file owned by that account, exactly like the files the account owned in the first place. The sharing permissions on the original are not copied along with it: the person who owns the source file still owns it and is not given access to the copy, and nobody else is either unless someone grants it after migration.

  Ownership also decides whose storage the file consumes. While it was only shared, it counted against the storage of whoever owned it and nothing against the account it was shared with; the copy counts against the destination account's storage quota like any other file it owns, so a large shared area has to be counted in when sizing the destination, as "Getting the destination ready" describes.

• The volume can be far larger than anyone expects. Years of being added to other people's folders accumulate quietly, so one account's shared files can outweigh everything the account owns. When a pre-migration scan reports a file count for an account well above what anyone predicted, shared files are the usual explanation, and that is the moment to decide deliberately whether they belong in scope. "How VaultMe works" covers what the scan reports.

• Not everything visible in "Shared with me" is in scope. Files and folders shared directly with the account are. Items shared more broadly — with a group, or with anyone holding the link — are in scope only once the account holder has opened them at least once, and that is judged file by file, so a broadly shared folder can come across incomplete. The rule keeps large volumes of publicly shared content from being pulled into migration scope unintentionally.

Shared drives

Shared drives are a different problem. They belong to the organization collectively rather than to any one person, and they usually hold internal working content that a whole team depends on.

Collectively owned content like this is migrated through the user accounts that can reach it, which means every account you include it for receives a full copy of its own. Include the same content for ten accounts that can all see it and it is copied ten times over: ten times the data volume to pay for, a longer run, and ten copies for someone to sort out afterwards.

The setup that avoids all of that is small. Decide which single account carries each collectively owned area, include that area for that account alone, and leave it out everywhere else. Leaving it out is done account by account when migration options are set, as "Choosing migration options" describes.

Can just part of a content type be migrated?

No. A content type that is in scope is migrated whole. VaultMe indexes every item the connected account exposes for that content type and then works through the entire index — every message, every file, every event, every contact. There is no date range to set and no way to include only some folders or labels and leave the rest behind, and the file areas in "How are shared files handled?" are the only sub-selection VaultMe offers.

This is a deliberate design choice rather than a missing feature. Every item in a business account is a record of something, and how much a record matters bears no relation to how many gigabytes it occupies: the oldest message in a mailbox can be the one a contract dispute turns on. Storage is cheap next to the cost of finding out too late that something is gone, so VaultMe preserves everything instead of guessing what is safe to drop. VaultMe's migration philosophy sets out that reasoning in full.

Experience is what settled it. Nobody is in a position to make that call blind — no date cutoff is reliably the right one, no subset of folders reliably holds what someone will ask for next year, and a bad guess only becomes visible months later, when the content is unrecoverable because the source has been decommissioned. Offering the choice would mostly be offering a way to lose content, so VaultMe does not offer it.

When scope genuinely has to shrink, the lever sits inside the accounts rather than in VaultMe. Ask each account holder to clean up their own account before the run and move what they no longer need to trash, which is not migrated. The risk is low: trash can be recovered, VaultMe never changes anything in the source, and the source account is being decommissioned later anyway. In practice, hesitating over whether to trash something is a reliable sign that it still matters and should come across.

Cleanup shows up in the numbers as well as in the scope. Fewer items mean a smaller data fee and a shorter run, since item count is the strongest driver of how long an account takes. "Preparing stakeholders and end users" covers how to put this and other requests to account holders before the run.

What can't VaultMe migrate from Google Workspace?

VaultMe migrates email, files, calendars, and contacts, and nothing beyond those four. The boundary follows content types rather than accounts, which is what makes it easy to trip over: plenty of other content lives in the same ecosystem, often behind the same sign-in and one click away on the same screen, and none of it is in scope however much it feels like part of the account.

A few of them are assumed to be part of the account more often than the rest: Google Photos libraries, YouTube content, Chrome bookmarks, Google Keep notes, Google Tasks, and Google Sites. None of them migrate, and no setting in VaultMe adds them.

A softer version of the same boundary runs inside the four content types. Some individual items cannot be copied at all and are skipped; others are copied in a changed form, because the destination cannot hold them exactly as the source did and the closest faithful equivalent is what arrives instead. Both outcomes are recorded item by item in the migration report, with the reason, so the result is visible rather than silent.

Whatever turns out to matter needs an owner rather than a mention. Record it against the account on the inventory, together with who is handling it and how, so it ends up as a task somebody completed rather than a gap discovered after cutover. For where the line runs more generally, see "What is VaultMe".

Settling content scope for the project

For most projects this is quick work: email, files, calendars, and contacts, for every account in the inventory, decided in one pass and recorded alongside the inventory itself. The list below is the whole job.

1. Content types confirmed per account. Every account in the inventory has its content types settled, and the default and the recommendation is all four — email, files, calendars, and contacts — migrated together in one batch.
2. File areas decided. Each account's file areas are settled: its own files, and whether the files other people shared with it are included too. Every shared drive in scope also has one account named to carry it, so it is not copied a second time by everyone else who can see it.
3. What stays behind recorded. Everything that will not migrate is written down, each item with the person handling it and the plan for it.

None of this is locked in yet. Nothing is committed until a batch is paid for and started, and the free pre-migration scan reports real size and item counts per account for whatever is in scope, so borderline content can be revisited with numbers instead of guesses — see "How VaultMe works". What this checklist settles is entered per account when the project is configured, and stays editable for as long as the batch is a draft — see "Choosing migration options".

The next decisions build straight on the scope settled here. "Choosing a connection method" covers how each account is connected, and "Choosing a migration strategy" covers how the accounts are grouped into batches. The content types in scope also determine what has to be provisioned, licensed, and given sufficient storage on the other side, which "Getting the destination ready" covers.