Planning the migration timeline

Planning the timeline turns decisions that have already been made about scope and rollout into actual dates. It covers the schedule for the whole migration project, not only the stretch of it when VaultMe is running.

What does planning the migration timeline involve?

Asked to plan a migration timeline, admins sometimes reduce the problem to a single question: how long will VaultMe take to migrate everything? The answer becomes the schedule — pick a start date, add the estimated duration, and call that the plan. The instinct is understandable, and it is not so much wrong as incomplete. It treats the migration run as the project, when the run is one activity inside it. Left out are the readiness work that has to be finished before a batch can start, the cutover that completes the project, and the questions that arrive once end users are working in the destination.

How much of that matters depends on the project, and it tracks size fairly closely — a bigger project is usually also more complex and less able to absorb a bad surprise. Two cases sit at either end:

• A small, simple, low-risk migration has almost no timeline to plan. Everything gets ready, the migration project is created, the pre-migration scan produces a duration estimate, a little headroom is added on top of it, the batch runs, and the cutover follows. The run is the only real dependency in the schedule, so there is nothing to sequence around it.
• A larger, more complex, or less forgiving migration needs a genuine schedule. More has to be prepared, more people are involved, and more can go wrong — and that holds whether every user account migrates in one batch or across a phased sequence. Here the run is one segment inside a longer shape: preparation lead time, then the run with time reserved for it, then the cutover, then a tail of post-migration support.

This is not the place where scope or rollout shape gets revisited: which user accounts are in scope was decided in "Building the migration inventory", which content types in "Selecting content for migration", and the shape of the rollout in "Choosing a migration strategy". Planning the timeline takes the batch structure those produced and turns it into dates.

If the migration is small and straightforward, the next two chapters are enough, and it is reasonable to stop after them. Everything past that point is written for larger projects, where planning the timeline is an order of magnitude more involved.

How long does the migration itself take?

This is the one piece of the timeline every project shares, and the honest answer is a range. Small migrations usually finish within hours, large ones take days, and the very largest can run for weeks. There is no formula underneath those figures. Dividing total size by an assumed speed produces a number with almost no relationship to reality, because the things that actually govern duration are not visible in a total size.

For scheduling purposes, four of those things are worth knowing:

• Item count and structure matter more than total volume. VaultMe works through content item by item, so the number of items is usually the strongest driver of how long a user account takes. An account with a modest total size but a very high item count is a real timeline risk, and deep folder hierarchies take longer to replicate than flat ones. Two accounts holding the same number of gigabytes can finish hours apart.
• Accounts in a batch migrate in parallel, so the heaviest ones set the duration. Within a single account the content types in scope also run in parallel where the providers allow it, so that account's duration is set by whichever stream finishes last rather than by adding email, files, calendars, and contacts together. Across the batch, the same logic applies to accounts: the batch is done when its largest and most complex accounts are done, and everything else completes earlier, at staggered times. So batch duration is a question about individual accounts, never about the average one.
• Provider limits are the ceiling, and nothing raises them. VaultMe does not hold back its own throughput; it runs as fast as the connected systems will sustain. What bounds that speed is the source and destination providers' own limits — per-minute caps on operations, and longer quota windows they enforce to keep their services stable for everyone. Reading from Gmail and writing into Microsoft 365 are both bounded this way, and in practice destination writes tend to be the slower half, so that side often sets the pace. No setting makes this go faster.
• Exposure to throttling varies, and some of it is self-inflicted. Providers tighten limits when an account looks unusually busy. The heaviest contributors are an earlier migration attempt on the same accounts — with VaultMe or with any other bulk tool, which all but guarantees immediate limiting — plus heavy activity in the days just before the run, and too many accounts launched at once. When a longer quota window is exhausted, the migration pauses until that window resets.

The number worth planning around does not come from arithmetic, then; it comes from the VaultMe app. Connect both sides, create a migration project, and run the free pre-migration scan. The scan reads each account's real size and item count and produces a duration estimate from them, which is why account counts and storage totals collected in advance are not enough to plan on. What the scan does is described in "How VaultMe works".

