SharePoint Server to Online Migration: 2013 / 2016 / 2019 Step-by-Step

A SharePoint Server to Online migration moves more than documents. Your farm may depend on custom solutions, Windows authentication, service applications, MySites, Designer workflows, and InfoPath forms. Those dependencies determine what can move, what needs rebuilding, and when users can switch.

This nextM365 guide covers SharePoint Server 2013, 2016, and 2019 through twelve practical steps: scope, inventory, replacements, identity, tooling, cutover, and validation.

Technical baseline: October 2026. Use the inventory and acceptance checks below as a working plan with named owners, evidence, and delivery gates.

Action: Create one migration register containing source URL, owner, destination, disposition, dependencies, wave, and acceptance status.

Is This SharePoint Server to Online Migration Guide for You?

Use this guide when retiring an on-premises farm and moving collaboration to Microsoft 365. Tenant-to-tenant migrations require a different identity and tooling plan.

Area	Server 2013	Server 2016	Server 2019
Support status	Support ended 11 April 2023	Support ended 14 July 2026	Support ended 14 July 2026
Workflow engine	2010 platform; separate engine for 2013 workflows	Same two-platform assessment	Same assessment; newer UI does not remove legacy dependencies
Add-in model	Inventory SharePoint-hosted and provider-hosted add-ins	Inventory add-ins and authentication	Inventory add-ins alongside SPFx
MySites	Personal sites, documents, profiles, social features	Personal content and profile dependencies remain	Personal content still needs explicit OneDrive mapping
Minimum migration path using SPMT	Direct supported content migration to Online	Direct supported content migration to Online	Direct supported content migration to Online

The support dates come from Microsoft's SharePoint lifecycle guidance and 2026 lifecycle list. SPMT lists all three source versions in its supported source overview.

SharePoint 2013 Caveat: Direct Migration Versus Database Attach

SharePoint 2013 does not universally need an intermediate hop to migrate content to SharePoint Online. SPMT supports direct migration from an accessible source farm.

An intermediate farm becomes relevant when restoring or upgrading databases through an on-premises upgrade path. Microsoft documents database attach from 2013 to 2016; a subsequent 2019 upgrade requires the next supported stage. SharePoint Online does not accept attached content databases. See Microsoft's database-attach upgrade guidance.

Check: Record whether you have a working source farm, disconnected databases, or an upgrade requirement before selecting a migration path.

Step 1: Scope Your SharePoint Server to Online Migration

Start with business ownership. Migrating everything preserves abandoned sites, duplicate records, and applications nobody supports.

Source asset	Typical disposition	Required decision
Active documents and lists	Migrate	Destination, owner, versions
Historical records	Migrate or archive	Retention and retrieval requirements
Unused sites	Retire	Owner approval and disposal rules
Farm configuration and SQL databases	Do not transfer as cloud configuration	Recreate required capabilities
Custom applications	Replace or rebuild	Business process and dependencies
MySite documents	Migrate to OneDrive or shared sites	Personal versus business ownership

Record exclusions explicitly. Include attachments, checked-out files, drafts, published pages, document sets, and records requiring special handling. For each exclusion, record who approved it and where any required historical copy will remain accessible.

Use the migration assessment and readiness guide to structure discovery across content, applications, identity, and governance.

Book a SharePoint Migration Assessment

Action: Obtain owner approval for every migrate, archive, rebuild, and retire decision before estimating delivery.

Step 2: Inventory the Farm

Inventory each farm separately. Capture build number, servers, web applications, alternate access mappings, authentication zones, site collections, content databases, and service applications.

Run this read-only starting inventory in the SharePoint Management Shell on a farm server, using an account with appropriate access. It writes local CSV reports; it does not modify SharePoint content.

$outDir = "C:\MigrationInventory"
New-Item -ItemType Directory -Path $outDir -Force | Out-Null

Get-SPWebApplication |
    Select-Object DisplayName, Url |
    Export-Csv "$outDir\WebApplications.csv" -NoTypeInformation

Get-SPContentDatabase |
    Select-Object Name, Server,
        @{N="WebApplication";E={$_.WebApplication.Url}},
        CurrentSiteCount, DiskSizeRequired |
    Export-Csv "$outDir\ContentDatabases.csv" -NoTypeInformation

