Migration
On-premises to SharePoint Online, tenant to tenant, or file shares into Microsoft 365 — planned properly, tested in staging, with a rollback path that exists before cutover starts.
Overview
The risky part is never the file copy
Moving content is largely a tooling problem and tooling has got good. What causes migrations to fail is everything around it: permissions that do not map cleanly, customisations with no modern equivalent, workflows that stop at the tenant boundary, and users who were never told what changes.
- Full inventory before anything movesSite collections, content volume, list sizes, customisations, workflows and permission structures documented and assessed.
- Permissions mapped, not guessedLegacy groups reconciled against Entra ID, broken inheritance identified, and an explicit decision made about each exception.
- Staged cutoverPilot group first, then departmental waves, with validation gates between each. Not a single weekend big bang unless the environment genuinely allows it.
- A rollback plan that existsWritten before migration starts, with defined criteria for when to invoke it.
Architecture
Wave-based cutover
Assessment and remediation happen before anything moves. Each wave has a validation gate, and the rollback path is written before the first user is migrated.
What is included
What a migration engagement includes
Environment assessment
Automated inventory plus manual review, producing a report on content volume, risk items and anything without a modern equivalent.
Migration plan
Wave structure, timeline, downtime windows, communications plan and success criteria, agreed before work begins.
Remediation
Legacy customisations, unsupported workflows and oversized lists addressed before they block the move.
Pilot migration
A representative subset moved to staging and validated with real users before the full run.
Production waves
Executed to plan with validation after each wave and a defined point of no return.
Post-migration support
Hypercare window covering the first weeks, when the questions actually arrive.
In practice
About the things that do not migrate
Every on-premises environment of any age contains things with no clean destination. SharePoint Designer workflows. InfoPath forms. Full-trust solutions. Custom master pages. A list with sixty thousand items that someone built as a database in 2014.
These are not edge cases; they are the normal state of a mature farm. Discovery finds them early so each one gets an explicit decision — rebuild in Power Automate, replace with a Power App, archive, or leave behind — rather than surfacing halfway through a cutover weekend.
We would rather tell you in week one that a piece of your environment needs rebuilding than discover it with users waiting.
Questions
Common questions
How much downtime should we expect?
For most wave-based migrations, none for users outside the wave being moved. The wave itself typically has a read-only window measured in hours rather than days.
Can you migrate from file shares or another platform?
Yes — network file shares, Google Workspace and other document platforms into SharePoint Online or OneDrive, with metadata mapping where the source supports it.
What happens to our old SharePoint Designer workflows?
They are inventoried during discovery and each is assessed individually. Most rebuild cleanly in Power Automate; some are better retired, and we will say which.
Do you use ShareGate, or Microsoft’s own tooling?
Whichever fits the migration. The Microsoft tooling is capable and free for many scenarios; third-party tools earn their cost on complex permission structures and metadata fidelity.