Classic SharePoint Is Retiring: The Complete 2026–2027 Migration Roadmap

Where Classic SharePoint Actually Stands Today

There was never a single day when classic SharePoint switched off, and that is precisely why so many organisations are still running it. Microsoft has not deleted classic sites from SharePoint Online — a classic team site provisioned in 2014 will still render in a browser this afternoon. What Microsoft has done instead is systematically dismantle everything around classic: the authentication model that let Add-ins connect, the workflow engine that ran business processes, the forms service that captured data, the design tool that built it all, and the on-premises servers that hosted the hybrid half.

The result is a platform that looks alive and behaves increasingly like a liability. Pages render, but the approval workflow behind them stopped firing. The site loads, but the Add-in that pulled in CRM data now throws an authentication error. The form still opens, but nobody at Microsoft will take a support ticket about it. This is the pattern that makes classic SharePoint to modern migration urgent in a way that a single hard deadline never would be: the failures are staggered, they surface in production, and each one lands without warning on a process somebody depends on.

This guide is the roadmap we use on real modernisation engagements. It covers every retirement date that matters, gives you the PowerShell to measure your own exposure before you talk to anyone, sets out how to decide what to rebuild versus retire, and lays out realistic effort so you can budget properly instead of guessing.

The Complete Retirement Timeline

Here is the consolidated picture across every classic SharePoint dependency. Dates marked passed are already unsupported — if you are still running those components, you are operating without patches or support today.

Step 1 — Audit Your Classic Footprint

Every credible modernisation plan starts with a measured inventory, not an estimate. You cannot scope what you have not counted, and in our experience the gap between what an organisation believes it runs and what its tenant actually contains is consistently between 30% and 60% — almost always in the direction of more classic than expected.

Run these scripts against your own tenant before engaging any vendor, including us. They take under an hour and the output is genuinely yours: it tells you whether you have a nine-week problem or a nine-month programme.

1a. Inventory every site collection by template

This is the foundation. Site template IDs tell you immediately which sites are classic and which are already modern.

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

$sites = Get-PnPTenantSite -IncludeOneDriveSites:$false

# Full export for the record
$sites | Select-Object Url, Template, LastContentModifiedDate, StorageUsageCurrent |
    Sort-Object Template |
    Export-Csv ".\sp-site-inventory.csv" -NoTypeInformation

# Template reference:
#   STS#0                    = Classic Team Site      -> needs migration
#   STS#1                    = Classic Blank Site     -> needs migration
#   BLANKINTERNETCONTAINER#0 = Classic Publishing     -> needs migration
#   GROUP#0                  = Modern Team Site       -> already modern
#   SITEPAGEPUBLISHING#0     = Communication Site     -> already modern

$classic = $sites | Where-Object {
    $_.Template -in @("STS#0", "STS#1", "BLANKINTERNETCONTAINER#0")
}

Write-Host "Classic sites: $($classic.Count) of $($sites.Count)"

# Dormant classic sites are migration candidates for retirement, not rebuild
$cutoff = (Get-Date).AddMonths(-18)
$classic | Where-Object { $_.LastContentModifiedDate -lt $cutoff } |
    Select-Object Url, LastContentModifiedDate |
    Export-Csv ".\dormant-classic-sites.csv" -NoTypeInformation

That last query is the one that saves the most money. In most tenants, a meaningful share of classic sites have not been touched in over eighteen months. Those do not need migrating — they need archiving and decommissioning, which costs a fraction of a rebuild.

1b. Find ACS app principals — your nine-week exposure

This is the most time-critical query in the entire audit. Anything it returns stops authenticating in November.

Connect-PnPOnline -Url "https://contoso-admin.sharepoint.com" -Interactive

# Legacy ACS principals registered at tenant scope
Get-PnPAzureACSPrincipal -Scope Tenant -IncludeSubsites:$false |
    Select-Object AppIdentifier, Title, RedirectUri, ValidUntil |
    Export-Csv ".\acs-principals-tenant.csv" -NoTypeInformation