Even then, never commit to that estimate bare. It is a projection rather than a guarantee, and it can shift while the migration runs as VaultMe observes how the accounts really behave. Add buffer before giving anyone a date, and on a larger project calibrate the estimate against a representative test batch before trusting it for everything else. The full account of what makes a migration fast or slow is in "What determines migration duration"; this chapter carries only enough to schedule around.

How do I plan a small migration?

If the project is a handful of user accounts migrating in one batch, with no unusual constraints, there is barely a timeline to plan. The whole sequence fits in a short list:

1. Finish the readiness work first. Get the source readable and the destination able to accept what is coming — described in "Getting the source ready" and "Getting the destination ready". No amount of scheduling helps if the accounts are not ready on the day.
2. Create the migration project and run the pre-migration scan. One project with both sides connected is all it takes, and the scan is free. This is where the duration estimate comes from.
3. Take the estimate at roughly face value, then reserve a bit more than it says. A migration estimated at three hours can run longer for reasons nobody could have predicted, so reserve the day rather than the hours.
4. Start the run and let it work. Ask end users to carry on in the source as normal and to stay out of their destination account until their own migration has finished — the reasoning behind those two requests is in "Preparing stakeholders and end users".
5. Cut over once the batch has finished and been checked. There is no mail routing to switch here, so the cutover is simply the point at which each account holder starts using the destination account and stops using the source account, as described in "Planning the cutover and domain switch".

What keeps this simple is that the run is the only moving part: nothing else in the schedule is waiting on anything, so a day either way changes nothing. It also helps that every migration ends with a sync-up migration (delta migration), which copies whatever changed in the source while the run was going. The cutover therefore does not have to be timed to the minute — a gap between the migration finishing and the switch happening is normal and safe.

Even a small migration leaves a short tail of questions in the days after the cutover, though, so leave a little room for it. That is the subject of "Planning for the post-migration period".

How do I plan a larger migration?

On a larger project the question changes shape. It stops being "how long will the run take?" and becomes "where does the run sit among everything else that has to happen?" — and the answer is frequently that the run is not the longest part of the project. Preparation often outlasts it.

What makes a project larger in this sense is size and complexity, not the shape of the rollout. A big-bang migration of eighty user accounts is still a large project; one batch does not make it a small one. It needs the same full preparation lead time, the same generously reserved run window, and the same post-migration budget as those eighty accounts would need split across five batches.

The shape to plan has four segments, in order:

1. Preparation lead time. This is everything that has to be true before a batch can start at all, and on a large project it is where most of the calendar goes.
2. The run, with time reserved for it. This is the estimate plus deliberate headroom, positioned so the batch does not have to finish on any particular day.
3. The cutover. The switch to the destination happens after the batches have finished, rather than being squeezed in among them.
4. The post-migration tail. Support load, manual follow-up, and the questions that arrive once people are working in the destination for real all land here.

Phasing adds a coordination layer on top of that shape rather than changing it. Instead of one run window there are several, usually overlapping, since a later batch can start before an earlier one has completely finished. Each is gated on its own readiness: that batch's accounts provisioned, connected, and scanned. More batches means more to sequence and more to keep track of, and because VaultMe launches one batch at a time, the full multi-batch picture lives in the migration inventory spreadsheet rather than in the app — see "Choosing a migration strategy". Phasing is a response to scale, though, not the source of the complexity: the eighty-account big bang has all of the same preparation, just without the sequencing.

This is where planning from one number does real damage. A date derived from the run estimate alone quietly assumes everything around the run is already done — accounts provisioned, connections in place, the people who have to act available when needed. Where one of those assumptions is wrong, either the cutover slips or it happens on schedule with the migration still unfinished behind it.

The rest of this article is the alternative, in three moves: reserve time around the run, work backward from the cutover date to place everything the run depends on, and budget the period afterward. None of it is locked in while you do it — scope, strategy, and dates all stay changeable until a batch is paid for and started, which is the point of no return described in "Pricing and payment".

How much time should I reserve for the run?

For a larger project this is the core of the exercise, and it starts with separating two words that get used interchangeably. The estimate is what VaultMe calculates. The reservation is how much calendar you set aside for it — a judgment, deliberately less precise than the estimate, and always larger than it.

