Estimate volume and duration

Measure, then plan

Volume from Discovery, speed from the pilot, four jobs at a time — and the plan for every wave follows from those three.

What the duration depends on

No two migrations run at the same speed, because the things that decide it differ from one organisation to the next:

Factor	Why it matters	Where you see it
Volume including versions	The migration speed is measured against it, and version history can be many times the size of the current files	Discovery, in Run History and the Power BI report
Number of files	Each file is handled on its own, so many small files take longer than the same volume in a few large ones	`File Count` of a run
Version History Scope	Fewer versions per file means less volume to move	The job's version settings
The file filters	Content left out by date, size or type is not moved at all	The job's advanced settings
Microsoft 365 throttling	Microsoft 365 slows down heavy or frequent reads	`SPO Rate Limit Delay` in the run details
Four jobs at a time	The SMART Migration server runs at most four jobs at once	The Dashboard's running jobs
The edition	Enterprise+ migrates at up to three times the Enterprise speed	Your licence

Step 1: measure the volume with Discovery

Run Discovery on everything in scope — an Import job creates the jobs for a whole tenant, a site or every OneDrive. Then read the volume:

Per run, in Run History: Files, Volume, Versions and Version volume. These count the new and the modified files; rest the pointer on a Discovery run's title for its card, whose Total adds the unchanged files — the whole source as the run found it.
Per library, site and wave, in the Power BI report, with the volume including version history and the age of the content.

Decide what stays behind before you estimate: content nobody has opened or changed in years, archives, and versions you do not need. Every gigabyte left out is time saved in every wave.

Step 2: measure the speed with a pilot wave

Run a pilot wave of libraries that are typical of the rest as Migration jobs. For each run, open its details:

Duration and Volume give the speed of one job: the volume divided by the duration, for example in gigabytes per hour.
SPO Rate Limit Delay shows how much of the duration Microsoft 365's throttling took.

Use the speed of the pilot's larger runs: small runs spend a larger share of their time starting and finishing.

Step 3: work out the waves

For each wave, divide its volume by the speed of one job, and that by four for the jobs running at once:

The estimate for one wave

Hours ≈ volume of the wave including versions ÷ speed of one job ÷ 4

For example, a pilot whose runs moved 40 GB in 8 hours migrates 5 GB per hour per job. A wave of 600 GB then takes about 600 ÷ 5 ÷ 4 = 30 hours. The figures are an illustration only — use your own pilot's.

Then add what is not migration time:

Checking and sign-off. The owners check each wave before the next, usually a few days.
A margin for throttling. Four large libraries at once read harder than one, and Microsoft 365 may slow all four down.
The final synchronisation before the cutover, which only copies what changed and is short.
A margin for interruptions. Network dropouts, server reboots and updates, missing permissions, files in use and expired credentials happen in every real migration, and each costs the time until someone notices and runs the job again. Size the margin from your pilot, run through ordinary working days.

Scans take time too

A tenant scan that creates the jobs reads 30 to 50 sites a minute — about 30 to 40 minutes per 1,000 sites. Plan it before Discovery, which then takes its own time per library.

Shorten the migration

Leave out what nobody uses with From Date, and the file types you do not need with Source File Type.
Limit the versions with Version History Scope.
Run around the clock: set Scheduled Date to the evening or the weekend, and give the largest jobs a high Priority so they start first.
Spread the largest libraries over the waves rather than running them side by side.
Keep the destination current with recurring jobs, so the final run before the cutover is small.
Enterprise+ migrates at up to three times the Enterprise speed.

Let your partner estimate it

Your SMART Migration partner can make the estimate with you from the Discovery report and the pilot, and turn it into a timeline and an offer.

Once the migration runs, the Dashboard's Migration progress keeps the estimate current: it works out the time left and the throughput from the runs themselves, as working time without the hours nothing ran — see What a migration involves, and what sets its speed

See also