# Site-scoped principals are easy to miss and just as fatal
foreach ($site in (Get-PnPTenantSite -IncludeOneDriveSites:$false)) {
    Connect-PnPOnline -Url $site.Url -Interactive
    $p = Get-PnPAzureACSPrincipal -Scope Site -ErrorAction SilentlyContinue
    if ($p) {
        $p | Select-Object @{n='Site';e={$site.Url}}, AppIdentifier, Title |
            Export-Csv ".\acs-principals-site.csv" -Append -NoTypeInformation
    }
}

# Also check which Add-ins are actually installed and enabled
Get-PnPApp -Scope Tenant |
    Select-Object Title, Id, InstalledVersion, IsEnabled, AppCatalogVersion |
    Export-Csv ".\installed-apps.csv" -NoTypeInformation

1c. Find 2013 workflows still in use

Counting workflow definitions overstates the problem — many were built and abandoned. Counting active subscriptions with recent run history tells you what genuinely needs rebuilding.

$results = @()

foreach ($site in (Get-PnPTenantSite -IncludeOneDriveSites:$false)) {
    try {
        Connect-PnPOnline -Url $site.Url -Interactive

        # SharePoint 2013 (Workflow Manager) definitions
        $defs = Get-PnPWorkflowDefinition -ErrorAction SilentlyContinue

        # Subscriptions are what actually run
        $subs = Get-PnPWorkflowSubscription -ErrorAction SilentlyContinue

        foreach ($s in $subs) {
            $results += [pscustomobject]@{
                Site         = $site.Url
                Workflow     = $s.Name
                Enabled      = $s.Enabled
                ListId       = $s.ListId
                DefinitionId = $s.DefinitionId
            }
        }
    } catch {
        Write-Warning "Skipped $($site.Url): $($_.Exception.Message)"
    }
}

$results | Export-Csv ".\workflow-2013-inventory.csv" -NoTypeInformation
Write-Host "Active 2013 workflow subscriptions: $(($results | Where-Object Enabled).Count)"

1d. Find InfoPath forms and classic web parts

InfoPath form libraries use base template 115. Classic Content Editor and Script Editor web parts hide inside wiki page HTML, which means you have to inspect page content rather than query a list.

Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/finance" -Interactive

# InfoPath form libraries (BaseTemplate 115 = XMLForm)
Get-PnPList | Where-Object { $_.BaseTemplate -eq 115 } |
    Select-Object Title, ItemCount, DefaultViewUrl

# Classic vs modern pages: modern pages carry a ClientSideApplicationId
$pages = Get-PnPListItem -List "Site Pages" -PageSize 500

foreach ($p in $pages) {
    $name = $p.FieldValues["FileLeafRef"]
    $isModern = [bool]$p.FieldValues["ClientSideApplicationId"]
    $html = $p.FieldValues["WikiField"]

    if (-not $isModern) {
        # Flag embedded script — these need manual rebuild, not transformation
        $hasScript = $html -match '<script|ScriptEditorWebPart|ContentEditorWebPart'
        [pscustomobject]@{
            Page          = $name
            EmbeddedScript = $hasScript
        }
    }
}

Step 2 — Classify Every Artefact You Found

The single most expensive mistake in classic SharePoint migration is treating it as a lift-and-shift exercise. A large share of what you inventoried should never be rebuilt at all. Classify every artefact into one of four dispositions before estimating anything.

Run this classification with the business, not just IT. The question that resolves most disagreements quickly is not "do you use this?" but "if this stopped working on Monday, what would you do instead?" If the answer is a shrug, it is a Retire. If the answer describes a manual workaround people already use, it is usually a Replace. Only when the answer is "the process would stop" are you looking at a genuine Rebuild.

What Each Migration Path Actually Costs In Effort

These are person-day ranges from delivered modernisation work. They assume a competent SharePoint and Power Platform developer, existing tenant governance, and business availability for requirements and testing. They exclude programme management and change communications, which typically add 15–25% on top.

To turn this into a budget, multiply your classified inventory by these ranges and add the 15–25% programme overhead. For a sanity check against that number, our SharePoint intranet cost calculator models a modern build from scratch, and the Power Automate ROI calculator helps quantify the savings side when you are replacing manual processes rather than just migrating them.

The Compounding Cost of Waiting

Deferring modernisation feels free because nothing on the invoice changes. The cost is real but it accrues in places that do not appear in an IT budget line.