Start from the estimate produced once both sides are connected and scanned. It is grounded in each account's real size and item count, and it is reliable enough to build a reservation on by itself.

Better still, validate it before committing the rest of the project. A large project runs a small test batch anyway, so use that batch for calibration: make it representative rather than convenient, mixing typical accounts with the heaviest ones, since the heaviest accounts set the ceiling for whichever batch they land in. Then compare the actual duration against the estimated one. If it came in close, trust the estimates for the remaining batches. If it ran long, scale the remaining reservations by roughly the same factor. How to compose that batch is covered in "Choosing a migration strategy".

With a number in hand, reserve generously rather than precisely:

• Assume it will take longer than estimated. Something unforeseeable usually intervenes — a provider slowdown, a connection that dropped overnight, a pocket of old corrupted items that costs retries and recovery work to get through. Where the estimate is already measured in days, doubling it is a sound default.
• Reserve whole days, not hours. An estimate of three hours becomes a day, not six hours. The day is the planning unit, because a day leaves room to notice a problem, resolve it, and still finish. On the largest projects the unit becomes weeks, and reserving four weeks is not unusual.
• Write a reservation per batch on a phased project. Each batch gets its own estimate plus its own headroom, recorded in the plan rather than held in someone's head. Pull the longest and riskiest batches forward so they carry the most headroom, and leave a day or two of recovery margin around each one, before that batch's cutover.

Over-reserving is close to free, which is what makes generosity easy here. The run does not have to land on the cutover date: it can finish comfortably early, because the sync-up migration (delta migration) that follows carries everything that changed in the source in the meantime. Spare margin costs calendar and nothing else. How that catch-up fits the end of the project is explained in "Planning the cutover and domain switch".

There is a limit to how early is useful, though. VaultMe keeps the index that pairs each migrated item with its destination copy for 30 days after the most recent run, and every sync-up refreshes that window. Finish a batch months before its cutover and you have committed yourself to running periodic sync-ups purely to keep the window open. Early but reasonable is the target: weeks of margin, not months. How that window works is in "How sync-up migration works".

Working backward from the cutover date

A migration calendar is far easier to assemble backward than forward, because exactly one date is chosen and the rest are consequences of it. Working from the end:

1. The cutover, fixed first. Every other date hangs off this one, so choose it before anything else. In a Gmail to Microsoft 365 migration, there is no mail delivery to repoint at the cutover, so the date is governed by when the people involved are available rather than by anything technical. Leave enough room around it for a final sync-up migration (delta migration) and for each account holder to confirm the destination looks right before they stop using the source account.
2. The run window, ending well before the cutover. Position the reserved window so the batch finishes early rather than on the day of the switch. The sync-up migration then carries whatever changed in the source in between, which is what keeps the run from ever racing a deadline.
3. The readiness work, each piece landing before whatever depends on it. Destination accounts have to exist before they can be connected; both sides have to be connected before the pre-migration scan can prove anything; the scan has to pass before the batch can run. Where a side connects account by account rather than through a single admin grant, this step is paced by people rather than by systems: links have to reach account holders, the holders have to open them, and multi-factor authentication prompts have to be cleared. That legwork decides who is ready when, and it is the most common reason a batch starts later than planned — see "Choosing a connection method".
4. The destination environment underneath those accounts. It has to exist before any account can be created inside it, and standing one up takes someone with the authority to commit the business to it — often not the admin running the migration. Domains have to be added and verified, which means placing a DNS record at the registrar, often through whoever controls it. Licenses have to be bought and assigned, and the services for the content types in scope activated. A brand-new domain may additionally need mail-authentication records and a period of gradual sending before it can carry the organization's mail without being treated as spam. None of this is VaultMe's work, none of it happens quickly, and any of it can slip the whole plan — see "Getting the destination ready".

The lead time this chain produces is the whole argument of this article made concrete: it is where the earlier decisions in this section turn into dates. On a small project the chain is a day's work. On a large one it can run for weeks or months and outlast the migration itself — even when everything migrates as a single big-bang batch, because a big batch needs every account provisioned, connected, and scanned before it can start.

