What determines migration duration

This article explains what determines how long a VaultMe migration takes, and what to do with that information when you schedule a project.

How do I get a timeline estimate for my project?

The number worth planning against comes from VaultMe rather than from arithmetic. Create a migration project, add the source and destination user accounts to it, and let the pre-migration scan run; those two steps are covered in "Creating a migration project" and "Connecting and adding user accounts". The scan examines what is actually in the accounts — how many items they hold and how much content that adds up to — and produces a duration estimate alongside the cost figures, while the project is still an editable configuration and before any batch has started. What else the scan checks is covered in "How VaultMe works", and how to read the figures it hands back is covered in the estimates chapter of "Running the pre-migration scan".

Both sides have to be in place before that estimate means anything. Reading from the source and writing to the destination are separate constraints with separate limits, and the destination is usually the narrower of the two, so a figure derived from the source alone would miss the half of the migration that most often governs the pace.

There is no formula that replaces this. Total size divided by a speed figure does not work, because there is no single speed to divide by: providers meter migration work per operation and per item rather than per gigabyte, the limits they apply differ from one account to the next and shift with how each account has been used recently, and the way content is organized changes how much work the same content represents. High-level inputs alone — how many user accounts are in scope, how much storage they occupy in total — are not enough for a timeline anyone should schedule around. Two accounts of identical size can finish hours apart.

For a rough sense of scale before anything is connected, the useful rule of thumb is that small migrations are measured in hours and large ones in days. Very large projects run longer still, and they need significant additional time for planning and provisioning on top of the run, so on those projects the run stops being the piece of the schedule that matters most. "Planning the migration timeline" covers how to turn any of this into a calendar.

One thing to know before you quote the estimate to anyone: it is a projection rather than a commitment, and it can move while the migration runs. See "How accurate are VaultMe's time estimates?".

How fast is VaultMe?

VaultMe is built to migrate very large amounts of content quickly, and it has no internal performance limits. There is no throughput cap set below what the connected systems can sustain and no deliberate slow lane; whatever capacity is available at a given moment, VaultMe attempts to use all of it, and it continuously aims for the highest stable speed current conditions allow.

The ceiling is not VaultMe's to set. All content moves through the public APIs the providers publish — the same interfaces available to any other application — and those APIs are metered. Providers impose throughput ceilings, quota windows, throttling that tightens dynamically, and load controls that respond to how busy their own systems are.

Those controls exist for reasons that have nothing to do with migration. Providers run shared infrastructure, so they meter API use to protect service stability, to keep capacity fair across every customer they serve, and to contain abusive or excessive load. A migration is precisely the kind of workload those controls were designed for: heavy, sustained, and automated. Being limited is therefore not a symptom of anything wrong with the project or the accounts.

Both sides meter independently. The source limits how quickly content can be read, and the destination limits how quickly it will accept what is written. In practice the write side is usually the tighter one, because accepting an item means processing, indexing, and storing it, which is heavier work than serving a read. Migrations often end up waiting on the destination even when the source could supply content faster.

The consequence is that VaultMe sometimes has to run slower than it could, and sometimes has to stop and wait for a limit window to reset. That is expected, correct behavior rather than a fault, and it is why a migration that has gone quiet is usually waiting rather than broken. The wider picture of how VaultMe reads and writes is in "How the VaultMe platform works".

How does VaultMe enable the maximum possible speed?

Parallel execution is the main thing VaultMe does to stay fast, and it happens at two levels:

1. Within one user account. The content types in scope — email, files, calendars, and contacts — are processed as parallel streams wherever provider capabilities allow. An account's duration is therefore set by whichever stream finishes last, not by adding the streams together. An account whose mailbox holds hundreds of thousands of messages can still be copying mail long after its files, calendars, and contacts are complete.
2. Across a batch. The user accounts in a batch are generally processed in parallel as well. Batch duration is therefore governed by the largest and most complex accounts in it rather than by the average, which is why adding several more small accounts to a batch usually costs little extra time, while adding one very large account can extend the whole batch.