Security and compliance exposure

Unsupported components receive no security patches. SharePoint Server 2016 and 2019 farms past end of support are unpatched workloads, and in most regulated frameworks an unsupported system holding business records is an auditable finding — one that is significantly cheaper to remediate before an auditor writes it up than after.

The talent problem

The pool of engineers who can safely modify a SharePoint 2013 workflow or debug a provider-hosted Add-in shrinks every year, and the people who remain charge a premium precisely because the skill is scarce. Meanwhile the tooling is gone: with SharePoint Designer unsupported, there is no sanctioned way to edit a classic workflow at all. You are maintaining a system you cannot legally tool for with people who are increasingly hard to hire.

Opportunity cost in the AI layer

This is the argument that has moved most decision-makers in the last eighteen months. Microsoft 365 Copilot, Viva Connections, modern search, and Copilot agents all ground themselves in modern SharePoint surfaces. Content sitting in classic pages is substantially less discoverable and largely invisible to the agent layer. Every quarter spent on classic is a quarter where your organisation's knowledge is not reachable by the tools your competitors are already deploying.

Emergency migration costs more

A planned migration lets you retire dormant sites, replace custom code with first-party features, and sequence work around business cycles. An emergency migration after a hard break skips all of that — you rebuild exactly what broke, as fast as possible, usually at premium rates and often carrying the original design flaws into the new platform. Organisations that wait do not avoid the cost; they pay a higher one with fewer options.

The Four-Phase Migration Roadmap

This is the delivery structure we run. The phases exist in this order because each one de-risks the next, and because the sequencing front-loads the hard deadlines.

Phase 1 — Assessment and inventory (2–4 weeks)

Run the Step 1 audit across the full tenant. Classify every artefact using the Step 2 matrix with business input. Produce a costed backlog and a risk register ordered by deadline, not by site. The deliverable is a decision-ready document: what we keep, what we kill, what it costs, and in what order.

Critically, Phase 1 also resolves the ACS deadline separately and immediately. Do not let a nine-week authentication break queue behind a nine-month page migration — it runs as a parallel workstream from day one.

Phase 2 — Pilot migration (3–6 weeks)

Pick two or three representative sites: one straightforward content site, one with a workflow, one with custom code. Migrate them end to end, including user acceptance testing and a real cutover. The purpose is not to migrate three sites — it is to calibrate your effort estimates against reality and to build the repeatable runbook.

Expect your Phase 1 estimates to move after the pilot. That is the pilot working correctly. Re-baseline the backlog before starting Phase 3.

Phase 3 — Wave migration (3–6 months)

Group remaining sites into waves by business unit or by similarity, whichever produces cleaner communication. Similarity grouping is more efficient for the delivery team; business-unit grouping is easier for change management. For most organisations, business-unit waves win because adoption failure costs more than a few extra delivery days.

Each wave follows the runbook: confirm inventory, migrate content, rebuild logic, test with owners, cut over, monitor for two weeks, close. Deadline-driven items — remaining ACS integrations, then 2013 workflows — are scheduled into the earliest waves regardless of which business unit owns them.

Phase 4 — Governance hardening (2–3 weeks)

The phase most programmes skip, and the reason so many organisations are doing this a second time. Without controls, classic patterns return: someone provisions a classic template through a legacy script, someone pastes JavaScript into a page, someone registers a new app with a client secret. Phase 4 closes those doors.

Governance: Stopping Classic Drift From Returning

Four controls prevent regression. Implement all of them before you declare the programme complete.

• Block classic provisioning. Restrict site creation to approved modern templates through a site-provisioning solution or PnP site designs. Remove the ability for end users to create classic templates at all.
• Enforce app registration standards. Require certificate-based authentication for all new Entra ID app registrations touching SharePoint. Prohibit client secrets by policy and audit for them quarterly — this is the control that prevents a repeat of the ACS scramble.
• Gate custom code. Route all SPFx solutions through a reviewed App Catalog deployment with a documented owner and a named business sponsor. An SPFx solution with no identified owner is a future migration line item.
• Report on classic inventory continuously. Schedule the Step 1 inventory scripts monthly and surface the classic count on an admin dashboard. What gets measured stops growing.

Frequently Asked Questions