Before you migrate

A migration can only start once a set of decisions, technical conditions, and people are lined up. This article describes what has to be true before that point, and which parts of getting there belong to you rather than to VaultMe.

What does it take to be ready for a migration?

VaultMe copies content between user accounts that already exist and that it can already reach. Its part of the work begins at the point where both sides are connected to it: before that, it cannot see the accounts, cannot check them, and cannot fix anything that is wrong with them. Getting to that point is yours to arrange.

The work that gets you there comes in three kinds:

• Decisions only you can make. What is in scope, how the project is shaped, and when it happens are judgments about the organization rather than questions VaultMe can answer, and very little can be prepared until they are settled.
• Each side in the state it needs to be in. The source has to be readable and the destination has to be writable. Those turn out to be two quite different amounts of work.
• People the project depends on. Some of what has to be true is not yours to finish. It depends on individuals who have to act, and on end users who have to know what is coming.

That is a way of dividing the work, not a running order. Preparation rarely falls into three tidy phases: decisions get revisited once real numbers appear, and readiness tasks on the two sides overlap. For the order the work usually happens in, see "Getting ready for a migration".

How much of it applies scales with the size of the project, not with VaultMe. A migration of a handful of user accounts whose content is already in the cloud, into a destination that already exists, arrives with most of these conditions met; confirming them is usually an afternoon's work. The same conditions apply to a thousand accounts across several domains, where satisfying them is a project in its own right.

None of this preparation costs anything in VaultMe. Signing up, connecting accounts, and running pre-migration scans are free and need no payment method on file, and payment is required only when you decide to start a batch. You can work through everything in this article, see exactly what VaultMe reports about the accounts, and still walk away having committed to nothing. See "Pricing and payment".

What do you need to decide before you start?

Some projects arrive with every decision already made: these twenty accounts, all of their content, into the destination set up last month, over the last weekend of the quarter. If that describes yours, the list below is something to skim and confirm rather than work through. It earns its place for the reader who has a goal — the organization is leaving its current provider — and no picture yet of what a migration involves.

A migration project opens with judgment VaultMe cannot supply. Which people have left and whose content still matters, what is worth paying to migrate, when a team can absorb a switch — none of that can be read out of the source. Until those calls land there is nothing concrete to prepare, because what has to be prepared depends on them.

There are six such decisions, and each one has an article that walks it end to end:

• What migrates, and whether each arrives live or archived. Every user account leaving the source needs to be on a list, together with any shared drives, shared mailboxes, and other types of resources coming along, and each entry marked as a working account or an archive. See "Building the migration inventory".
• Which content types are in scope. Email, files, calendars, and contacts, in whatever combination the project needs. See "Selecting content for migration".
• How each side connects to VaultMe. One environment-wide grant from an administrator, or each account connected individually. The two sides are decided separately and often differ. See "Choosing a connection method".
• Whether everything migrates at once or in waves. A single batch for the whole project, or a sequence that starts small and grows. See "Choosing a migration strategy".
• When it happens. The dates the run and the surrounding work are scheduled against, and how much time each stage realistically needs. See "Planning the migration timeline".
• How the switch lands afterwards. How and when people start relying on the destination instead of the source, and what happens to the domain. See "Planning the cutover and domain switch".

These come first because they set how much preparation follows. The same set of accounts migrated in waves, each one connected individually, is a different project from a small scope migrating into a destination that is already live and already licensed — different in the tasks it generates, the people it pulls in, and the time it consumes.

Making these calls does not lock them in. Scope stays changeable up to the moment a batch is paid for and started, and where a call is genuinely borderline — an account nobody is sure is worth migrating — the pre-migration scan puts a real item count and a real size behind it before you have to commit.

What does the source side need to look like?

The source side has to meet remarkably few conditions. A source user account is ready when VaultMe can connect to it through its provider and read what is inside. That is the entire bar, which makes the source the lighter half of the project.

Nothing has to be tidied first. VaultMe copies content rather than moving it and never modifies, deletes, or reorganizes anything in the source, so there is no need to clear out old mail, export anything, rearrange folders, or empty an account before a run. The source stays usable while the migration runs and stays intact afterwards.

What does block a source account is access, in one of two shapes:

• An account nobody can connect. A suspended or deactivated account has to be reactivated before it can be read, and where accounts are connected one at a time, an account whose holder cannot be reached cannot be connected at all.
• Anything reachable only through such an account. Shared drives, shared mailboxes, and document libraries are not connected in their own right — each is reached through a user account — so the account carrying one has to be connectable itself. See "Building the migration inventory".

The one condition that is not about access is also the likeliest disappointment. VaultMe reads only what the provider holds in the cloud for the connected account. Mail that a desktop client downloaded and removed from the server, contacts that live only on a handset, files sitting in a different cloud than the one connected — none of it is visible to VaultMe, none of it is reported as missing, and none of it arrives at the destination. Confirming that the content people expect to see afterwards is really in the cloud is a sweep you have to run yourself, with the people who know each account.

All of this is worked through in "Getting the source ready". It is the lighter half of readiness, and where the content is already in the cloud it can come down to little more than connecting the accounts and checking what comes back.

What does the destination side need to look like?

The destination asks for considerably more than the source, and one asymmetry explains most of it: VaultMe fills destination user accounts, but it does not create them. Every account that will receive content has to exist beforehand, and creating it is yours to do. Destination-side work is per user account, because a user account is what VaultMe connects to and writes into: content headed for a shared drive or a shared mailbox still arrives through a user account, and it is that account that has to be ready.

For each destination account, "exists" means four things:

• Provisioned and connectable. The account has to be there, and VaultMe has to be able to connect to it with permission to write.
• Licensed. Whatever licensing the provider requires for that account to hold content has to be assigned to it.
• Services active. The service behind each content type in scope has to be switched on for the account. A licensed account is not automatically a working mailbox or a working drive.
• Sufficient storage. The account needs enough storage for what its source counterpart will send, on top of anything it already holds.

If the destination is an environment already in daily use, nearly all of that is true the moment you look. The weight of this chapter falls on projects standing something up from scratch.

Above the individual accounts sits the environment itself — a Google Workspace organization or a Microsoft 365 tenant — along with the domains it uses and the mail-authentication records that a domain brings with it. None of this is VaultMe's work. All of it takes authority the migrating admin frequently does not hold, such as committing the organization to a contract or changing records at a domain registrar, and all of it is slow. It is the part of preparation most likely to decide when the project can start, which is the reason to begin it before anything else.

Storage is the one condition that cannot be sized by hand. What a destination account needs depends on what its source counterpart actually holds, and that number is one VaultMe reports from the pre-migration scan it runs over the connected accounts, not one you can estimate reliably. It is also the clearest reason the destination cannot be judged on its own: until VaultMe can see both sides, "enough storage" has no number attached to it.

All of this is worked through in "Getting the destination ready". It is the heaviest of the readiness work, and none of it is work VaultMe can do on your behalf — which is what makes it the part most likely to decide whether a project runs comfortably or in a rush.

Who needs to be involved?

If you are running a small migration single-handed, over accounts you control yourself, there is nobody to wait on and this chapter does not apply to you. It earns its keep on larger projects, and for anyone running a first migration who has not yet discovered how much of the schedule belongs to other people.

The claim is a simple one: part of readiness is not yours to finish. It depends on people VaultMe cannot reach and you can only ask.

The biggest variable is the connection method, which is why it belongs here as much as among the technical conditions. Connecting a managed environment is a single grant from a single administrator, after which every account inside it is reachable. Connecting account by account is an errand per account holder: a link to send, a sign-in for the holder to complete, a multi-factor authentication prompt for them to clear, and a follow-up for everyone who did not respond the first time. A shared drive or a shared mailbox in scope adds a person to coordinate with as well — whoever manages it — and those are easy to overlook precisely because nobody works in them daily. The migration itself is identical whichever method you choose; the human load is not comparable. See "Choosing a connection method".

Plan the calendar around that, honestly. Waiting on people is reliably the slowest and least controllable part of preparation. Licenses can be bought in an afternoon and storage raised in minutes, but an account holder on vacation is two weeks, and a connection link nobody opens takes as long as it takes to chase. When a migration date moves, this is usually the reason, not VaultMe.

The other half of the people side is the half no check can see. Everyone whose account is being migrated needs to know it is coming and what to expect from it, and anyone who has to do something needs to know what and when. Both are cheap to handle before the run and expensive afterwards, when the same information has to be delivered one support ticket at a time. See "Preparing stakeholders and end users".

What does VaultMe verify, and what does it not?

Planning gets you close; the pre-migration scan VaultMe runs is what actually confirms it. Once the accounts in scope are connected, VaultMe examines them through their providers and reports what is wrong, one to-do per account per problem, phrased as something to fix rather than an error to interpret. See "How VaultMe works".

Treat it as a working tool rather than a final exam. Scans are free, need no payment method, and can be run and re-run as often as you like, so the useful habit is to scan early and repeatedly as conditions change — not once, on the day of the migration, when there is no time left to act on what comes back.

The asymmetry between the two sides returns here in a practical form. A source can be checked on its own: create a project with only the source connected, scan it, and you know the source is readable long before a destination exists. A destination cannot be checked alone, because "ready" for a destination means ready for a particular source — enough storage for that source's real volume, the right services for the content types that source will send. Proving a destination therefore takes both sides connected at once.

What the scan sees is what the providers expose: whether each account is reachable, whether the permissions granted match what the migration needs, whether the services in scope are active, and how much content is there. What it cannot see is everything outside that. It does not know about content that never reached the cloud, whether the people whose accounts are migrating have been told, or whether there is a plan for the switch afterwards. A clean scan means VaultMe can do its part. It does not mean the project is ready. Where that line falls in practice is covered in the chapter on what a clean scan does not guarantee, in "Running the pre-migration scan".

What does not need to be ready first?

Most of the delay before a first batch comes from waiting on conditions VaultMe never asked for, so it is worth naming them.

The big one, and the confusion underneath the smaller ones, is the difference between being ready enough for VaultMe to migrate and being ready enough for the organization to live on the destination. Those are not the same standard, and only the first one gates a run. A migration runs account to account through the providers' own interfaces and changes nothing about how mail is routed: mail keeps arriving in the source mailboxes throughout, the domain keeps pointing wherever it points today, and nobody has to change how they work. Switching over is the finale of the project, planned separately and carried out after VaultMe has finished. See "Planning the cutover and domain switch".

The rest are smaller:

• Source accounts do not need to be cleaned or emptied. VaultMe never touches source content, so tidying beforehand buys nothing except a smaller bill where the content genuinely was not worth migrating.
• End users do not need to have stopped using the source. They keep working there normally while their account migrates, and whatever they change along the way is copied over afterwards.
• A destination already in use does not need to be cleared out. Migrated content is added alongside what is already in the account; VaultMe does not replace items that are already there.
• The whole project does not need to be ready at once. A batch needs only its own accounts ready, which is what makes a phased rollout possible in the first place.

The principle to leave with is that VaultMe asks for the smallest set of conditions that let it copy content correctly, and treats everything beyond that as your call about whether and when. Nothing is committed in either direction until a batch is paid for and started.

The section that turns all of this into actual work begins at "Getting ready for a migration".