Choosing a migration strategy

Once the scope of a project is settled, the next decision is the shape of the rollout: whether every user account migrates together or across a sequence of smaller groups. This article covers how to make that call and, when the answer is a sequence, how to divide the accounts into batches and keep track of them.

What does choosing a migration strategy involve?

A migration strategy is the shape of the rollout: whether every in-scope user account migrates in one go, or in a sequence of smaller groups run one after another. It does not change what migrates or how VaultMe migrates it — only how the work is paced, and how many times it is launched.

For a small project this is a quick call. A handful of user accounts, a familiar setup, and no particular reason for caution: migrate everyone together and move on to the schedule. Everything else in this article — test batches, splitting principles, tracking a rollout across several launches — earns its keep on larger or riskier projects, where discovering a problem after everyone has already migrated is expensive.

By this point the scope of the project is decided: which user accounts are in the migration inventory, which content types they migrate, and how each side connects to VaultMe. This is the first of the operational decisions that follow, and it settles pacing rather than scope.

One term does most of the work here. In VaultMe you assemble a migration project — a list of user accounts and the configuration for how they migrate — and once it is paid for and started it becomes a batch: the set of migrations that run together, one migration per account. A strategy, then, is a decision about how many batches the rollout takes and which accounts go into each.

Two things decide it: how large the project is, and how much risk the organization can absorb. A third — how much about the migration is still unknown — pulls in the same direction as caution. Whatever comes out of this chapter stays changeable: a batch is committed only when it is paid for and started, so a strategy sketched now can be revised once there are real numbers to look at.

VaultMe does not dictate the shape. There is no requirement to stage anything, and no penalty for launching everything at once — a big-bang rollout is fully supported. The reasons for staging a rollout are administrator-side ones: coordination, communication, support load, and risk.

There is one rule on VaultMe's side. A single batch holds a limited number of user accounts. The cap is a guardrail against large-scale mistakes rather than a performance limit — it is not there because VaultMe struggles with volume — and a project larger than the cap is simply split into enough batches to fit. Those batches can still be launched in immediate succession, so the rollout remains a single pass. Splitting to fit the cap is not the same thing as phasing. The figure itself, and what the app does with a list that goes over it, are in "Connecting and adding user accounts".

The batch structure that comes out of this decision is what the schedule is then built on: the strategy sets the shape, and "Planning the migration timeline" turns that shape into dates. Deciding it here, once, is what keeps the question from being re-opened when the calendar is drawn up. What you should have by the end is a shape — one batch or several — and, if several, a list of which user accounts belong to which batch.

What are the two migration strategies?

Two shapes cover essentially every project:

• Big bang. Every in-scope user account goes into a single batch and migrates in one window, often scheduled over a weekend or outside business hours. There is one round of preparation, one announcement, and one cutover.
• Phased. The user accounts are divided across several batches that run in sequence, and usually overlap — a later batch can start before an earlier one has completely finished. The typical spine is a small test batch to calibrate, then a pilot batch, then the remaining production batches.

What a big bang buys is simplicity. There is one set of readiness checks to complete, one message to send end users, one window to staff, and the whole migration is over in a single pass. What it costs is exposure. Everything happens at once, so anything wrong with the setup is wrong for everyone, and there is no earlier run to have learned from. It also puts the heaviest possible simultaneous load on both providers, which makes provider-side throttling more likely, and it concentrates end-user questions into one moment.

A phased rollout trades that simplicity for control. Early batches are small enough to learn from: timings can be measured against VaultMe's estimate, surprises surface while they are still cheap, and the process can be corrected before the rest of the organization migrates. Provider load is spread out, and end-user issues arrive in waves that a small support team can absorb. The cost is coordination — several rounds of readiness checks and communication instead of one, a longer calendar overall, and a longer stretch in which people are working in the source and the destination at the same time.

What an early batch actually catches is usually mundane and specific: a user account that finishes migrating with years of mail missing, because those messages only ever lived in a desktop mail client and never in the cloud; a destination service that was never activated; a run that takes twice as long as the estimate because one mailbox holds far more items than anyone guessed. None of those is serious in a batch of five user accounts. All of them are a bad week in a batch of two hundred.

Phased does not necessarily mean slow. Batches usually overlap rather than running strictly one after another: as soon as an early batch is under way and looking healthy, the next can be launched. What phasing always stages is risk; it does not necessarily add time. The balance to watch is at the other end — overlapping many batches at once recreates exactly the simultaneous provider load that makes a big bang risky, so there is little sense in running everything in parallel under a phased label.

Phasing does not increase the cost of the project. Pricing is per migrated user account, so each account is migrated and billed once, whichever batch it lands in; splitting the same accounts across five batches instead of one leaves the total unchanged. See "Pricing and payment".

What it does change is when that cost falls due. Each batch is paid for before it runs and invoiced separately, so a phased rollout is paid for batch by batch as it proceeds, while a big bang settles the full amount at once. See "Pricing and payment".

Which migration strategy is the best fit?

Project size is the first cut, and for most projects it is the whole answer. The figures below are guidance drawn from experience, not thresholds VaultMe enforces:

