SharePoint Server 2019 Support Ending July 2026: Risks, Upgrade Paths & Migration Guide

Extended support for SharePoint Server 2019 ends on July 14, 2026. After that date, Microsoft stops all security patches, bug fixes, and technical support. Your SharePoint farm will still run — Microsoft doesn't remotely disable anything — but every day you operate past that date, you accumulate security debt, compliance risk, and technical isolation that only gets harder to unwind.

But the server end-of-life date is only half the story. Several legacy components — SharePoint 2013 workflows, SharePoint Add-ins, and Azure ACS — are fully retired from Microsoft 365 tenants on April 2, 2026, months before the server deadline. If your migration strategy assumes everything works until July, your business processes will break mid-flight.

This guide covers the exact deadlines, the real security and compliance exposure, both supported upgrade paths (SharePoint Online and SharePoint Server Subscription Edition), the technical limitations of native migration tools, and a concrete roadmap for IT teams that need to move before the deadline.

For a broader view of every Microsoft product retirement hitting in 2026 — including Exchange 2016, Office Online Server, and SharePoint 2016 — see our Microsoft 2026 End-of-Support Timeline.

What "End of Support" Actually Means for SharePoint Server 2019

End of support is not end of life in the literal sense. Your servers won't shut down. But the operational reality shifts dramatically.

SharePoint Server 2019 follows Microsoft's Fixed Lifecycle Policy with two phases:

• Mainstream support ended January 9, 2024. Since then, Microsoft has stopped delivering feature updates and non-security bug fixes.
• Extended support ends July 14, 2026. This is the final cutoff. After this date: no security updates — not even critical ones — no paid support incidents, and no technical content updates. (learn.microsoft.com)

Once extended support ends, here is what stops:

What stops	Impact
Security patches	New vulnerabilities remain permanently unpatched
Bug fixes	Known issues will never be resolved
Microsoft support cases	No paid support, only community forums
Compliance certifications	Auditors flag unsupported software as a control failure
Vendor ecosystem	Third-party tools and connectors drop support for EOL platforms

The Security Risk Is Not Theoretical

Running unsupported SharePoint isn't a hypothetical compliance checkbox. It's an active attack surface.

In July 2025, multiple critical zero-day vulnerabilities collectively known as "ToolShell" were actively exploited against on-premises SharePoint servers. The most severe, CVE-2025-53770, carried a CVSS score of 9.8 (Critical) and enabled unauthenticated remote code execution — attackers could fully compromise a SharePoint server without any credentials. CISA added it to the Known Exploited Vulnerabilities catalog on July 20, 2025. (microsoft.com)

Microsoft confirmed that Chinese nation-state actors (Linen Typhoon, Violet Typhoon) and a separate threat actor (Storm-2603) deploying ransomware were actively exploiting these flaws against internet-facing SharePoint servers. Targets included government agencies, schools, healthcare organizations, and large enterprises.

Microsoft released emergency patches — but only for supported versions: SharePoint Server Subscription Edition, 2019, and 2016. Once SharePoint 2019 leaves support in July 2026, the next ToolShell-class vulnerability gets no patch. Ever.

The practical consequences:

• Regulatory exposure: NIST SP 800-53 (SA-22), ISO 27001, HIPAA, SOC 2, and Cyber Essentials Plus require supported, patched software. Running unsupported SharePoint is a direct control failure that auditors will flag.
• Insurance risk: Cyber insurance providers increasingly require evidence of supported software stacks. An unpatched SharePoint server could void coverage.
• Lateral movement: A compromised SharePoint server isn't just a document breach — it's a gateway to Active Directory, Teams, and every integrated Microsoft service.

For permissions hardening before migration, see our Definitive Guide to SharePoint Permissions & Security.

The April 2026 Deadline: Workflows, Add-ins, and InfoPath

While the server itself survives until July 2026, the ecosystem around it does not. Microsoft is retiring legacy extensibility models on a separate, earlier timeline. If you plan to migrate to SharePoint Online, you must rebuild these dependencies before or in parallel with your content migration — not after.

SharePoint Add-ins and Azure ACS — April 2, 2026