There is one deliberate exception. When the same user account takes part in more than one migration at the same time, whether as source or as destination, all of those migrations draw on the same provider capacity for that one account, and running them simultaneously would only make them compete. VaultMe prefers sequential processing where parallel execution would overload a shared account: in particular, several migrations writing into the same destination account are typically scheduled one after another rather than concurrently. Archive consolidation is the common case, where content from several source accounts is collected into a single destination account.

When a limit is reached, VaultMe neither stops nor gives up on the affected user account. It keeps monitoring and retrying within what the provider currently allows, and continuously attempts to bring each affected account and each affected stream back to the highest speed that provider permits. As soon as capacity returns, throughput recovers without anyone intervening. Because limits apply per account and per stream, different parts of the same batch can be affected very differently at the same moment — one account crawling while the rest run at full speed is a normal picture, not a sign that the slow one is stuck.

What are the key factors that determine migration speed?

Because the user accounts in a batch run in parallel, and because each account's content types run in parallel within it, a batch rarely has a single batch-wide bottleneck. What decides the timeline is what is true of individual accounts: how much they hold, how it is organized, which limits their providers are applying, and what else is happening in them while they migrate. Averages mislead for the same reason — a batch is finished when its heaviest account is finished, not when a typical one is.

Per-minute limits on the service providers' side

Providers cap how many operations they will serve in a short window, usually measured per minute: how many items may be read, how many may be created. When a cap is reached, or when the provider tightens it dynamically because its own systems are under load, the migration slows down but keeps running. Caps of this kind apply on both sides — the source meters reads and the destination meters writes — and the write side is usually the tighter one. Short-window limits are the most common reason a migration is clearly making progress but making it slowly.

Daily limits on the service providers' side

Providers also enforce limits over much longer windows, from roughly an hour up to a full day, and often on a rolling basis rather than resetting at a fixed time. These behave differently from per-minute caps: once a long window is exhausted there is no reduced rate to fall back on, so a migration can pause outright until the window resets. It then continues on its own; there is nothing to restart and nothing to fix. This is the main reason a single large user account can span several calendar days while spending part of that time waiting rather than copying.

Account size and composition

This is the largest source of variation between user accounts in the same batch. Four properties matter:

• The number of items. Provider APIs work item by item — one message, one file, one event, one contact at a time — so duration is primarily a function of how many items an account holds rather than how many gigabytes it occupies. Item count is the strongest single driver of duration, and it is the number worth checking when judging whether a particular account is a schedule risk.
• The total size of the content. Larger items take longer to copy than smaller ones, so an account full of heavy attachments, media, or long documents takes longer than its item count alone would suggest. Count and size pull in different directions: a hundred thousand short messages and a few hundred large video files can occupy similar storage and behave nothing alike.
• The mix of content types. Some kinds of items need more processing than others, so two accounts with identical item counts can still take noticeably different amounts of time depending on what those items are.
• How the content is organized. Structure has to be replicated in the destination rather than simply copied, and a deep hierarchy of nested folders takes longer to reproduce than a flat arrangement. An account with a few thousand folders nested several levels deep is more work than an account holding the same content in a dozen folders.

Between them, these four are why storage totals make a poor predictor of duration, and why an estimate is worth having only once the pre-migration scan has measured what the accounts actually contain.

Previous account activity

Provider limits are not fixed thresholds applied to each migration in isolation. Providers weigh how heavily a user account has been used recently when deciding how much more to allow, so an account that was worked hard in the days immediately before its migration may already be close to its limits when the run begins, and it will be throttled sooner and harder than a comparable quiet account.

Bulk processing is the extreme form of this and the one most worth avoiding. If the same accounts were previously put through a migration attempt — VaultMe's or another tool's — or through any other bulk-processing job, provider-side limiting is much more likely to show up early in the new run. An earlier attempt that was abandoned partway is the usual example, and it makes the second attempt slower than the first would have been.