• Up to roughly 20 user accounts — big bang. At this size staging buys almost nothing. Coordination is light, a test batch has little to teach that the pre-migration scan does not already show, and the extra rounds of communication cost more than they save. Migrate everyone in one batch and move on.
• Roughly 50 user accounts and above — phased. Start with a small pilot batch, or even a single test account, and split the rest into further batches from there. Committing 50 or more accounts before a single one has migrated means every assumption in the plan is tested on everybody at the same time.
• Between roughly 20 and 50 — a judgment call. Weigh the factors below. Where the setup is familiar and a bad surprise would be an inconvenience rather than a crisis, lean toward a single batch and keep the project simple. Thirty user accounts in one office, all connected and ready at the same time, make a comfortable big bang; the same thirty spread over three sites, becoming ready at different times, do not.

Beyond the raw count, the factors that tip a borderline project toward phasing are these:

1. Low tolerance for disruption. The question is not how likely a problem is, but what a bad surprise would cost. Where an interrupted day would be genuinely damaging, an early batch is worth the extra calendar time.
2. Unknowns. The less that is known in advance, the more an early batch is worth: a first migration, a first one between this particular pair of providers, or content volumes nobody has measured — high item counts especially, since item count drives duration more than total size does. A test batch turns those guesses into measurements. See "What determines migration duration".
3. User accounts connected one at a time. Where each account is connected individually rather than through a single environment-wide grant, it joins the project only once its account holder has acted — approved a connection link, or cleared a multi-factor prompt — so readiness arrives in waves. In a Google Workspace to Gmail migration, at least one side is connected account by account, so this applies to some degree whatever the strategy: batching around who is ready keeps the project moving instead of waiting on the last straggler. See "Choosing a connection method".
4. Throttling exposure. Both source and destination enforce their own limits on how much VaultMe can read and write, and many user accounts migrating at the same moment is one of the conditions that makes provider-side limiting more likely. Smaller consecutive batches keep the load below the level that triggers it.
5. Capacity to absorb the aftermath. A rollout produces questions, and someone has to answer them. Where support is one or two people, waves are manageable and a single wave may not be.

None of this is a commitment. A batch is only committed once it is paid for and started, and the free pre-migration scan reports each user account's real size and item count — so a borderline call can be revisited with numbers rather than guesses. See "How VaultMe works".

How is a phased rollout split into batches?

A phased rollout has a spine worth keeping even when everything else about the split is improvised: a test batch, then a pilot, then the production batches.

Start with a small, representative test batch — on a project at the smaller end of the range, a single test user account is enough. Its purpose is calibration rather than progress: to see how long a run actually takes against the estimate, to surface surprises while they affect one or two people, and to walk the whole process end to end once before it matters. Representativeness counts for more than size here. A batch made of the most convenient user accounts teaches little, so mix a typical account with one of the heaviest, since the heaviest accounts are what set the duration of every batch they sit in.

The pilot batch comes next: a little larger, drawn from a group that can tolerate a rough edge and report it constructively. It validates at small scale what the test batch calibrated. The remaining production batches follow.

Beyond that spine there is no single right way to divide the rest, and the principles below combine freely — pick whatever matches how the organization actually works:

• By organizational unit. A department, team, or office migrates together. Communication is simpler when everyone hearing the same message is on the same schedule, and a working group is not left collaborating across two systems.

• By user profile. Low-risk volunteers go early, as the pilot, and the most demanding users go last, once the process is proven. Some organizations do the reverse, putting power users first on the grounds that they will find the problems and can describe them precisely.

• By size and volume. Group user accounts by mailbox or drive size and item count, so that a batch's duration is predictable. Isolating the heaviest accounts keeps them from dominating an otherwise quick batch.

  As a rule of thumb, front-load the largest and most complex user accounts rather than saving them for last. They carry the most schedule risk: a very large mailbox or drive can run for days and finish long after everything else in its batch, and it is better to discover that early, with time still in hand.

• By readiness. Whoever is connected and reachable now goes first, and the rest follow as they become ready. This is the natural order wherever user accounts are connected one at a time, and it stops one unreachable person from holding up everybody else.

Whichever principle is used, the aim is the same: batches that are straightforward to coordinate, useful to calibrate from, and small enough to recover from.

Put together, a 60-account project might run as a test batch of two — one ordinary user account and the heaviest mailbox in the company — then a pilot of eight from the IT team, then the remaining fifty in three batches of roughly equal size drawn along department lines, with the department holding the largest content going first. Nothing about that shape is prescribed. It is simply what the principles above look like once they are applied to one organization.

There is one split to avoid. A batch is a set of user accounts, never a set of content types: dividing an account's content across batches — mail now, files next month — is a different exercise, and not a recommended one. Each batch is billed separately, so an account appearing in two batches pays the base migration fee twice, and the second round repeats the coordination for people who have already been through it once. Migrate all of a user account's in-scope content types together. See "Selecting content for migration".

Finally, keep each batch within the per-batch cap, and on a large project prefer several smaller consecutive batches to one enormous one. The cap sets the ceiling; throttling is the reason to stay well under it.

How are multiple batches tracked?