Get-SPSite -Limit All | ForEach-Object {
    $site = $_
    try {
        Get-SPWeb -Site $site -Limit All | ForEach-Object {
            $web = $_
            try {
                [pscustomobject]@{
                    SiteCollection = $site.Url
                    ContentDatabase = $site.ContentDatabase.Name
                    SiteStorageBytes = $site.Usage.Storage
                    WebUrl = $web.Url
                    Template = "$($web.WebTemplate)#$($web.Configuration)"
                    Language = $web.Language
                    MasterUrl = $web.MasterUrl
                    CustomMasterUrl = $web.CustomMasterUrl
                }
            }
            finally { $web.Dispose() }
        }
    }
    finally { $site.Dispose() }
} | Export-Csv "$outDir\Webs.csv" -NoTypeInformation

Get-SPSolution |
    Select-Object Name, Deployed, ContainsGlobalAssembly |
    Export-Csv "$outDir\FarmSolutions.csv" -NoTypeInformation

DiskSizeRequired provides a SharePoint-reported database measure; reconcile actual SQL data/log allocation with the DBA. Site storage repeats for each web and must not be summed across those rows.

Inventory finding	Why it matters
STS#0	Classic team-site structure
STS#1	Blank-site pattern; inspect actual contents
BLOG family	Posts, comments, categories, and presentation need decisions
WIKI family	Distinguish enterprise wiki from wiki libraries
Publishing templates/features	Master pages, layouts, approval, navigation
Custom WSPs and farm solutions	Server code cannot simply deploy to Online
Language packs and web languages	Target locale and multilingual experience need planning

Collect installed language packs separately from server installation records; web language alone is insufficient. Record scan errors as findings, rather than treating inaccessible sites as empty sites.

Check: Reconcile the inventory with Central Administration and owner lists, including inaccessible sites and failed scans.

Step 3: Map Service Applications

Service application databases are not portable cloud services. Map the business capability and its consumers.

Farm capability	Microsoft 365 replacement direction	What does not transfer directly
Search	Microsoft Search and SharePoint search	Crawl topology, index, custom search components
User Profile Service	Entra ID-backed identity and supported SharePoint profile properties	UPS database, synchronization configuration, arbitrary property mappings
Managed Metadata Service	SharePoint Online term store and content types	Complete service application configuration
BCS and external lists	Power Apps, connectors, APIs, Dataverse where appropriate	Existing BCS runtime
Secure Store	Supported connection identities, gateway configuration, or application secrets management	Credential database and target applications
Excel Services	Excel for the web or Power BI, depending on behavior	Complete server-side calculation and integration behavior
Visio Services	Visio for the web and redesigned embeds	Legacy Visio Web Access integrations

BCS was fully retired in Microsoft 365 on 30 September 2024. Do not design a new Online solution around external lists backed by BCS.

These are replacement directions, not feature-equivalent substitutions. Test refresh, authentication, licensing, and embedded experiences. A workbook that opens successfully may still fail its scheduled refresh or external-data requirement.

Action: Assign a replacement owner and acceptance test to every service-dependent process.

Step 4: Move MySites to OneDrive and Map Profiles

Treat MySites as a dedicated workstream. Personal documents, profile attributes, and social features need different handling.

MySite asset	Target approach
Personal working documents	User's provisioned OneDrive
Shared departmental documents	Owned SharePoint team site
Former employee documents	Approved records or successor location
Profile attributes	Authoritative Entra ID source plus supported profile mappings
Newsfeed and social history	Separate archive/retirement decision

Build a mapping of source personal-site URL, source account, target UPN, actual OneDrive URL, owner status, and exceptions.

1. Resolve duplicate, renamed, disabled, and departed accounts.
2. Confirm licensing and provision destination OneDrives.
3. Configure library-to-OneDrive migration tasks.
4. Pilot private documents, shared files, metadata, and history.
5. Communicate new links and sharing behavior.

Do not generate OneDrive URLs by guessing from employee names. Use provisioned destinations. SPMT supports OneDrive as a migration task destination.

