Getting ready for a migration

Everything that happens before a migration starts falls into two halves: the decisions that define the project, and the work that turns those decisions into a source and a destination VaultMe can run against. This article walks through both halves and points to the article that covers each piece in full.

What does planning and preparation involve?

VaultMe joins a project at a specific moment: both sides are connected, a batch is configured, and that batch is paid for. Everything before that moment is yours to arrange, and it comes down to three things being true on the day a batch starts.

1. The decisions are settled. You know which accounts and which content are in scope, how each side connects, how the work is split into batches, when those batches run, and how the switch to the destination lands afterwards.
2. Both sides are in the shape VaultMe needs. Every source account in scope can be connected and read, and every destination account exists, can be written to, and can hold what its source counterpart will deliver.
3. The people behind the accounts in scope know what is coming. Anyone whose account is migrating has been told, and anyone the plan depends on — to authorize a connection, to confirm a result — knows what they will be asked to do and when.

The first of those is planning and the other two are preparation. The distinction is worth keeping, because the two halves feel nothing alike to work through. Planning is thinking: what is in scope, how the run is shaped and paced, when it happens, and how the organization stops relying on the source once it is done. None of it touches a system. Preparation is doing: provisioning and licensing destination accounts, activating the services the migration needs, making source accounts reachable, and coordinating with the people involved. All of it is concrete, and much of it happens outside VaultMe entirely.

The distinction describes two kinds of work, though, not two phases of a project. Decisions genuinely do drive preparation — you cannot provision a destination before deciding what it has to hold — but the dependency runs decision by decision rather than half by half. In practice the work loops: you settle enough to start preparing, learn something while preparing, then revise an earlier decision. A scan that puts real numbers behind a borderline account, or an account holder nobody can reach, sends you back to a call you thought was closed. That is the normal shape of the work rather than a sign the planning was done badly.

How much of this you actually face scales with the estate rather than with VaultMe. A handful of accounts whose content is already in the cloud, migrating into a destination that already exists, arrives with most of it settled — confirming the details is an afternoon's work rather than a project plan. The rest of this section is written so that the deeper material is there when the size of the migration earns it.

The rest of this section takes the pieces in the order they usually come up.

1. Settle the scope. Which accounts are migrated, and what happens to each of them, is the subject of "Building the migration inventory"; which content types come along is settled in "Selecting content for migration".
2. Decide how each side connects. The method is chosen independently for the source and the destination, and "Choosing a connection method" weighs both.
3. Get both sides into the state VaultMe needs. "Getting the source ready" covers everything that makes the source readable, and "Getting the destination ready" everything that makes the destination writable.
4. Shape the rollout. Whether every account runs in one batch or across a sequence of them is decided in "Choosing a migration strategy".
5. Plan the switch to the destination. How the organization finally stops relying on the source is covered in "Planning the cutover and domain switch".
6. Turn all of that into a schedule. "Planning the migration timeline" covers the calendar for the whole project, not just the window the run itself occupies.
7. Prepare the people the project touches. "Preparing stakeholders and end users" covers the half of readiness that no system check can see.

Only the two ends of that list are really fixed. Scope has to be roughly settled before much else is worth doing, and the schedule is only realistic once you know what readiness involves. Everything in between moves around: readiness work on a side can begin as soon as that side's connection method is settled, and long-lead items are worth pulling forward hardest of all — standing up a destination environment is worth starting the moment scope is roughly known, rather than waiting for every later decision to be final.

Which scope decisions need to be made?

Scope is the first thing to settle because everything else is measured against it. How many batches make sense, how long the run takes, what the project costs, how much provisioning the destination needs — none of those questions has an answer until you know what is in scope. Scope comes down to three decisions, and they are usually taken in this order.

• What is migrating. This is the migration inventory: the list of everything leaving the source, assembled and trimmed by hand. Most of it is user accounts, and shared mailboxes, SharePoint document libraries, and the files behind Teams and Microsoft 365 Groups can come along too, each with a little preparation of its own. Alongside the list, note what is genuinely out of scope, so that nothing is quietly assumed to be migrating when it is not; that boundary is drawn in "What is VaultMe".

  The list almost always starts longer than it needs to be: deactivated accounts, people who left years ago, test and service addresses, duplicates nobody cleaned up. Because VaultMe bills per migrated user account, every row you keep adds to the bill, so trimming to what is genuinely worth the spend is the point of the exercise rather than a footnote to it. See "Pricing and payment" for how that adds up.

• What happens to each entry that stays on the list. A user account is either migrated as a live one that somebody will keep working in, or archived so its content is preserved and findable but not used day to day. VaultMe organizes the destination differently in each case: a live account merges the migrated content into the structures already there, while an archived one keeps it in a dedicated, clearly labelled container (such as a folder or a label). The trade-off is mostly cost and clarity — a live account needs its own destination seat, whereas archived content from several accounts can be consolidated into far fewer. The same live-or-archived call applies to everything else in the inventory, not only to user accounts. The choice is made one entry at a time, and a single project routinely mixes the two.

