Plan and run a migration, wave by wave

Discover, decide, configure, migrate, validate, document

Understand the data. Control the migration. Prove the result.

The migration, step by step

Set up
A partner, the SMART Migration server, the app password and a trial or production licence. See the topic on setting up SMART Migration below.
Discover everything in scope
Import Discovery jobs for the tenant, the sites or the OneDrives in question, or list the file shares in a CSV file. Set them to Ready and let them run.
Decide on facts
Refresh the Power BI report: what to migrate, what to clean up first, what to archive or leave behind, where each library goes, and how the waves are cut.
Organise the waves
Merge the imported groups into one group per wave — Pilot, Wave 1, Wave 2 — and tag what cuts across them. Delete the jobs for what stays behind.
Configure the destinations
Switch each wave's jobs to Test Migration, and set their Team Folders or users, folders, filters, version scope and metadata. Set up the Team Folders' members in Nextcloud.
Test
Run the Test Migrations: they show which files each job would add as new and which it would overwrite, without writing anything. Correct what they report, until the wave runs clean. In the Power BI report their files show as Test Migration, with the destination each would go to.
Migrate
Tick the group's box, pick Change selected jobs … in the Actions menu, and set Mode to Migration and Status to Ready in one go — every job is validated again first, and one still missing a destination stays on Hold. The server works through it, four jobs at a time.
Check and repeat
Read Run History and File Issues, fix the causes, and run the jobs again: each run adds what is missing and updates what changed.
Cut over
Run a final synchronisation, then move the users — or replace the SharePoint files with .url links to Nextcloud, which frees the SharePoint storage they took and leads users to Nextcloud from the places they know.
Document
Refresh the Power BI report and keep a copy as the wave's record, with its Run History and reports in Nextcloud Files.

The topics for each step:

Start with a pilot wave

Pick a few libraries that are typical of the rest and belong to people who will tell you what they find. A pilot shows how the naming, the Team Folder layout, the metadata and the permissions work out before they are repeated a hundred times, and it gives a measured speed to plan the remaining waves with.

How big should a wave be?

Small enough to check. A wave is signed off as a whole, so it should be a set the owners can check in a few days.
Shaped by the owners, not by the alphabet. A department, a site or a team moves together, so the people who work together switch together.
Measured by volume, versions included. Discovery's volume including version history is what the migration speed is measured against.
Very large libraries split by folder. A library of hundreds of thousands or millions of files is several jobs, each a subset of its folders, never one: see Sources
Spread over time where Microsoft 365 throttles. Many large libraries at once slow each other down; the run details show the delay Microsoft 365's rate limits imposed.

How long each wave takes, from the Discovery volume and the pilot's speed: Estimate volume and duration

What the reporting database and the Power BI computer need for the whole migration, measured on the pilot: Size the servers for a large migration

Recurring jobs for a long transition

When a department cannot switch on one day, give its jobs a recurrence. Each run copies what is new or changed since the last one, so Nextcloud stays current until the day of the switch, and the final run is only a small one.

Keep the record

Every wave leaves its own record without extra work: a Run History row for every run with its configuration, counts and result, the reports and logs in Nextcloud Files, and the Power BI report as a file. Save a refreshed copy of SMART BI.pbix when a wave is signed off.

See also