Keep profile mapping separate from file ownership mapping. Document the authoritative source for department, manager, job title, and any custom attributes; confirm which properties synchronize and which need another supported management process.

Check: Verify every personal-site destination and approve former-employee handling before bulk migration.

Step 5: Decide What Happens to Classic Customizations

Inventory pages, master pages, page layouts, JSLink, Content Editor Web Parts (CEWP), Script Editor Web Parts (SEWP), custom CSS, and embedded integrations.

Decision	Suitable example	Delivery requirement
Migrate	Supported standard content or page components	Verify target behavior
Replace	Simple CEWP announcement or links	Native modern web part
Modernize	Classic publishing or wiki content	Modern pages and navigation
Rebuild	JSLink logic, custom application, server web part	JSON formatting, SPFx, Power Apps, or API
Retire	Unused dashboard or duplicate portal	Owner-approved removal

A copied page is not necessarily a functioning page. Check hard-coded URLs, DOM manipulation, unsupported APIs, scripts loaded from farm folders, and browser dependencies.

Custom master pages do not become modern SharePoint branding. Preserve the business requirement, then implement it using supported target capabilities. SharePoint add-ins are also unsuitable as a new target dependency following their Online retirement on 2 April 2026.

Use the classic-to-modern migration guide for component-level decisions.

Action: Give every customization a disposition, target implementation, owner, and functional test.

Step 6: Assess and Replace Workflows

The retirement dates differ:

• SharePoint 2010 workflows retired in SharePoint Online on 1 November 2020.
• SharePoint 2013 workflows retired in SharePoint Online on 2 April 2026.

These Online dates do not mean every on-premises workflow stopped running that day. Microsoft distinguishes the environments in its workflow retirement guidance.

For a bounded site collection, this query lists legacy workflow associations, including those using the 2010 platform:

$site = Get-SPSite "https://sharepoint.contoso.com/sites/finance"
try {
    Get-SPWeb -Site $site -Limit All | ForEach-Object {
        $web = $_
        try {
            foreach ($list in $web.Lists) {
                foreach ($workflow in $list.WorkflowAssociations) {
                    [pscustomobject]@{
                        Web = $web.Url
                        List = $list.Title
                        Workflow = $workflow.Name
                        Enabled = $workflow.Enabled
                        AssociationId = $workflow.Id
                    }
                }
            }
        }
        finally { $web.Dispose() }
    }
}
finally { $site.Dispose() }

This is a starting query, not a complete workflow audit. Assess 2013-platform subscriptions separately through Workflow Services APIs or a scanner supporting that platform. Include site workflows, Nintex/K2 definitions, custom actions, running instances, history, and external credentials.

Existing behavior	Replacement assessment
Approval or notification	Power Automate trigger, approval, escalation
Long-running state machine	Durable state, timeout, restart design
SQL or line-of-business integration	Connector/API, gateway, licensing
Nintex/K2 application	Vendor-supported migration or deliberate rebuild

Migration tooling can assist supported conversions; it does not prove process equivalence. Define how in-flight cases finish or restart without duplicate approvals. Assign flow ownership, connection references, environment, and support responsibility before launch.

Check: Require successful end-to-end business tests before disabling the source workflow.

Step 7: Replace InfoPath and Forms

InfoPath's July 2026 retirement makes replacement a migration prerequisite. Microsoft confirms that InfoPath 2013 support ended on 14 July 2026. InfoPath Forms Services in Online is not a viable destination runtime.

Do not confuse InfoPath retirement with retirement of Microsoft Forms or standard SharePoint list forms.

Existing form	Replacement direction
Simple list entry	Standard Microsoft Lists form
Conditional list interface	Power Apps customized list form
Multi-screen business application	Canvas app with suitable data platform
Relational, secured process	Dataverse-backed application
Survey or simple intake	Microsoft Forms where requirements fit

Inventory XSN templates, XML submissions, repeating sections, code-behind, data connections, attachments, validation rules, and workflow coupling.

Migrating XML preserves files, not necessarily a usable business record. Map fields into the destination schema, reconcile totals, and retain a readable historical representation where required. Test old submissions as well as new form entry.

Action: Approve replacement forms and historical-data access before scheduling their dependent sites.