• Which content comes along. VaultMe migrates email, files, calendars, and contacts, and a single migration can carry all four in one pass. For nearly every project the answer is all four, for every account, together — splitting them into a mail phase and a files phase costs more rather than less, because each batch is billed separately and the same accounts are charged again in the second one.

  Files carry one further choice, which the other types do not: which file areas each account brings — its own files, files other people shared with it, and any SharePoint document libraries or Teams and Microsoft 365 Group files it can reach. Those shared libraries are the part worth deciding deliberately rather than by default, because more than one account can end up bringing the same one across; "Selecting content for migration" works through the options.

Nothing here is locked in. Scope stays changeable right up until a batch is paid for and started, and the pre-migration scan is the natural checkpoint to review it, because it is the first point where the argument is about real numbers rather than guesses — the scan reports the actual size and item count behind every account in scope, which is usually what settles the borderline cases. Scans are free and can be re-run as often as you like, so this is a checkpoint rather than a commitment; "How VaultMe works" explains what it does.

Which operational decisions need to be made?

With scope fixed, what remains is the operational shape of the run. These decisions do not change what is migrated — the same accounts and the same content arrive either way. What they change is who has to be involved, how the work is paced across the calendar, and what end users experience around their own account's migration.

• How each side connects. Nothing can be read or written until both the source and the destination are connected to VaultMe, and the method is chosen independently for each side. Two are possible: an administrator connects an entire environment in one go, after which VaultMe reaches the in-scope accounts inside it without anyone signing in account by account, or each account is connected on its own under authorization scoped to just that account. The gap between them is almost entirely legwork, and it is the biggest single influence on how long preparation takes — one grant is a single conversation with one person, whereas connecting account by account means distributing links and waiting on every account holder who has to open one. The environment grant covers the source, so Microsoft 365 can be connected once by an administrator, while every destination account is connected on its own — which is where the legwork lands. See "Choosing a connection method".

• How the project is split into batches. A batch is the set of migrations that run together from one migration project, and the strategy decision is how many batches there are and what goes in each. Everything can go in a single batch and run at once — a big-bang rollout — which is the obvious choice for a small, clear-cut project. Larger or riskier ones are usually phased instead: a small test batch to calibrate, a pilot group, then the remaining production batches, with later batches often overlapping earlier ones. Splitting the same accounts across several batches does not raise the bill, since each account is migrated and billed once wherever it lands. See "Choosing a migration strategy".

• When it runs. The timeline turns that batch structure into a schedule. Duration is not something you can calculate from the size of the estate, and a few factors explain why:

  1. Item count and structure matter more than raw size. An account holding a very large number of small items, or a deep folder hierarchy, takes longer than a similarly sized account with fewer, larger items in a flat structure.
  2. Accounts in a batch generally run in parallel. The batch therefore finishes when the heaviest account finishes rather than when the average one does, and individual accounts complete at staggered times.
  3. Provider limits set the ceiling. VaultMe runs as fast as the source and destination providers allow and cannot go faster; in practice, writing to the destination is the more common bottleneck.
  4. Throttling becomes more likely as load rises. Many accounts running at once and heavy recent activity both raise the odds — most of all when the same accounts were already put through another migration attempt or bulk tool.

  The number you can actually schedule against comes from connecting the accounts to VaultMe and running the pre-migration scan, not from arithmetic. "Planning the migration timeline" covers how to build the calendar around it, and "What determines migration duration" goes further into what drives the run itself.

• How the cutover lands. Cutover is the phase where the organization shifts its primary reliance from the source to the destination. In practice that means reconfiguring mail clients, telling everyone to work in the destination, and eventually retiring the source. All of it is customer-side follow-up rather than a VaultMe step, and it comes after the migration rather than gating it — the source keeps working normally while batches run. It still belongs in the plan from the start, with the sequence understood and the dependencies cleared before the date gets close. The timing itself is forgiving: because sync-up migration (delta migration) carries across anything that changed in the source after the initial run, the switch does not have to be landed to the minute. See "Planning the cutover and domain switch".

These decisions interact more than they look like they do. Connecting a side account by account means depending on each account holder being reachable, which in turn decides who is ready when — and that often ends up shaping the batches themselves, because a phased rollout naturally stages around readiness. The articles behind each decision call out those knock-on effects where they matter.

What needs to be ready before kickoff?

Readiness is where the subject shifts from what to think through to what to actually do. Every decision above assumes certain conditions will be true on the day a batch starts, and readiness work is what makes them true. It splits into the technical side, where both source and destination have to be in a particular state, and the people side, which is quieter and easier to skip.

Getting both sides into the right state

On the source, readiness is about being able to read everything expected. Every account in scope has to be connectable and active, since a suspended or deactivated account cannot be read at all and has to be reactivated or consciously dropped. Beyond access, VaultMe reads only what an account holds in the cloud: mail a desktop client downloaded and removed from the server, contacts and calendars living only on a handset, files sitting in a different cloud than the connected one — none of it is visible to VaultMe, and none of it will be reported as missing either. Confirming that the expected content is really in the cloud is a sweep only you can run, and "Getting the source ready" explains how to approach it.

