SharePoint migrations are where Microsoft 365 projects go to die. Lift-and-shift migrations produce SharePoint that nobody uses. Over-engineered ones never finish. This playbook is the middle path — the one we use on every engagement, tuned for Australian organisations between 50 and 2,000 seats.
Phase 1 — Discovery
Before any architecture work, you need to know exactly what you have. Run a data discovery tool (we use ShareGate, Quest or SPMT pre-scan) against every source — file server, NAS, network drives, OneDrive, existing SharePoint. Capture total volume, file age distribution, top folders by size, NTFS permissions, last-accessed dates, file types.
Three things always fall out of this. First, 20–40% of the data hasn't been touched in three years and can be archived. Second, you find at least one folder shared with 'Everyone' that shouldn't be. Third, you find duplicate data — the same files synced to multiple locations — which is going to cause Copilot problems later.
Phase 2 — Information architecture
Don't lift and shift. SharePoint rewards structure. Model an IA that maps to how the business runs — not how the file server organically evolved.
Hub sites for business units
One Hub site per major business unit (Finance, HR, Operations, Sales, Delivery). Hubs give you shared navigation, shared branding and rolled-up search.
Sites for functions
Under each Hub, create a site per major function or team. Each site is a security boundary. Within a site, libraries group content by type.
Permissions to Entra groups, never individuals
The single biggest maintenance nightmare in SharePoint is per-user permissioning. Everything flows through Entra security groups. When someone joins or leaves a team, you change one group membership — permissions update everywhere.
Phase 3 — Governance baseline
Before migrating a single file, configure: site creation policies (only admins or approved creators), external sharing defaults, retention policies, sensitivity labels, default permission levels. This prevents the 'SharePoint sprawl' that kills tenants six months after migration.
Phase 4 — Migration in waves
Never migrate everything at once. Wave structure looks like this.
- 1Pilot wave (1 business unit, 1–2 weeks): prove the process, tune the runbook.
- 2Parallel waves (3–6 business units at a time, 2-week cycles): migrate source-by-source, not site-by-site.
- 3Final sweep (1 wave): miscellaneous content, orphaned data, long-tail file shares.
Each wave has: a pre-wave briefing 7 days out, a cutover weekend, a post-wave hypercare period of 5 business days, and a retrospective before the next wave starts.
Phase 5 — User adoption
The technology part is the easy half. The hard half is changing how people save, find and share files.
Every wave includes: 30-minute training for every user (recorded, not just live), one-page 'how to find your files' cheat sheet, named site champions in each business unit, and a feedback channel directly to the project team. Measure adoption weekly — users opening SharePoint, files edited, search queries.
Phase 6 — Sunsetting the file server
Too many projects skip this and end up running a file server indefinitely because nobody trusts the migration. The sequence: mapped drives go read-only one week after cutover, the server stays available for 60 days, then it's archived for six months, then deleted. Communicate each step a week in advance.
The Copilot unlock
The real prize of a well-run SharePoint migration isn't the file move. It's that Copilot can now reason over your business data. Copilot cannot see file servers. It can see SharePoint — and when your SharePoint is properly structured, permissions are clean and labels are applied, Copilot becomes genuinely useful.
Try it
Check your AI readiness post-migration
Run the assessment to see whether your tenant is actually ready to extract Copilot value — data, governance, workflow, adoption and capacity.
Score each dimension, 1 – 5
How ready is your organisation for AI — really?
Five dimensions. Pick the statement closest to the truth for your business today. No wrong answers.
Data readiness
Is your data in a shape AI can actually reason over?
Governance & security
Identity, permissions, DLP, audit — the safety rails for AI.
Workflow integration
Where will AI actually get used in the business?
Adoption capability
Will your team actually use it when it arrives?
Capacity to invest
Can you actually fund and run an AI program right now?
Common failure modes
- Lift-and-shift: users don't adopt because the new structure feels identical to the old one, with extra clicks.
- Per-user permissions: admin team drowns in tickets within 90 days.
- No sunset plan: file server runs forever, defeating the business case.
- No training: users hate the change and escalate.
- No labelling: Copilot deployment later becomes a remediation project.
A good SharePoint migration is boring, structured and measurable. If yours is heroic, something's wrong.