Step 8: Resolve Permissions and Identity

NTLM, Kerberos, and claims describe source authentication. They do not become Online authentication settings.

Source condition	Required target work
DOMAIN\\user or Windows claims	Map to correct Entra ID identity
Multiple domains or renamed users	Explicit account mapping
AD synchronization	Confirm supported sync design, UPNs, object matching
SharePoint groups	Map membership and permission levels
Nested security groups	Test effective target access
Orphaned users	Resolve ownership and historical attribution separately
Unique item permissions	Preserve approved exceptions or simplify deliberately

Create an identity exception register before migrating permissions. Historical authorship does not justify granting an inactive account access. Decide whether existing SharePoint groups remain, whether membership changes, and how each approved AD group maps to a target principal.

SPMT's user-mapping documentation identifies mapping restrictions, including mapping AD groups to target SharePoint groups.

Test ordinary users, owners, restricted users, and guests. Administrator access can hide mapping failures.

Check: Prove both authorized access and denied access against the approved permission design.

Step 9: Design the Target Information Architecture

Do not recreate the farm hierarchy as a deep Online subsite tree.

Source concept	Target design question
Farm/web application	Which tenant governance and access boundaries apply?
Site collection/subsite	Does this need an independent modern site?
Department portal	Communication site, team site, or hub association?
Library/folder hierarchy	Which libraries, metadata, and views support discovery?
MMS hierarchy	Which term sets remain authoritative?

Hubs organize navigation and related experiences; association does not automatically grant access.

Create destinations, content types, columns, term mappings, version policies, sharing controls, and retention settings before migration. Decide tenant geography and data-location requirements before provisioning destinations across regional teams.

Keep a source-to-target URL map for links and integrations. Validate lookup dependencies when splitting subsites into separate sites; a cleaner hierarchy still needs working business relationships.

Action: Approve target architecture and provisioning standards before the pilot.

Step 10: Select Tooling Against Real Requirements

Evaluate tools against the same representative sample.

Tool	Source-version fit	Versions/history	Permissions fidelity	Practical role
SPMT	Direct Server 2013/2016/2019 sources	Configurable history preservation	Supported permissions with settings and identity mapping	Standard content migration
Migration Manager	Documented file-share/cloud scenarios; verify source support	File-share copying does not preserve SharePoint library history	Source-specific mapping	Separate file-share workstream
ShareGate Migrate	Lists 2013/2016/2019	Version-history copy options	Permission-copy options; validate mappings	Restructuring, reporting, migration operations
AvePoint	Lists 2013/2016/2019	Verify selected product and migration mode	Permission/metadata migration capabilities; pilot exceptions	Projects needing its orchestration and deployment model

Microsoft documents SPMT feature coverage and Migration Manager file-share tasks. ShareGate documents supported versions and copy options; AvePoint lists supported migration sources.

Permission preservation depends on supported principals and deliberate mapping. No migration engine installs a farm WSP into Online or restores a retired runtime.

Include drafts, approvals, attachments, metadata, unique permissions, and difficult filenames in the comparison. Record scan accuracy, retries, operational effort, and reporting quality alongside copy speed.

Check: Select tooling from measured pilot results and documented exceptions, rather than a feature checkbox.

Step 11: Run the Pilot, Waves, Delta, and Cutover

Phase	Required output
Pilot	Measured throughput, defects, remediation, user acceptance
Initial copy	Content staged while source remains authoritative
Waves	Owned groups of ready sites and users
Incremental passes	Reconciled changes and reduced cutover backlog
Freeze	Enforced source write boundary
Final delta	Last approved changes transferred
Cutover	Links, navigation, integrations, communications switched
Hypercare	Named support owners and tracked issues

Choose a pilot containing representative complexity, not only the cleanest library. Include a MySite, restricted content, classic pages, and a process replacement.

Estimate the freeze from observed backlog, retries, and validation time. Do not promise a fixed duration from terabytes alone; see how long SharePoint migration takes.

Confirm how incremental runs handle deletions, renames, moves, and destination edits. Delta migration is not automatically bidirectional synchronization. Prevent source workflows and target flows from processing the same case during transition.

