Begin with the source
A cloud migration starts
with your current estate.
Select a starting point to explore the review priorities. The migration approach follows the source, the dependencies and the agreed destination.
Your starting point
Map the legacy estate before choosing a path.
Review classic publishing, forms, workflows, custom solutions and authentication alongside the content inventory.
Microsoft lifecycle reference (opens in a new tab)Discovery focus
- Farm structure and source access
- Business-critical forms and workflows
- Custom branding, master pages and solutions
- Ownership, content scope and remediation priorities
Your starting point
Connect content readiness to business dependencies.
Assess sites, permissions, metadata and integrations before selecting tools, defining target architecture or committing migration waves.
Microsoft lifecycle reference (opens in a new tab)Discovery focus
- Sites, libraries, versions and metadata
- Permissions and identity mappings
- Custom solutions and connected systems
- Pilot candidates and target design
Your starting point
Review the modern and classic mix together.
Identify which experiences, customizations and integration patterns can move with the selected approach and which need a separate decision.
Microsoft lifecycle reference (opens in a new tab)Discovery focus
- Modern and classic site experiences
- Authentication and API dependencies
- Pages, web parts and custom solutions
- Content, access and business acceptance checks
Your starting point
Design one destination from several starting points.
Coordinate source inventories, identity, destination mapping and business ownership across the environments included in the agreed scope.
Discovery focus
- Source boundaries and shared dependencies
- Identity and content ownership
- Target sites, hubs and information architecture
- Cross-source sequencing and validation
Lifecycle is one planning input. The target architecture also needs to fit your business, compliance and operating requirements.
Separate the decisions
Know what can move.
Decide what needs to change.
Content transfer and legacy modernization are related workstreams. Expand each area to review the questions, options and acceptance evidence.
01Content & information architectureSites, libraries, lists, content types, metadata and versions.Migrate with defined mappings
Assessment questions
Review scope, ownership, target structure and mapping requirements.
Possible target approach
Supported content migration with appropriate cleanup and target configuration.
Acceptance evidence
Reconcile content, metadata and versions against the source baseline.
02Pages & classic experiencesClassic sites, publishing, navigation, master pages and web parts.Review the target experience
Assessment questions
Identify business use, custom branding and supported migration behavior.
Possible target approach
Modern pages, supported native features or scoped remediation.
Acceptance evidence
Test page behavior, navigation, links and key user journeys.
03Forms & workflowsInfoPath, Designer workflows, approvals and manual handoffs.Assess the business process
Assessment questions
Document rules, data, identity, integrations and exception handling.
Possible target approach
Supported workflow migration, replacement, redesign or retirement as appropriate.
Acceptance evidence
Validate rules, approvals, access, connections and recovery.
04Custom code & integrationsFarm solutions, legacy JavaScript, SPFx, APIs and external systems.Decide before rebuilding
Assessment questions
Review dependencies, credentials handling, permissions and tenant-specific configuration.
Possible target approach
Native capability, supported SPFx, approved APIs or a separately scoped rebuild.
Acceptance evidence
Test functionality, API access, deployment and business acceptance.
From readiness to transition
Build the plan.
Rehearse it in the pilot.
Agree scope, milestones and acceptance criteria before implementation. Let pilot findings inform tooling, sequencing and cutover expectations.
- 01
Assess
Inventory the estate and agree scope, owners, risks and target requirements.
- 02
Design & prepare
Map destinations, permissions and metadata. Remediate blockers and prepare the target.
- 03
Prove the pilot
Test representative content, mappings, access, throughput and business processes.
- 04
Migrate in waves
Sequence agreed workloads around readiness, dependencies and migration windows.
- 05
Validate & transition
Reconcile results, resolve exceptions, coordinate cutover and hand over operations.
Your migration rehearsal
A representative pilot turns assumptions into evidence.
Test the configuration and the user experience together. Use the findings to resolve blockers and refine the wave plan.
- Source access and tool configuration
- Content, metadata and version behavior
- Identity mappings and effective permissions
- Pages, links and connected processes
- Throughput and migration window assumptions
- Reconciliation, exceptions and owner acceptance
Tooling and current Microsoft guidance
SPMT includes source-site scan and assessment capabilities. Select tools and settings against source version, workload support, reporting, required fidelity and the pilot results; a tool choice alone does not define the migration plan.
Evidence before acceptance
Check the destination
against the source baseline.
Define what a successful wave means before migration starts. Review technical results and business acceptance as distinct gates.
| Review area | Source baseline | Destination evidence |
|---|---|---|
| Content | Agreed sites, libraries and item scope | Reconciled counts, reports and failed/skipped items |
| Metadata & versions | Required fields, content types and version requirements | Mapping checks, populated values and version behavior |
| Access | Users, groups, owners and target access design | Effective permission and sharing checks |
| Experience & processes | Critical pages, links, forms and integrations | Functional tests and business-process acceptance |
| Exceptions & handover | Acceptance criteria and accountable owners | Assigned exceptions, sign-off and support responsibilities |
An appropriate first engagement
Get the readiness picture
before setting the move.
Bring the source and target context, known legacy dependencies and the decisions your team needs to make.
Explore the readiness assessmentThe SharePoint owner, source administrator, Microsoft 365 lead and a business process owner.
Farm version, site and storage scope, access, known customizations, goals and constraints.
Inventory and risk findings, target mappings, remediation priorities and a pilot/validation approach.
Engagement scope and specialist work
Agree source access, tools, responsibilities, acceptance criteria and commercial terms before delivery. Significant custom-app rebuilds, workflow redesign, on-premises upgrades, licensing and ongoing managed support need explicit scope. Initial discussions do not require tenant credentials.
Read the approach
Guidance for your
next migration decision.
Explore the implementation guide, inspect an illustrative deliverable or review the separate modernization workstream.
Server to Online, step by step
Review assessment, preparation, migration and validation considerations.
Explore resource Sample deliverableSee the assessment structure
Inspect fictional inventory, risks, decisions and wave planning.
Explore resource Related serviceModernize the legacy estate
Review supported options for forms, workflows and custom components.
Explore resourceBefore you begin
Questions about
the move to Online?
Clarify source readiness, legacy dependencies and validation before making the migration commitment.
Discuss your migration (opens scheduling in a new tab)Can SharePoint Server 2013, 2016 or 2019 be a migration source?
Microsoft documents these versions as supported sources for the SharePoint Migration Tool. The practical approach still depends on access, source configuration, content, customizations, permissions, tooling settings and the target design.
Will moving content modernize the whole solution?
No. Content migration and modernization are separate decisions. Review classic publishing, forms, workflows, custom master pages, farm solutions and integrations before deciding what to migrate, replace, redesign or retire.
What happens to InfoPath forms and Designer workflows?
Inventory their data, rules, approvals, owners and integrations. Evaluate supported migration or replacement options against the business process, then test the resulting solution. Do not assume that moving a site makes every dependency production-ready.
How do you select migration tools?
Start with the source version, target, workload scope, reporting, required fidelity and validation needs. Options may include SPMT, appropriate third-party tools and scoped inventory or validation scripts. Prove the selected configuration in a representative pilot.
What is checked after a migration wave?
Compare the source baseline and destination evidence for content, metadata, versions, access, pages, links and connected business processes. Record failed or skipped items, assign exceptions and obtain agreed owner acceptance.
How long will migration take?
Duration depends on content volume, source and target readiness, access, dependencies, remediation, throughput, migration windows and validation depth. Pilot evidence helps establish a realistic wave plan and cutover approach.
Is SharePoint Online the only possible target?
No. Select the target architecture against business, compliance, operational and user requirements. Lifecycle planning matters, but a move to SharePoint Online should follow an agreed architecture decision.
Plan the next move
Move forward
with a clearer migration plan.
Discuss the estate, the dependencies and what a useful first engagement should establish.