The SharePoint Add-in extensibility model and Azure Access Control Service (ACS) are permanently retired from all SharePoint Online tenants on April 2, 2026. This is a hard stop with no extension option, affecting all tenants including GCC, GCC High, and DoD. (learn.microsoft.com)

Both SharePoint-hosted and provider-hosted Add-ins stop functioning on that date. Replacements must use SharePoint Framework (SPFx) for UI components and Microsoft Entra ID for authentication. There is no automated migration path.

For full technical details, see our SharePoint Add-ins Retirement: The April 2026 Migration Guide.

SharePoint 2013 Workflows — April 2, 2026

SharePoint 2013 workflows are fully removed from all existing Microsoft 365 tenants on April 2, 2026. SharePoint 2010 workflows were already removed in November 2024. The replacement is Power Automate.

On-premises SharePoint Server 2019 still runs these workflows until you decommission the farm — but they cannot be migrated to SharePoint Online. They must be rebuilt from scratch in Power Automate. Even on-prem, Microsoft Workflow Manager 1.0 is supported only according to the parent SharePoint version or until July 14, 2026, whichever comes first. (learn.microsoft.com)

InfoPath Forms Services — July 14, 2026

InfoPath Forms Services will be removed from SharePoint Online after July 14, 2026. The InfoPath 2013 client also reaches end of extended support on the same date. Microsoft has stated there will be no extension. (learn.microsoft.com)

The replacement is Power Apps. There is no automated conversion tool. Each form must be manually rebuilt, including data connections, validation rules, and workflow integrations.

For a complete walkthrough of the InfoPath and workflow retirement, see our InfoPath & SharePoint Workflows Ending 2026: Migration Guide.

Path 1: Migrating to SharePoint Online (Microsoft 365)

For most organizations, SharePoint Online is the target destination. It eliminates server infrastructure, delivers automatic security updates, and provides access to Copilot, Teams integration, and the full Microsoft 365 ecosystem.

But moving from on-prem SharePoint 2019 to SharePoint Online is not a lift-and-shift. It requires a fundamental architectural transformation.

The Flat Architecture Shift

SharePoint Server 2019 typically uses a deep hierarchical structure: site collections containing subsites, sub-subsites, and deeply nested libraries. SharePoint Online uses a flat architecture based on modern Team Sites and Communication Sites connected via Hub Sites. (learn.microsoft.com)

Classic subsites still technically exist in SharePoint Online, but Microsoft actively discourages them. New features — Copilot, Viva, modern search — are designed for the flat model. Migrating subsites as-is creates legacy debt that limits every future capability.

You cannot simply copy a subsite tree into SharePoint Online. You must programmatically flatten your topology, mapping legacy subsites to independent modern sites and associating them with a Hub.

When shifting to a flat architecture, you lose the ability to inherit Content Types from a root site collection down to subsites. You must use the SharePoint Content Type Hub or tenant-level Content Type Gallery to syndicate metadata definitions across your new Hub Sites. Failing to map this correctly during migration results in orphaned metadata and broken enterprise search.

For detailed mapping strategies, see our guide on Transitioning from Subsites to Hub Sites.