For international teams, publish cutover times in UTC and local business zones. Define rollback conditions, authority, and reconciliation if users have already edited Online content.

Action: Rehearse the cutover runbook and obtain business approval for the freeze window.

Step 12: Validate and Obtain Sign-Off

A completed migration job is evidence, not business acceptance.

Validation	Acceptance evidence
Counts	Reconciled files/items with approved exclusions
Metadata	Required fields, dates, authors, taxonomy verified
Versions	Agreed history present and readable
Permissions	Positive and negative access tests
Links	Navigation, embedded links, integrations checked
Search	Expected content discoverable after indexing
Pages	Readable layouts and functioning components
Workflows/Flows	Triggers, approvals, exceptions, ownership tested
Forms	Submission, edit, attachment, historical-access tests
MySites/OneDrive	Correct owner, destination, sharing behavior

Use automated comparison for breadth and owner testing for business meaning. Search readiness is a separate check because indexing follows ingestion.

Record exceptions with severity, owner, workaround, and resolution date. Establish which defects block acceptance. Compare against the frozen source baseline, accounting for approved exclusions and transformations rather than expecting every raw count to match.

Follow the migration validation guide and retain migration logs, comparison reports, and signed acceptance.

Check: Obtain technical and business sign-off before decommissioning source access.

Mistakes That Increase Rework

Mistake	Better control
Assuming 2013 always requires a hop	Distinguish content migration from database upgrade
Estimating from database size alone	Include items, versions, permissions, applications
Copying classic pages without testing	Assess dependencies before copying
Treating MySites as ordinary team sites	Separate personal ownership and OneDrive mapping
Migrating workflows as definitions only	Validate replacement execution and in-flight cases
Running two writable environments	Declare one authoritative location per phase
Retiring the farm immediately	Preserve recovery and evidence until acceptance

Action: Add these controls to the project risk register and migration checklist.

Final Migration Checklist

• Scope and exclusions approved.
• Farm, templates, languages, and custom solutions inventoried.
• Service application replacements assigned.
• MySites and identities mapped.
• Pages, workflows, and forms have approved dispositions.
• Target sites and governance provisioned.
• Tool settings and exceptions proven in the pilot.
• Waves, freeze, delta, and rollback rehearsed.
• Content, access, links, search, and processes validated.
• Owners signed acceptance and decommissioning criteria.

Action: Use the migration hub to track supporting guidance against each unchecked item.

Frequently Asked Questions

How Much Does SharePoint Server to Online Migration Cost?

Budget for discovery, cleanup, migration tooling, application replacement, licensing, validation, and support. Workflow and form complexity can outweigh data-copy effort.

Action: Request a scoped estimate separating migration from modernization.

How Long Does It Take?

Duration depends on readiness, item/version counts, identity exceptions, application dependencies, throughput, and owner availability. A pilot provides a defensible forecast.

Action: Estimate each workstream before committing to a cutover date.

Can SharePoint 2013 Migrate Directly to Online?

Yes, SPMT supports direct content migration from SharePoint 2013. Database restoration or an on-premises upgrade is a separate path that may require intermediate versions.

Check: Confirm source accessibility and scan results.

What Happens to Workflows and MySites?

Workflows require supported replacements and a plan for running cases. MySite documents need mapped OneDrive or shared-site destinations; profiles and social history require separate decisions.

Action: Track both as dedicated migration workstreams.

What Happens to Custom Code?

Farm solutions cannot execute in Online. Replace needed functionality with supported SPFx, Power Platform, or external services; retire unused components.

Action: Inventory behavior and dependencies before estimating a rebuild.

Bottom Line

Plan the content move and application replacements together. The migration succeeds when users can find information, retain appropriate access, and complete their work in the target environment.

nextM365's SharePoint migration services can help define scope, dependencies, architecture, and delivery gates.

Book a SharePoint Migration Assessment

Action: Start with an evidence-based assessment and one representative pilot.

Sources

• Microsoft Learn: SharePoint Migration Tool overview
• Microsoft Learn: SPMT supported features
• Microsoft Learn: Migrate to Microsoft 365
• Microsoft Learn: SPMT prerequisites

Check: Revalidate source support, retirement notices, and selected tool behavior when approving the migration design.