Concurrent account activity

Anything else using a user account while it migrates draws on the same provider capacity the migration needs. End users going about their normal work have a modest effect. Automation has a much larger one: backup tools, synchronization clients, archiving jobs, and third-party integrations can generate far more API load than a person, and they generate it continuously.

Activity in the destination carries a further cost beyond the capacity it consumes, because changes to content that has already been migrated can oblige VaultMe to redo work it had finished. That is covered in "Can users continue working in the accounts during the migration?".

Broken or corrupted items

Items that are corrupted or internally inconsistent slow a migration in two ways. VaultMe retries them rather than abandoning them at the first failure, and every one of those attempts consumes provider capacity that healthy items would otherwise have used. Repeated failures across a group of problem items can therefore push a user account nearer its limits and make everything else in that account slower too.

Provider-side technical issues

Providers occasionally have slowdowns, degraded API performance, or intermittent instability of their own. When that happens the migration is affected regardless of how well the project was prepared, and there is nothing on either side to correct. VaultMe carries on working within whatever capacity is available and recovers as the provider does. Incidents like these are unpredictable and unpreventable, which is the strongest argument for keeping buffer in the schedule rather than planning to the estimate exactly.

Will all accounts finish migrating at the same time?

No, and a batch is not expected to finish evenly. User accounts generally start together and run in parallel, but each one carries its own item counts, its own structure, and its own provider limits, so they complete at different times — sometimes hours apart, sometimes days.

In practice the smallest accounts often finish within the first hours while the largest are still working. The batch is complete when its largest and most complex accounts are complete, which makes those accounts the ones that set the end date. Identifying them before the run is more useful than discovering them during it; "Choosing a migration strategy" covers how batch composition can be arranged around them.

The same pattern appears inside a single account, where content types run in parallel and complete independently. The types holding the fewest items are usually done well before the ones holding the most.

Two practical consequences follow. An account still running long after its neighbors have completed is not evidence that something is wrong with it; it is usually the largest account in the batch doing what large accounts do. And the moment the first accounts finish is not the moment the migration can be treated as done, so cutover planning has to work from the last completion rather than the first.

There is one case where accounts genuinely do run one after another by design: when several migrations write into the same destination account, VaultMe schedules them sequentially, so those complete in sequence rather than together.

How accurate are VaultMe's time estimates?

Reliable enough to plan around, not precise enough to promise. A duration estimate is a projection built from what the pre-migration scan measured, and it is explicitly not a guarantee.

What the estimate cannot know in advance is how the user accounts will behave once they are actually running: how much capacity the providers will grant on the day, how much of it other activity in those accounts will take, whether a long quota window will be exhausted, whether a provider will have a bad hour. None of that is visible until the migration is under way.

Estimates therefore change during a run, as VaultMe observes the accounts in live conditions. An estimate that moves is expected behavior rather than a failure signal, and it is not in itself a reason to contact anyone or intervene — it is better read as a projection that is kept current than as a finish time that has slipped.

Two things make it more trustworthy. The first is the scan itself: a figure inferred from account count and total storage is not a reliable timeline, whereas one derived from measured item counts and structure is. The second is calibration on larger projects. A small representative test batch, mixing typical accounts with the heaviest ones, turns the projection into a measurement: if the actual run tracked the estimate, the estimate can be trusted for the accounts that follow, and if it ran long, expectations for the rest can be scaled by roughly the same margin.

Whatever the estimate says, commit to a date with buffer on top of it rather than at face value, and treat accounts with high item counts as the schedule risk even when their storage totals look unremarkable. How much time to reserve, and how to build the rest of the calendar around it, is covered in "Planning the migration timeline".

Can VaultMe speed up the process?