What Migrates (and What Doesn't)

Component	Migrates?	Notes
Documents & files	✅ Yes	Via SPMT, ShareGate, or API scripts
Document libraries	✅ Yes	Structure preserved, but consider flattening
Lists & list items	✅ Yes	Some column types may need remapping
Metadata & managed terms	⚠️ Partial	SPMT has known issues with custom metadata mapping
Version history	⚠️ Partial	Configurable; large version histories slow migration significantly
Permissions	⚠️ Partial	Basic permissions migrate; complex inheritance may break
SharePoint 2013 workflows	❌ No	Must rebuild in Power Automate
SharePoint Designer workflows	❌ No	Must rebuild in Power Automate
InfoPath forms	❌ No	Must rebuild in Power Apps
Custom Add-ins	❌ No	Must rebuild in SPFx / Entra ID
Server-side code / sandbox solutions	❌ No	Must rebuild as SPFx or Azure Functions
Nintex workflows	❌ No	Must rebuild or use Nintex for M365

The Permissions Audit Problem

On-premises SharePoint farms accumulate years of permission sprawl — broken inheritance, direct user assignments, orphaned groups. Migrating broken permissions to the cloud doesn't fix them; it makes them harder to find and harder to govern.

Before moving data, you must map legacy Active Directory groups to Entra ID (formerly Azure AD) and enforce Microsoft 365 Group-based permissions.

SharePoint Online also enforces permission boundaries that matter during migration: a maximum of 5,000 role assignments per security scope, a recommended 5,000 unique permissions per list or library (with a supported ceiling of 50,000), and a hard rule that folders exceeding 100,000 items cannot have inheritance broken after the fact. If your current farm relies on heavy item-level sharing, fix that during architecture design — not during cutover week. (learn.microsoft.com)

For exact methodologies, review The Definitive Guide to SharePoint Permissions & Security.

Path 2: Upgrading to SharePoint Server Subscription Edition

SharePoint Server Subscription Edition (SE) is Microsoft's final on-premises SharePoint release. It follows an "evergreen" model with biannual feature updates (e.g., 25H1, 25H2) and monthly cumulative patches. There is no fixed end-of-life date.

SE is designed for organizations that cannot move to the cloud due to data sovereignty requirements, air-gapped environments, regulatory constraints, or deeply embedded server-side integrations. It is not a stepping stone — it's a long-term on-premises commitment.

The Database-Attach Upgrade Process

You cannot perform an in-place upgrade from SharePoint 2019 to SE. The transition requires the database-attach method:

1. Build a new SE farm — Install SharePoint Server SE on new infrastructure (Windows Server 2019/2022/2025, SQL Server 2019 CU5+ or 2022 with compatibility level 150). (learn.microsoft.com)
2. Copy databases — Set the SP 2019 farm to read-only. Back up content and service application databases and restore them on the SE SQL instance.
3. Upgrade service applications — Attach and upgrade databases for Managed Metadata, User Profile, Business Data Connectivity, Secure Store, and Search.
4. Upgrade content databases — Use PowerShell (Mount-SPContentDatabase) to attach content databases to web applications and run the site collection upgrade.

Key Constraints

• No in-place upgrade. Configuration and Central Administration databases are recreated from scratch — they cannot be migrated.
• Software Assurance is mandatory. SE requires active Software Assurance (SA) on both server licenses and all CALs. If SA lapses, you lose the right to run SE and fall back to SharePoint 2019 license rights.
• SQL Server licensing. SE requires SQL Server 2019 CU5+ or SQL Server 2022. SQL licensing is often the single largest cost in an on-premises SharePoint deployment.
• Hub sites are not available. SharePoint Server (including SE) does not support Hub Sites. If your long-term plan depends on a flat architecture with hub-based navigation and roll-up, SE buys time and support but does not replicate the destination model of SharePoint Online. (learn.microsoft.com)
• Feature gap vs. SharePoint Online. SE does not have full parity with SPO. Copilot, Microsoft Loop, advanced Viva features, and many modern web parts are SPO-only.
• Search index rebuild. The search index is rebuilt from scratch during the upgrade; search analytics data from the SP 2019 farm cannot be fully retained.
• Custom solutions must be pre-installed. All server-side customizations must be installed on the SE farm before upgrading content databases. Missing features or solutions are the most common cause of upgrade failures.
• Add-in model preserved. The SharePoint Add-in retirement does not affect on-prem. SE can preserve older customizations that would already be dead in Microsoft 365. (learn.microsoft.com)

SharePoint Online vs. Subscription Edition: Decision Framework

Factor	SharePoint Online	SharePoint Server SE
Data location	Microsoft datacenters (region-selectable)	Your servers, your datacenter
Security patches	Automatic, zero effort	Manual, biannual + monthly CUs
Infrastructure cost	None (SaaS)	Hardware + SQL Server + Windows Server
Licensing model	Per-user/month	Server license + CALs + mandatory SA
Feature roadmap	Continuous innovation, Copilot, AI	Biannual updates, trailing feature set
Data sovereignty	Dependent on datacenter locations	Full organizational control
Hub site architecture	Full support	Not available
IT staffing	Minimal SharePoint admin overhead	Requires dedicated on-prem team
Legacy workflows	Must rebuild (Power Automate)	Existing SP 2013 workflows continue
Legacy Add-ins	Must rebuild (SPFx / Entra ID)	Continue functioning

Choose SharePoint Online if: You want to eliminate infrastructure overhead, need Copilot/AI capabilities, have a distributed workforce, or want predictable per-user costs. Accept that legacy workflows, forms, and Add-ins must be rebuilt.

Choose Subscription Edition if: You have strict data sovereignty mandates (defense, classified environments), cannot store data outside your physical network, or have deeply embedded server-side customizations that cannot be rebuilt on a short timeline.

Choose hybrid if: You need data sovereignty for specific workloads while using SharePoint Online for general collaboration. This adds complexity — two environments to manage — but it's a valid bridging strategy.

The cost comparison trips up many teams. SE usually lowers immediate migration pressure but preserves infrastructure cost and operational ownership. SharePoint Online removes the farm but often increases one-time migration cost because architecture, permissions, and legacy business logic need cleanup or rebuild. The right comparison is operating model plus modernization effort, not license vs. license.

Why Native Tools Fail at Enterprise Scale

Microsoft's free SharePoint Migration Tool (SPMT) is the default starting point for any SP 2019 to SharePoint Online migration. It handles basic content, supports incremental migration (delta sync), and integrates with the Migration Manager in the SharePoint admin center. It works for standard content. It is not a modernization engine.

SPMT's Hard Limits

• 400-character URL path limit. SharePoint Online enforces a 400-character limit on the decoded file path (starting from /sites/...). Deeply nested folder structures from on-prem environments routinely exceed this. SPMT will fail on these items without auto-remediation, forcing manual renaming and re-runs. (support.microsoft.com)
• No workflow migration. SharePoint 2010/2013 workflows, Nintex workflows, and SharePoint Designer workflows are not migrated. Period.
• No custom solution migration. Custom web parts, InfoPath forms, sandbox solutions, and Add-ins are out of scope.
• Limited metadata mapping. SPMT lacks detailed mapping options for custom metadata and managed properties, leading to data loss or inconsistency in environments with rich taxonomies.
• API throttling. Microsoft 365 aggressively throttles migration traffic. Tools using the SharePoint Migration API package data into Azure Blob Storage before ingestion. Large batches or peak-hour transfers trigger 429 Too Many Requests responses. Standard tools often fail to implement intelligent exponential backoff, resulting in incomplete transfers and corrupted version histories.
• Weak error reporting. SPMT generates spreadsheet-based post-action reports that are difficult to parse for root-cause analysis at scale.
• 250 GB file size cap. This is a SharePoint Online platform limit that applies to all ingestion methods.
• Custom Script requirement. Some web parts require Custom Script to be enabled on the destination site during migration, or they won't transfer. (learn.microsoft.com)

Third-Party Alternatives

ShareGate is a desktop-based tool that offers unlimited data transfer, better reporting, and content restructuring during migration. It handles permissions mapping well but does not migrate workflows, custom code, or third-party add-ons. Classic pages and web parts do not automatically modernize. (sharegate.com)

AvePoint Fly is an enterprise SaaS migration suite with pre-migration assessment, policy-based scheduling, and governance features. Designed for 10,000+ user environments. Higher cost, but strong orchestration for massive M365 transformations. It still does not eliminate the need to rebuild retired legacy components. (cdn.avepoint.com)

Custom PowerShell / Microsoft Graph API scripts give full control but require significant engineering investment. They bypass SPMT limitations around custom metadata mapping, throttle management, and retry logic. Microsoft's throttling guidance requires clients to honor 429 responses and the Retry-After header. (learn.microsoft.com) This is where most complex enterprise migrations end up — custom scripts handling the edge cases that no packaged tool covers.

Migration Roadmap: A Practical Timeline

Enterprise SharePoint migrations typically take 6 to 18 months depending on environment complexity, customization volume, and organizational change management. With the July 2026 deadline, that window is closing fast.

Phase 1: Discovery and Audit (Weeks 1–4)

• Inventory every site collection, subsite, document library, and list
• Catalog all workflows (SP 2010, SP 2013, Nintex, custom)
• Catalog all InfoPath forms and their data connections
• Identify all SharePoint Add-ins and ACS-dependent integrations
• Map permissions structure and flag broken inheritance
• Measure content volume (GB, item counts, version history depth)
• Identify ROT (Redundant, Obsolete, Trivial) content for archival or deletion — this routinely eliminates 30–50% of total content

Separate plain content from application behavior early. Documents, libraries, and metadata are one workstream. Workflows, forms, Add-ins, and event handlers are another. Most failed projects happen because teams bundle both into a single migration line item and treat the second category as minor.

Phase 2: Architecture and Remediation (Weeks 5–10)

• Design the target SharePoint Online site architecture (Hub Sites, Team Sites, Communication Sites) or provision the new SE farm infrastructure
• Map legacy subsites to the new flat structure
• Begin rebuilding critical workflows in Power Automate
• Begin rebuilding InfoPath forms in Power Apps
• Flatten folder structures that exceed the 400-character URL limit
• Clean up permissions, resolve orphaned accounts, and normalize group assignments
• For SP SE upgrades: verify database versions are at 16.0.4351.1000+, install all custom solutions on the new farm

Phase 3: Pilot Migration (Weeks 11–14)

Pilot the worst site first. Do not pilot the clean HR communication site that nobody customized. Pilot the ugly one: the legacy publishing site, the permissions-heavy records library, or the workflow-driven department portal. Easy sites create false confidence. Difficult sites create useful estimates.

• Migrate one complex site collection to validate content integrity, metadata, permissions, and version history
• Test rebuilt workflows and forms in the target environment
• Measure throughput and identify throttling patterns
• Document every failure and build remediation scripts

Phase 4: Production Migration Waves (Weeks 15–24+)

• Migrate remaining content in phased waves during off-peak hours
• Run delta syncs to capture changes made after the initial migration pass
• Execute final cutover with DNS/URL redirects
• Validate user access and run post-migration QA — test counts, metadata, permissions, versions, page rendering, search visibility, broken links, workflow replacements, and form replacements
• Decommission the legacy SharePoint 2019 farm intentionally: set it to controlled read-only mode, communicate where authoritative content now lives, and remove legacy dependencies in a planned sequence

Why Cloud Migration Keeps Winning the Tie-Breaker

The July 2025 ToolShell exploit chain was a turning point for many organizations still evaluating their options. Unauthenticated RCE vulnerabilities actively exploited by nation-state actors — and only supported versions receiving emergency patches — made the cost of staying on-prem viscerally clear.

Beyond security, the operational math increasingly favors SharePoint Online:

• No hardware refresh cycles. On-prem SharePoint requires server hardware replacement every 3–5 years.
• No SQL Server licensing. Frequently the highest single line item in on-prem SharePoint TCO.
• No patching labor. Monthly patch testing, staging, and deployment consumes significant IT hours.
• AI readiness. Microsoft Copilot works only with SharePoint Online content. Organizations that stay on-prem are locked out of the AI feature roadmap entirely.

That said, cloud is not automatically the right answer. If on-prem constraints are real — data sovereignty, air-gapped networks, tightly coupled internal integrations — SE is the correct move. The mistake is not choosing SE. The mistake is drifting into July 2026 without deciding.

What to Do Right Now

SharePoint Server 2019 end of support isn't a single event — it's the convergence of server EOL, Add-in retirement, workflow shutdown, and InfoPath deprecation all hitting within a three-month window. The organizations that come through clean are the ones that started early, understood the full scope, and treated migration as an engineering project.

1. Start your environment audit today. You can't plan what you don't understand. Catalog everything: sites, workflows, forms, Add-ins, permissions, and content volume.
2. Pick your destination. SharePoint Online for most. Subscription Edition for data sovereignty requirements only. Hybrid when specific workloads demand it.
3. Budget for workflow and form rebuilds. These are the most underestimated cost in every SharePoint migration. No tool migrates them — they must be re-engineered.
4. Don't rely solely on SPMT. It works for basic content. For enterprise-scale migrations with complex metadata, deep folder structures, and custom integrations, you need either a third-party tool or custom API scripts.
5. Pilot the hardest workload first. Surface real scope early instead of building false confidence with easy sites.
6. Plan for parallel operations. Keep the old farm live until the new environment is validated. Set it to read-only during final cutover, not before.
7. Test relentlessly. A migration can look complete in the dashboard and still fail the business because one approval route, one permission edge case, or one content lookup broke.