A little source-side hygiene helps as well, none of which changes what migrates. Trimming non-essential third-party apps and automation from source accounts frees up the provider capacity the migration competes for. More importantly, credential and policy changes on a connected account break the connection: a password reset, a change to multi-factor authentication settings, or an environment-level administrative change can silently drop it, and VaultMe pauses that migration until it is restored. Once accounts are connected, freeze those changes and coordinate any that are unavoidable.

On the destination, every account in scope has to exist and be reachable before anything can be written into it. VaultMe fills destination accounts but never creates them, so provisioning them is yours to do. The condition that most often goes unchecked is storage: each destination account needs enough of it for what its source counterpart will deliver.

Destination hygiene is worth a pass too. Automated rules on destination accounts — inbox rules, filters, auto-forwarding, auto-deletion — will act on migrated mail as it arrives and can misfile or discard it, so turn them off until the migration is done. The same freeze on credential and policy changes applies here, and it is better not to pre-fill destination accounts with content by hand, since that only invites duplication. "Getting the destination ready" walks the whole destination side.

Getting the people ready

The other half of readiness involves nobody's systems at all.

• Internal users need to know that their account is migrating, roughly when, what they will be asked to do, and who to ask. Most of the anxiety here is misplaced and easy to defuse: VaultMe copies rather than moves, nothing is deleted from the source, and there is no downtime, so people keep working normally while their account is being migrated.
• External collaborators are the group most often forgotten. Content shared outside the organization is migrated like everything else, but the access those people had does not follow it, so they have to be re-shared with afterwards. This matters wherever shared content is in scope.
• The person behind each account you have to connect individually becomes a genuine schedule dependency. Where a side connects account by account, someone has to open the connection link and clear multi-factor authentication for that account, and chasing the ones who do not is routinely the slowest step in a project. For anything that is not a user account, the equivalent is whoever looks after it — the person who manages the shared drive, or who knows what is in the shared mailbox.
• End users confirming their own result before their account is switched over is a small step that pays for itself. It catches anything missing while the source is still live, and it turns a change done to somebody into one they agreed to.

"Preparing stakeholders and end users" covers all of this in depth.

Hard gates and soft readiness

It helps to keep two kinds of readiness apart. A hard gate is a prerequisite VaultMe can observe for itself and checks during the pre-migration scan. A missing license, an unactivated service, insufficient storage, a wrong or partial permission set, an account that cannot be reached — the scan surfaces each one as a to-do to resolve, and a batch does not start while one is outstanding — see the chapter on why one unresolved to-do holds up a project, in "Running the pre-migration scan". That makes the scan the only real proof of technical readiness. Reasoning from a spreadsheet is not proof, and a connection that looks fine can still carry the wrong permissions. "Before you migrate" sets out what VaultMe checks and what it never asks for.

Soft readiness is everything a scan has no way to see, and it is where migrations actually go wrong. No check can tell you that a year of mail lives only in somebody's desktop client, that the person who has to authorize a connection is on holiday, that external collaborators were never warned, or that end users have no idea the switch is coming. So passing the scan is worth exactly what it says: VaultMe can do its part. An admin can clear every prerequisite the scan raises and still have a rocky migration, and when that happens it is almost always because the people side was left until afterwards.

Does the plan need to be written down?

VaultMe requires no plan document as input. There is nothing to upload, no template to fill in, and no stage of setup that asks for one. A small or medium migration runs perfectly well with the whole plan in the admin's head, and for a handful of accounts that is usually the sensible way to do it.

Past a handful, though, most admins end up keeping something anyway, and it is almost always the migration inventory itself — a spreadsheet, in practice Excel or a Google Sheet. That is not a coincidence: the inventory is the one artifact every later decision adds to. Which accounts are in scope, which batch each belongs to, which content types it takes, whether it is live or archived, whether it is connected and ready yet — each of those is a column on the same list rather than a separate document.

The VaultMe app happens to fit that habit well. Its account-list setup screens accept rows pasted straight from a spreadsheet, so when a batch's turn comes you can filter the sheet to that batch and paste its addresses in, which is faster and less error-prone than retyping them. At this point the list reduces to user accounts, since those are what the app connects and migrates. Where that paste goes, and what the app does with it, is covered in "Connecting and adding user accounts".

If you want a starting shape, roughly one row per account works, with columns for the source address, the destination it maps to, which batch it belongs to, which content types it takes, how it connects, whether it is live or archived, and where its readiness stands. That is a suggestion rather than a standard — the format is entirely your call, and VaultMe takes no opinion on it. "Building the migration inventory" goes into how the list is assembled and what is worth capturing per row.

Teams running larger projects often keep a second artifact alongside it: a timeline of milestones. Kickoff, the start and end window of each batch, the cutover, and the communications around them, usually in whatever tool already coordinates the team — frequently just a shared calendar. This one never touches VaultMe and will not change how the app behaves. Its value is entirely in stakeholder communication, and its accuracy depends on everything earlier in this section, because a milestone is only realistic once scope, rollout shape, and readiness work are understood well enough to date them.

Both artifacts are by-products of the planning the rest of this section walks through, kept because the team needs them to coordinate — not because VaultMe expects to receive them.