Not beyond what the providers allow, and there is no setting that changes that. VaultMe has no speed-boost mode and no option that lifts the ceiling, because the ceiling is set by the source and destination providers, not by VaultMe. A migration that is running slowly is generally already running as fast as the providers involved will currently permit, and those limits apply to VaultMe exactly as they apply to any other application using the same APIs. They cannot be bypassed or negotiated away from VaultMe's side.

Pausing and unpausing a migration by hand is not an optimization either. It does not recover capacity, it does not reset a provider's limit window, and it can make the total run longer than simply leaving the migration alone would have.

When a long quota window has been exhausted, time is the only remedy. Waiting for the provider's window to reset restores throughput faster than anything that can be done to the migration in the meantime.

What genuinely does make a difference sits on the customer's side rather than in the app: reducing what competes with the migration for provider capacity, clearing blockers on the user accounts themselves, and shaping the project so it does not ask the providers for everything at once. Those levers are covered in "How do I reduce the possibility of delays?".

How do I plan the timeline?

Start from the estimate the scan produces, add headroom, and schedule against the padded figure rather than the raw one. How much of an exercise this becomes depends almost entirely on the size of the project.

A small migration barely has a timeline to plan. Get the user accounts ready, create the migration project, read the estimate, reserve a little more time than it states, run, and cut over. The run is the only moving part, and nothing else in the schedule depends on precisely when it lands.

On a larger project the run is one component among several, and frequently not the longest. Provisioning and licensing destination accounts, getting every account connected, and preparing the people involved all take lead time that has nothing to do with how fast content copies. On very large projects that planning and provisioning work needs substantial time of its own, and the schedule is built around it rather than around the run.

A few points shape the schedule wherever the project is large enough to need one:

• Validate the estimate before betting dates on it. A representative test batch that mixes typical accounts with the heaviest ones converts a projection into a measurement you can extrapolate from.
• Reserve time rather than predict it. Buffer is what absorbs the things nobody can schedule: provider incidents, corrupted items, throttling heavier than anyone assumed.
• Prefer smaller consecutive batches on a large project. Asking the providers for everything at once raises the chance of environment-level limiting; see "Choosing a migration strategy".
• Plan around the largest accounts. They decide when the batch ends, so they belong early in the sequence where they carry the most headroom.
• Do not aim to land the run exactly on the cutover. Finishing early costs nothing, because the sync-up migration (delta migration) that follows carries source-side changes made in the gap; finishing late costs the cutover date.

The full exercise — reserving time, working backward from the cutover date, and budgeting the period after it — belongs to "Planning the migration timeline". The batch structure the schedule is built from is decided in "Choosing a migration strategy", and the mechanics of the follow-up pass are in "How sync-up migration works".

How do I reduce the possibility of delays?

Most of what helps is done before the run starts, and nearly all of it comes down to not asking the providers for more than they will comfortably give:

• Do not run anything else in bulk over the user accounts first. An earlier migration attempt, or another bulk-processing tool over the same accounts, is the strongest single trigger for immediate provider-side limiting. Where a previous attempt exists, expect the new run to be slower than a first run would have been, and expect to remove what that attempt left in the destination by hand: VaultMe writes a fresh copy rather than resuming or merging with an earlier one, as explained in "How sync-up migration works".
• Let heavily used accounts settle before the run. Intensive activity in the days immediately before a migration can leave an account already near its provider limits when it starts.
• Stagger a large project instead of launching everything at once. Many accounts starting simultaneously can trigger environment-level limits that none of them would reach alone, and smaller consecutive batches often finish sooner overall than one oversized launch.
• Quiet down automation for the migration window. Backup tools, synchronization clients, archiving jobs, and integrations pointed at the same accounts compete for exactly the capacity the migration needs.
• Ask end users to stay out of the destination until their account is complete. Modifying content that has already been migrated — above all its structure — can make VaultMe re-synchronize that content or rebuild the structure it expected to find, which costs throughput, extends completion, and raises the chance of an inconsistent result. What to ask of people, and when, is covered in "Preparing stakeholders and end users".
• Freeze credentials and identity settings once the project is under way. Password resets, key rotation, token revocation, and MFA policy changes affecting a connected identity can break a connection, and a migration with a broken connection on either side pauses until it is restored. See "How VaultMe authentication works".
• Give an exhausted quota window time to reset. Throughput will not return before the provider's window does, and nothing done to the migration in the meantime brings it back sooner.
• Keep buffer for what cannot be prevented. Provider-side incidents and corrupted items are not avoidable through good preparation; either the schedule absorbs them or the schedule slips.