On a phased project the chain repeats rather than running once. Each batch has its own version of it, overlapping with its neighbors, and the cutover becomes the finale after the last batch rather than the end of a single window. What you end up with is a staged calendar, which is more to draw but no harder to reason about, because every stage is the same short chain.

Planning for the post-migration period

The days after the cutover are a plannable segment of the project, not the moment it stops. Every project has one; it grows with project size, and it is the part most often left off the calendar altogether.

What happens is predictable. End users start working in the destination for the first time and they have questions: where a folder went, why a shared file is not shared any more, how to add the new account to a phone. Some of that is genuine follow-up work and much of it is simply people relearning where things are. Either way it is normal, particularly on an organization's first migration, and it is real, finite work that has to sit somewhere on the schedule.

It costs time because of one dynamic worth naming plainly: for a while after a cutover, anything an end user cannot immediately find gets attributed to the migration, whether or not the migration had anything to do with it. So there will be support load no matter how clean the run was. Budget a window for it — heaviest in the first day or two, tapering after that — and name the person who fields it rather than assuming someone will pick it up. Who that should be is discussed in "Preparing stakeholders and end users".

Part of the tail is genuinely manual work, and knowing what it consists of is enough to budget for it:

• Items placed in a destination TODO area. Where VaultMe cannot put an item where it belongs, it puts it somewhere clearly marked instead, usually a folder or label with TODO in the name, created for a content type only when something in it actually needs review. Nothing is lost, but somebody has to go through those items afterward and file them.
• Links that pointed at the source. Links embedded in migrated content are preserved exactly as they were rather than rewritten to point at the destination copies, so links that referred to source items stop working once the source is retired. That is expected behavior rather than a fault, but the important ones have to be found and updated by hand.

On top of those, the access other people had to shared files does not follow the content into the destination, so end users re-establish sharing themselves — including with collaborators outside the organization, who are the ones most often forgotten. The full follow-up list, with an owner against each item, belongs in the cutover plan: see "Planning the cutover and domain switch".

The largest single lever on the size of this window is work done before the migration rather than during it. End users who were told what was happening, what would look different afterward, and who to ask, and who got to confirm their own destination looked right before being switched over, generate a fraction of the questions. Effort spent up front trades directly against support time after the cutover, which is the argument of "Preparing stakeholders and end users".

One last thing to expect is that the source stays live for a while afterward — and keeping it that way is not merely normal but recommended. Changes made in the source up to the cutover are carried across by the sync-up migration (delta migration), and VaultMe never alters or deletes source content, so the source survives the project as an intact fallback at no cost beyond whatever it takes to keep it open. Retire it once the destination has been in real use long enough to be trusted, not at the moment of cutover, and plan the calendar around a period in which both sides exist.

What are the timeline risks and how do I avoid them?

Schedules come apart in two distinct ways: something stalls the migration run, or something slips the dates around it. Most of these share the same two defenses — generous buffer and an early start — and a small, low-risk migration will barely meet any of them.

What stalls the run

• A connection drops mid-run. If either side of a migration loses its connection, VaultMe pauses that migration until the connection is restored. The usual trigger is a password, credential, or multi-factor authentication change made on a connected account while the migration is running. Freeze those changes from the moment setup begins until the run is done, and coordinate any that genuinely cannot wait.
• Throttling turns out heavier than assumed. The run does not fail; it drags — sometimes for a day, while a provider's longer quota window resets. The causes are the ones described in "How long does the migration itself take?", and the two of them you control translate directly into schedule rules: keep other bulk tools off the accounts in the run-up, and stagger batches instead of launching everything at once. Past that, calibrate with a test batch rather than assuming the estimate holds under load.
• End users start working in the destination before their migration finishes. Changes made to content that has already been migrated force VaultMe to reconcile the difference, re-synchronizing content or rebuilding structure it expected to find. That costs throughput and time and raises the risk of an inconsistent result. Keep people out of their destination account until their own migration has completed, as "Preparing stakeholders and end users" explains.
• Individual items will not migrate, or a provider has an incident. Items that fail are retried automatically, and any that still do not go through are escalated to VaultMe for review, usually cleared within a day; if there is nothing else left to process meanwhile, the migration waits. Provider-side slowdowns behave much the same way. Neither is preventable and neither means anything was set up wrong — this is precisely what buffer exists for.
• The estimate changes while the run is going. VaultMe revises it as it observes how the accounts actually behave. That is expected rather than a warning sign. The way to keep it from hurting the schedule is to treat the estimate as a projection throughout and never publish it as a committed finish time.

