What a migration involves, and what sets its speed

Not a file copy

A migration moves files between two systems that each have their own rules, limits and load. The speed of a copy on a local disk says little about it.

What happens to every file

Each job works through its source one file at a time, and every file takes the same steps, whatever its size:

Prepare the job
SMART Migration connects to the source and the destination, reads the source's folders and lists the files that the job's filters let through. No file moves before this is done.
Look at the destination
For each file it looks up what the destination already holds, and compares it — by its rule for adding and overwriting files — to decide whether to add it, replace it or leave it.
Read the file and its versions
The file is read from the source, and with version history, each version too: every version is a file of its own to move.
Write it to Nextcloud
The file is written to its folder in Nextcloud, with its dates and, with MetaVox, its metadata.
Log the result
The step is logged, the run's figures are reported to the app, and any problem is recorded as a file issue.

The bytes travel in the third and fourth step only. Everything around them is calls to the source or the destination, each answered over the network — and for many small files, those calls take far longer than the bytes.

What sets the speed

The same volume can take an hour or a day, depending on what it is made of and where it goes:

Factor	What it does to the speed
Number of files	Each file costs the same steps, so 100,000 small files take far longer than a hundred large files of the same volume
Version history	Every version is moved as a file of its own; a library with long version histories holds many times its current files
Preparing	Reading the source's folders and the destination's contents before the first file moves; on a job with few files it is a large share of its time
What the destination holds	A repeat run compares every file with the destination, and only then knows that most of them need nothing — unless it is an incremental run, which reads and compares only the files changed since the last successful run
Microsoft 365 throttling	SharePoint Online and OneDrive limit how many requests they accept, and SMART Migration waits when they say slow down — shown as `SPO Rate Limit Delay` in the run details
The destination	A busy Nextcloud server, slow storage or a full disk slows every job writing to it
The network	Between the SMART Migration server, the source and Nextcloud — latency matters more than bandwidth when there are many files
Jobs at once	The SMART Migration server runs at most four jobs at a time; more jobs wait their turn
The edition	Enterprise+ migrates at up to three times the Enterprise speed

Why it can be slower than you expect

A throughput of a few gigabytes per hour can look low next to the network's speed. It is not the transfer speed: it is the volume moved per hour of a job's whole time, every step above included. A first run of a large library, many small files or a throttled tenant all bring it down — and none of them means something is wrong.

The real world: interruptions are normal

The figures above describe a migration that runs without a break. No migration does. Over weeks of work across a tenant, a file server and a Nextcloud server, things go wrong as a matter of course — not because something is broken, but because real systems are shared, maintained and used by people while the migration runs:

What happens	What it does to the migration	What to do
Network dropouts	A connection between the SMART Migration server, the source and Nextcloud breaks off: a file fails, or a whole run stops	Check the run's result and File Issues, and run the job again
Throttling	Microsoft 365 slows down or refuses requests when the tenant is busy — hardest in business hours — and a job waits, sometimes minutes at a time for hours	Run the largest jobs in the evening and at the weekend; see `SPO Rate Limit Delay` in the run details
Server reboots	Windows updates on the SMART Migration server, Nextcloud updates and maintenance, a restarted virtual machine — the running jobs stop, and the app shows Offline	Agree maintenance windows with IT, and check the running jobs once the server is back
Missing permissions	A site, library, OneDrive or folder the App Registration or the service account cannot read; files with permissions of their own	The run ends with an error, or the files are listed on File Issues; grant the access and run the job again
Files in use	Files locked, checked out or open in an application cannot always be read	They are listed on File Issues; run the job again later
Expired credentials	A certificate or a password that expires, an app password revoked: every job stops until it is renewed	Note the expiry dates before the project starts
Nextcloud refuses requests	Failed sign-ins from the SMART Migration server's address make Nextcloud slow down every request from it, then refuse them with `429 Too Many Requests`: every job stops	Fix the password, and put the server's address on Nextcloud's brute-force allow list; see "Size the servers" below
The destination fills up	A full disk or a quota reached stops the writes; antivirus scanning and backup windows slow them	Check free space and quotas before each wave
People keep working	Files change in the source while it is migrated	Plan a final catch-up run before the cutover
Decisions and fixes	Permission requests, answers from owners and sign-offs take people's time — often days	Plan them into the waves, not around them

