SharePoint Migration Checklist
A practical SharePoint migration checklist covering scope, inventory, cleanup, architecture, permissions, metadata, workflows, pilot waves, cutover, validation, and go-live.
- Published
- Reading time
- 12 min read
What you’ll learn
- Quick checklist
- Phase 1 — Define migration scope
- Phase 2 — Inventory the source
- Phase 3 — Clean up content
- Phase 4 — Target information architecture
On this page (25 sections)
Direct answer: A SharePoint migration checklist tracks what must be completed before, during, and after migration — scope, inventory, cleanup, architecture, permissions, metadata, automation, customizations, pilot, waves, cutover, validation, go-live, and post-migration review. Work it phase by phase; each phase's checks are the entry ticket to the next.
Need to assess the environment first? Start with SharePoint Migration Assessment & Readiness, which answers what exists, what the risks are, and whether you are ready. This checklist answers what needs completing, in what phase, and who verifies it. Use both with the migration hub.
- Assess — inventory the source and judge readiness.
- Prepare — clean content, design the target, map permissions and metadata.
- Pilot — prove tooling and mappings with representative content.
- Migrate — move in controlled waves with owners notified.
- Validate — compare evidence and collect sign-off per wave.
- Go Live — cut over users with support ready.
- Optimize — stabilize, modernize, and capture lessons.
Use this checklist as a project framework — not as a substitute for environment-specific migration planning. Tick boxes directly on this page as you work.
Quick checklist
The executive view. If any box here is unchecked, the detailed phase below it is not done.
Phase 1 — Define migration scope
Scope control is what keeps a migration a project instead of an open-ended expedition. Unscoped migrations absorb every forgotten file share and stall on ownership disputes. Verified by business and technical owners together.
Do not start migration tooling before scope and ownership are understood. Tooling configured against an undefined scope migrates the wrong content to the wrong places.
Phase 2 — Inventory the source
Record everything the migration could touch. This phase feeds every later decision; gaps here reappear as cutover surprises.
For the why behind each item, work through SharePoint Migration Assessment & Readiness — this checklist tracks completion, the assessment guide explains the risks.
Phase 3 — Clean up content
Migration is an opportunity to reduce unnecessary content rather than blindly moving everything. Classify each area as migrate, archive, delete, remediate, or review — and never delete content without appropriate owner and governance approval.
Phase 4 — Target information architecture
Do not automatically reproduce legacy architecture simply because it already exists. Decide per area whether to map or redesign into modern SharePoint.
- Legacy architecture — as found.
- Still appropriate? — defend "yes" with ownership and usage evidence.
- Yes → Map boundaries into the target.
- No → Redesign into modern SharePoint: flat sites, hubs, metadata-driven libraries.
Design with the information architecture blueprint and the document-dump blueprint.
Phase 5 — Permissions
Permissions fail migrations because broken inheritance, unmapped identities, and forgotten access combine silently — a perfectly copied file nobody can open is still a failure. Verified by the migration lead with site owners.
- Source permissions — captured, including every unique break.
- Review — intentional access separated from sprawl.
- Clean up — obsolete access removed before it can travel.
- Identity mapping — every principal resolved to a target identity.
- Target permissions — a model owners can explain.
- Validation — sampled side by side after the pilot.
Phase 6 — Metadata
File migration success does not mean metadata migration success. Required columns, defaults, lookups, and term mappings fail quietly — then views return nothing and edits get blocked after go-live.
Background: the metadata guide and permissions guide.
Phase 7 — Lists and libraries
Assess significant lists individually — size, views, versioning, approvals, formatting, and dependencies all change the approach. No platform limits are hard-coded here; confirm current values against Microsoft documentation when sizing large lists.
Phase 8 — Workflows and automation
Every workflow needs an owner and a disposition before migration — ownerless automation cannot be tested, and untested automation breaks at cutover. Power Automate may be appropriate for modernization but is not automatically a one-to-one replacement for every legacy workflow.
- Workflow — as found, with its owner.
- Required? — undefended workflows retire here.
- Supported? — check the target, not assumptions.
- Retain, replace, rebuild, or retire — rebuilds tested in parallel before cutover.
Rebuild patterns: approval workflows and SharePoint trigger patterns.
Phase 9 — Forms
Trace each form to its business requirement first, technology second. Modern SharePoint forms, Power Apps, or SPFx each fit different requirements — none is the default.
Phase 10 — Customizations
Customizations discovered late derail cutovers. Inventory everything that executes or renders custom behavior, then classify each item — retire, replace, modernize, rebuild, or retain — before waves are scheduled.
- Legacy customization — as found.
- Still required? — no defended requirement, no migration.
- Supported in target? — verify, never assume.
- Retire, replace, modernize, or rebuild — recorded per item.
Phase 11 — SPFx modernization
Do not rebuild legacy functionality in SPFx automatically. First determine whether each requirement can be retired or satisfied with a supported native Microsoft 365 capability — SPFx is for what remains justifiably custom.
- Classic SharePoint — legacy customization as found.
- Assessment — requirement confirmed and classified.
- Native modern feature, Power Platform, or SPFx — chosen per requirement, not by habit.
Explore SharePoint Framework (SPFx) for the development hub.
Phase 12 — Integrations
Untested integrations fail silently after content moves. Document every dependency and never expose credentials or client secrets in browser-side code — secrets belong in secured backends.
Phase 13 — Identity
Identity mapping quietly governs everything: sign-in, permissions, and ownership all resolve through it. Do not oversimplify — guests, service accounts, and app identities each need explicit handling, especially in tenant-to-tenant moves.
- Source identity — users, guests, groups, apps.
- Mapping — every principal resolved, orphans reassigned.
- Target identity — provisioned and licensed.
- Permissions — re-applied through the target model.
- Validation — sign-in and access sampled before cutover.
Sequencing detail: the tenant-to-tenant guide.
Phase 14 — Governance and compliance
Identify governance requirements before designing the target — retrofitted governance is rarely adopted. This checklist does not provide legal advice; confirm obligations with accountable owners.
Phase 15 — Select migration approach
Tool selection follows requirements — not the other way around. Verify capabilities against your source, volume, and fidelity needs; this is an evaluation, not a product ranking.
Phase 16 — Pilot migration
The pilot is where assumptions meet reality — give it production-shaped risk, not a demo folder. Owners validate representative scenarios before any bulk wave is approved.
- Pilot — run against representative content.
- Measure — errors, throughput observations, exceptions.
- Validate — content, permissions, metadata with owners.
- Fix — remediate findings in mappings and plan.
- Repeat if needed — re-pilot what changed.
- Approve migration waves — only on evidence.
Phase 17 — Migration waves
Moving everything simultaneously concentrates risk: one failure mode affects everyone, support drowns, and rollback becomes theoretical. Waves isolate blast radius by owner, dependency, and criticality.
Phase 18 — Pre-cutover
The final gate before users move. Every item here is cheaper to fix now than after cutover.
Phase 19 — Migration execution
Run the approved plan and watch it — unattended migrations produce unattended failures. No speed expectations are stated here; measure throughput in your pilot and plan buffers from evidence.
Phase 20 — Validation
Validation proves completeness and correctness with evidence and owner acceptance — per wave, before users depend on the target. For the full method, use migration validation with Python.
Content
Metadata
Security
Functional
Business
Phase 21 — Go-live
Go-live is a coordinated switch with support standing by — verified by business owners and the migration lead.
Phase 22 — Post-migration
Migration complete is not project complete. Stabilize before optimizing, and optimize before declaring victory.
- Validate — evidence and owner sign-off per wave.
- Stabilize — issues, links, access, and automation settled.
- Optimize — search, structure, and governance tuned.
- Modernize — retired and rebuilt capabilities land properly.
Classic to modern modernization checklist
Legacy SharePoint travels with content unless assessed. Identify each classic dependency and record its modern path — none of these mappings are automatic one-to-one replacements.
| Classic | Modern direction |
|---|---|
| Classic pages | Modern pages |
| Custom JavaScript | Native capability, or SPFx where custom code is justified |
| JSLink | JSON formatting, or SPFx depending on requirements |
| SharePoint Designer | Power Automate where appropriate |
| InfoPath | Modern forms, Power Apps, or SPFx where appropriate |
| Legacy web parts | Native modern web parts, SPFx, or retire |
Development detail: Explore SharePoint Framework (SPFx) and the modernization roadmap.
Planning a SharePoint migration?
If you are working through migration scope, permissions, legacy customizations, migration waves, or validation, share the environment and challenge with nextM365: Discuss Your Migration.
Continue with the migration hub, the assessment guide, the step-by-step migration guide, and migration validation.
Related resources
Topics covered
Architecture · Governance · Security
Frequently asked questions
What should be included in a SharePoint migration checklist?
Scope and ownership, source inventory, content cleanup, target architecture, permissions, metadata, lists, workflows, forms, customizations, integrations, identity, governance, tooling, pilot, waves, cutover, validation, go-live, and post-migration review.
What should be done before migrating SharePoint?
Approve scope, inventory the source, classify content into migrate, archive, delete, remediate, or review, design the target architecture, map permissions and metadata, disposition workflows and customizations, select tooling, and prove it all with a pilot.
Should SharePoint permissions be cleaned before migration?
Yes. Review unique permissions, remove obsolete access, map every identity to the target, approve a simpler target model with owners, and plan permission validation per wave before migrating.
Should you run a pilot SharePoint migration?
Always. Pilot with representative simple and complex content, permissions, metadata, and — where relevant — workflows and customizations. Measure, validate with business users, fix findings, and only then approve bulk waves.
How should SharePoint migration be validated?
Validate content counts and samples, metadata and content types, permissions and groups, navigation, search, views, forms, workflows, Power Automate, Power Apps, SPFx, integrations, and business processes — with owner acceptance recorded per wave.
What happens to workflows during SharePoint migration?
Each workflow is inventoried and given a retain, replace, rebuild, or retire decision. Legacy SharePoint Designer workflows do not carry forward as-is; genuine processes are typically rebuilt in Power Automate against target URLs and tested in parallel.
What happens to custom SharePoint solutions?
Each customization is classified as retire, replace, modernize, rebuild, or retain. Script-based and legacy solutions do not move as-is into modern SharePoint; custom code that remains justified moves to SPFx or supported APIs.
When should SPFx be considered during modernization?
After deciding a requirement cannot be retired or met with native SharePoint or Power Platform capabilities. SPFx is for justified custom web parts, extensions, and integrations — never an automatic rebuild of everything legacy.
What should be checked after SharePoint migration?
User-reported issues, missed content, permissions, search indexing, automation, integrations, SPFx solutions, broken links, external sharing, usability, documentation updates, and lessons learned — migration complete is not project complete.
Sources
Have a Microsoft 365 topic idea?
Share article suggestions, community session ideas, corrections, or real-world scenarios for future nextM365 learning notes.
Keep learning Microsoft 365
Explore more practical tutorials for SharePoint, Power Platform, Copilot Studio, migration, automation, governance, and security.
Continue learning
Related tutorials
Related questions
Related comparisons