Can users continue working in the accounts during the migration?

Yes. Migrations are designed to run without downtime: source and destination user accounts stay usable while a migration is in progress, and normal activity does not by itself cause a migration to fail. Nobody has to be locked out for the duration of the run.

The cost of that activity is measured in time rather than in risk. Every operation an end user or a tool performs draws on the same provider capacity the migration needs, so a busy account migrates more slowly than a quiet one. Changes made while the run is in progress are also not part of the initial pass; they are picked up afterward by the sync-up migration (delta migration), so heavy live activity extends the total time to completion even when the migration itself stays perfectly healthy.

On the source, ordinary use is genuinely fine. VaultMe copies rather than moves, so it does not modify, delete, or reorganize source content: account holders can keep working as they normally would, and the source stays intact and accessible throughout. The copy-not-move model is described in "How the VaultMe platform works".

The destination deserves more care. End users should limit their use of a destination account until its migration completes and, at a minimum, avoid changing content that has already arrived — especially its structure, such as renaming or relocating the folders VaultMe created. If unexpected destination changes do appear, VaultMe may re-synchronize content it had already migrated or rebuild the structure it expects to find, and that reconciliation work reduces throughput, extends completion, and increases the risk of an incomplete or partially inconsistent result.

There is one consequence worth passing on to end users directly. When a later sync-up pass applies a source-side change to an item that was already migrated, any edits made in the meantime to the destination copy of that item are overwritten. Where the destination keeps revision history, those edits can sometimes be recovered from it; otherwise they are lost. The rules that govern that pass are in "How sync-up migration works". The practical instruction is a simple one: keep working in the source, and treat the destination as somewhere to look rather than somewhere to work until the account is confirmed complete.

What should I do if my migration is stalled?

Begin from the assumption that it is waiting rather than broken. A migration showing no visible progress for a stretch of time is in a normal state, not an error state, and most of the causes clear without anyone doing anything:

• A long provider limit window is exhausted. The migration pauses until the window resets and then continues on its own. A wait of several hours is unremarkable here.
• A connection has dropped. A migration whose source or destination connection has broken pauses until it is restored, and this is the one cause that genuinely needs action from you: reconnect the user account and the migration resumes. Credential and MFA changes are the usual culprits, as covered in "How VaultMe authentication works".
• Items are waiting on review. When problem items have been set aside for VaultMe staff to look at and nothing else is left to process, the migration waits until that review is finished, usually within a day.
• The provider is having trouble. A provider-side slowdown or API incident can flatten progress until it passes.

Two things are worth not doing. Do not pause and unpause the migration to shake it loose, since that recovers no capacity and can lengthen the run. And do not start a second migration of the same accounts to catch up: VaultMe does not inspect the destination for content an earlier run already placed there, so a second migration writes a fresh, independent copy of everything and leaves duplicates to be cleaned up by hand.

What is worth doing is checking the explanations above in order. Confirm that the source and destination connections are both still live. Check whether anything else is drawing on the user accounts — end users doing bulk work, an automation tool, or another migration sharing the same destination account. If a long quota window is the likely explanation, give it time to reset. And bear in mind that an estimate which has moved is not a stall signal in itself.

If none of that accounts for what you are seeing and the migration is genuinely not progressing, write to VaultMe support at support@vaultme.com with the details of the project.