Most interruptions cost little on their own, and the default rule for existing files makes them safe: run the job again and Add New Overwrite Existing By Newer leaves the files already moved alone and copies the rest. What they cost is calendar time — the hours between the moment a job stopped and the moment someone noticed, fixed the cause and started it again.

Plan for the real world, not the ideal one

The forecast measures the time jobs were running. The interruptions met inside those runs — throttling waits, files that failed — are already in it; the time lost while nothing ran is not. Treat it as the best case for uninterrupted work, and plan the calendar with a margin on top. A pilot wave run through ordinary working days, with its interruptions, shows how large that margin is in your environment.

How the Dashboard forecasts the time left

Under the bars of Migration progress, the Dashboard shows three lines worked out from the jobs' own figures. Rest the pointer on them for a card that explains each, with the figures behind it.

Time left

The files left, times the average time per file, shared between the jobs running at once.

Finished about

When the files left are moved at the rate the running jobs reach now.

Throughput

The volume moved per hour of a job's time, on average and now.

The time per file comes from the session log. For each migration, the time from the job's start in the log to its latest log row is divided by the files it has moved. The time spent preparing, before the first file moves, is inside that span, so it is shared out over the files. Finished migrations count with their start and finish; running ones with what they have logged so far. All of them together give one average.
The time left is the files still to move, times that average, divided by the number of migrations running now — at least one. While nothing runs, it is the time one job at a time would take, and the line says so: at the past pace. It is working time: hours when no job runs come on top of it.
Finished about is a guess from now: each running job's files per hour since it started, added up, and the files left at that rate. It reacts at once to a slow source, a busy destination or throttling, so it moves more than the time left. With nothing running, there is no guess.
Throughput is the volume moved per hour of a job's time, in MB per hour: on average over the finished and running migrations, and now, every running job together. It includes every step, not only the bytes. While nothing runs, only the average is shown, marked past migrations.

The forecast learns. With only a few finished migrations it is rough; it settles as more jobs finish, and the choice under Measure from decides which finished runs it learns from.

Jobs without a Discovery run

The bars measure each job against what its last Discovery run counted. A job without one cannot be measured precisely: the Dashboard counts it with what its last finished Migration moved, or else as the average job, so the time left covers it too — but only as well as that estimate fits the job. Run the jobs as Discovery first for exact figures. Progress for jobs without a Discovery run explains how the estimate is made and how far it can be off.

Make it go faster

Leave out what nobody uses with From Date and Source File Type, and limit the versions with Version History Scope.
Keep four jobs running around the clock: schedule the largest jobs for the evening and the weekend, and give them a high Priority.
Spread the largest libraries over the waves, rather than four of them side by side against one throttled tenant.
Split a library of hundreds of thousands or millions of files into jobs of a subset of its folders each: one job for all of it is slow, and may not finish at all. See Sources
Run recurring jobs before the cutover, so the final run only compares and copies what changed.
Make repeat runs incremental: with Incremental (only files changed since the last successful run), a run reads only the files changed since the last successful one and checks only those against Nextcloud — a few changed files instead of the whole library. See Incremental runs: only the files changed since the last run
Check the destination: free space, and a Nextcloud server sized for the load, with enough PHP workers for four jobs writing at once. See Size the servers for a large migration
Keep the interruptions short: watch the Dashboard and the notifications, so a stopped job is noticed in minutes rather than the next morning, and agree maintenance windows with the people who run the servers. See Notifications when a job runs

See also