The moment a project is more than one batch, the split has to be recorded and tracked somewhere. That somewhere is the migration inventory spreadsheet, not VaultMe.

The inventory is already the backbone of the project: one row per user account, with a column added for each decision made about it — whether it migrates as active or archived, which content types it takes, how it connects, whether it is ready. Batching is one more column — a batch label per row. With that in place the sheet can be sorted and filtered to shape the split and to check it: that batch sizes are balanced, that no department has been cut in half, and that no account has been left out of every batch. See "Building the migration inventory".

The reason this is a need rather than a nicety is how the VaultMe app works. VaultMe holds one migration project at a time, and batches are launched one by one; there is no screen where an entire multi-batch rollout sits open, with the third batch drafted while the first is still running. A phased plan therefore cannot live in the app at all, which leaves the spreadsheet as the only place the full picture exists. That limit, and what it means for working alongside colleagues, is covered in "Creating a migration project".

The same lists of user accounts also get assembled more than once. Creating a temporary project to run a pre-migration scan is a normal way to confirm that a batch's user accounts are genuinely ready before the real run. The same set is assembled again when that batch is launched, and again for anything that has to be re-run afterward. Retyping addresses by hand each time is exactly where an account gets missed or duplicated; the sheet is what makes assembly repeatable.

On a multi-batch project, that means the sheet has to carry three things beyond the decisions already in it:

• Which batch each user account belongs to. One label per row turns the split from an intention someone remembers into a fact anyone on the team can check.
• A status per batch. Each batch needs a state — not started, launched, done — so that a glance at the sheet shows what is still pending and nothing is launched twice or quietly skipped.
• The connection and readiness columns already in the sheet. These get read per batch, so that no batch is launched before the user accounts in it are actually connected and ready.

The payoff arrives on launch day. Filter the sheet to the batch whose turn it is, copy that column of email addresses, and paste it straight into VaultMe's account-list setup screen, which accepts rows pasted from a spreadsheet. The batch is assembled in seconds, containing exactly the user accounts that were planned, with nothing retyped. How that paste works, including pairing each source account with its destination in the same pass, is covered in "Connecting and adding user accounts".

Without it, there is no overview across batches. Each batch page shows what that batch did, but nothing shows which user accounts have already migrated, which are still waiting, and which were never assigned anywhere — and the more batches there are, the faster that becomes a real problem.

None of this applies to a single-batch project. One batch, launched once, needs no tracking beyond the batch page itself.

Where do non-user-account resources fit in the batches?

Batches are assembled out of user accounts, and on most projects that is the whole of it. This is a secondary consideration: worth a moment on a phased rollout, and rarely something that changes the plan.

The exception is content that belongs to no one person in particular. A shared drive is owned collectively rather than held by a user account, and VaultMe migrates it within the file migration of a connected user account that has access to it, rather than on its own. It travels in whichever batch that account is placed in.

In a phased rollout the user account that carries collectively owned content lands in one batch or another, so it is worth deciding which one deliberately rather than by accident. A few pointers, none of which should be overstated:

• Keep it with the people who depend on it. Placing the carrying user account in the same batch as the team that works in that content daily, or whoever manages it, means the content arrives around their own cutover rather than long before or after it.
• Isolate a very large one. Collectively owned content can be far bigger than any one user account's own content, and its volume and provider load fall on whichever batch carries it — often a reason to place it in a lighter batch, or in a batch of its own.
• Do not strand a heavily used one late. Where many people have migrated and the content they collaborate in has not, they are working across two systems until it arrives.

Usually this is a minor placement call. Occasionally there is a real dependency — a department that works out of one shared area every day — and then a few minutes of deliberate thought pays for itself.

A checklist for choosing the migration strategy

Run this top to bottom:

1. Pick the shape from size and risk tolerance. Up to roughly 20 user accounts, one batch; 50 or more, phased, starting with a test batch or even a single test account; in between, a judgment call weighed against unknowns, connection legwork, throttling exposure, and how much support the project can absorb at once.
2. For a phased rollout, define the sequence. A small, representative test batch to calibrate — typical user accounts mixed with one of the heaviest — then a pilot batch drawn from a tolerant group, then the production batches.
3. Choose a splitting principle that fits the organization. Department, user profile, size and volume, or readiness, combined as needed, with the largest and most complex user accounts front-loaded. Keep each batch within the per-batch cap, prefer smaller consecutive batches on a large project, and record the split as a column in the migration inventory so each batch can be assembled straight from it.
4. Place shared content deliberately. Decide which batch the user account carrying collectively owned content belongs in, instead of letting the split place it by accident.

Remember that nothing is locked in. A batch is committed only when it is paid for and started, and the pre-migration scan reports each user account's real size and item count — enough to revisit a borderline call before any money is spent.

The batch structure this produces is the input for the schedule: "Planning the migration timeline" turns it into dates, batch by batch. How quickly those batches can follow one another also depends on the connection legwork on each side, since a user account joins a batch only once it is connected and ready. And cutover — the point where people stop relying on the source and start relying on the destination — is planned separately, on top of the shape decided here: see "Planning the cutover and domain switch".