What slips the dates

• A long-lead prerequisite is not ready. This is the most common cause of a slipped cutover by a wide margin, and it is almost always something that had to be bought, verified, or granted by somebody outside the project. Front-load these ahead of everything else, as in "Working backward from the cutover date".
• The people the plan depends on are not available. That includes account holders who have to authorize their own account or clear a multi-factor authentication prompt, end users who have to confirm before their account is switched, and the IT staff who need to be around during the cutover window. Vacations, public holidays, and time zones do most of the damage. Line people up early, and check availability before fixing the cutover date rather than after.
• Launch day arrives and the accounts are not actually ready. An account that was never finished being set up, a service or access setting still switched off, storage short of what is coming — and the start slips before it begins. Do not take readiness on trust: run the pre-migration scan well ahead, and on a larger project confirm each batch's accounts at least the day before that batch launches. A temporary project and a fresh scan are a cheap way to do it, which is the argument of "Getting the destination ready".
• The plan changes after the batches have started. Adding accounts, changing which content types are in scope, or reopening the rollout strategy once migrations are running all mean rework. Lock scope and strategy before kickoff; both stay open to change until a batch is paid for and started, under the per-batch billing described in "Pricing and payment".
• The finish is crammed against the cutover. If the run is scheduled to end on the morning of the switch, there is no buffer left, so every risk above lands directly on the cutover date. Start early instead and let the sync-up migration (delta migration) bridge the gap, rather than aiming to land on the minute.
• Nobody owns the aftermath. The support tail lands regardless; without an owner it lands on whoever happens to answer. Name that person and budget the window, as in "Planning for the post-migration period".

Not all of these can be prevented, and it is a mistake to try to schedule them away precisely. Buffer and an early start are what absorb the unpredictable ones. The preventable few are cheap insurance by comparison: frozen credentials, other bulk tools kept off the accounts, decisions locked before kickoff, and people lined up in advance.

A checklist for planning the timeline

A small migration

1. Get both sides ready, then create the migration project and run the free pre-migration scan.
2. Read the duration estimate and reserve somewhat more time than it gives — a full day where it says hours.
3. Run the batch, keeping end users out of their destination account until their own migration finishes.
4. Cut over once the batch has finished and been checked, and leave a few days afterward for questions.

A larger migration

1. Fix the cutover date first, including the time of day. It is the only date in the plan that is chosen rather than derived, and everything else is placed relative to it.
2. Earn a number worth trusting. Connect both sides and run the pre-migration scan; where the project is large enough, validate the estimate against a representative test batch or a single test account before relying on it for the rest.
3. Reserve generously rather than precisely. Double the estimate as a default, work in whole days rather than hours (weeks on the largest projects), and write the reservation down per batch instead of carrying it in your head.
4. Position the run early rather than at the end of its window. Let the sync-up migration (delta migration) carry whatever changes afterward, and on a phased project put the longest and riskiest batches first, with recovery margin around each one.
5. Chain the preparation backward from the run. Long-lead items go earliest — whatever has to be bought, verified, or granted outside the project — then the rest of the destination groundwork, source readiness, connections, and the people work, in the order set out in "Working backward from the cutover date".
6. On a phased rollout, lay the batch sequence out explicitly. Each batch gets its own run window, overlapping with its neighbors and gated on its own readiness, and the cutover comes as the finale after the last one.
7. Guard the derailers you can control. Freeze credential changes on connected accounts, keep other bulk tools off the accounts, lock the decisions before kickoff, and line the people up — then let buffer absorb what is left, as in "What are the timeline risks and how do I avoid them?".
8. Budget the post-migration window and give it an owner. Then shrink it by doing the people work before the migration rather than after.

With dates on the calendar, two things are left. The people the schedule depends on still have to be prepared for it, which is the subject of "Preparing stakeholders and end users", and the switch those dates build toward has to be planned in detail, in "Planning the cutover and domain switch".