SharePoint 2016 and 2019 Support Ends July 14. Here’s Your Migration Checklist

For organizations still running SharePoint Server 2016 or 2019, July 14, 2026, is a fixed date on the IT calendar. On that date, Microsoft ends extended support for both versions. There will be no further security updates, no patches, no technical assistance from Microsoft, and no further compatibility guarantees with the wider Microsoft ecosystem.

For most enterprises, the question is no longer whether to migrate. It is how to migrate without disrupting the business, where to land, and how much legacy weight to carry forward. This article lays out a practical migration checklist for IT leaders who want to use the remaining runway carefully, rather than scramble in the final months.

What “End of Support” Actually Means

A common misunderstanding among business leaders is that “end of support” means the system stops working. It does not. SharePoint Server 2016 and SharePoint Server 2019 farms will continue to start up, serve content, and accept user requests after July 14, 2026. The change is what happens behind that experience.

Microsoft will no longer publish security updates for newly discovered vulnerabilities. Engineering teams will not produce hotfixes for SharePoint-specific defects. Paid support channels will stop accepting tickets for these versions. Third-party vendors will, in most cases, follow Microsoft’s lead and retire their own support for products that integrate with these platforms.

In practical terms, the system continues. The safety net underneath it does not. That is the gap that creates risk and is the one compliance auditors, security teams, and insurance providers tend to focus on.

Why July 14, 2026 Matters for IT, Security, and Compliance

The deadline matters for several reasons that are easy to underestimate when read in isolation.

Security exposure compounds quickly. Attackers actively scan for known vulnerabilities in unsupported software. Public exploit details often emerge in the months after end-of-support dates, and there is no patch path once Microsoft closes the line. The July 2025 SharePoint Server zero-day campaign, which Microsoft addressed through emergency updates, is a useful reminder that on-premises SharePoint remains a high-value target.

Compliance frameworks treat unsupported software as a finding. Standards such as ISO 27001, SOC 2, HIPAA, PCI DSS, and most government frameworks expect organizations to run vendor-supported software for systems that hold regulated data. Many cyber insurance policies now ask the same question during renewal. Running SharePoint 2016 or 2019 past July 2026 is likely to trigger audit findings, exception processes, or higher premiums.

Related platforms retire at the same time. Several dependent technologies share the July 14, 2026, cut-off, including InfoPath Forms Services, SharePoint Designer 2013 against Subscription Edition, and SharePoint 2010 workflows. SharePoint Add-Ins and Azure ACS in Microsoft 365 are scheduled to retire on April 2, 2026, ahead of the server deadline. Organizations that depend on these features need a coordinated plan, not a single product migration.

Migrations take longer than leadership teams expect. Industry observations suggest that most enterprise SharePoint migrations take between 6 and 18 months from kickoff to stable operation, and complex environments routinely exceed that window. Counting back from July 2026, the realistic planning window is already narrow for organizations that have not started.

Why Lift-and-Shift Is Rarely the Right Answer

There is a temptation, especially under deadline pressure, to treat migration as a copy operation. Move every site, every library, every list, and every permission as-is to a new environment and call the project complete.

For most enterprises, that approach carries forward a decade or more of accumulated debt. Stale site collections that no one owns. Permissions that drifted away from the original information architecture. Custom workflows built by someone who has long since left. Web parts written against legacy APIs that will not function in modern SharePoint. Document libraries that quietly serve as informal records repositories.

The July 2026 deadline is one of the few moments when leadership across IT, compliance, and business units is genuinely paying attention to SharePoint. That attention is an opportunity. A structured migration can reduce content volume, retire dormant sites, tighten permissions, formalize records management, and modernize the user experience while resolving the support problem. Treating the project as purely technical work means losing that opportunity.

The Pre-Migration Assessment

Before any decision about target platforms, every organization should have a clear, current picture of what it is actually running. The following inventory should be the first deliverable of any SharePoint migration program.

Environment and infrastructure

• Confirmed SharePoint version, cumulative update level, and patch status of each farm

• Server inventory (web front-ends, application servers, database servers) and their underlying operating systems and SQL Server versions

• Authentication setup, including any AD FS, claims-based, or hybrid identity configurations

• Backup, disaster recovery, and high-availability arrangements

Content and structure

• Number and size of site collections, sites, and subsites

• Content database sizes and growth trends

• List, library, and file counts, including unusually large or orphaned collections

• Files near or above SharePoint Online thresholds (file size, path length, list view limits)

• Stale, redundant, or trivial content that does not need to migrate

Permissions and governance

• Permission inheritance patterns and broken inheritance points

• External sharing, anonymous links, and guest access configurations

• Site ownership data and dormant ownership chains

• Existing retention, records, and information management policies

Customizations and integrations

• Full-trust solutions, sandbox solutions, and SharePoint Framework (SPFx) components

• SharePoint Designer workflows, including any 2010-platform workflows

• InfoPath forms and their dependencies

• Custom master pages, page layouts, and branding

• Third-party add-ins and ISV products

• Integrations with line-of-business systems, ERP, CRM, identity providers, and document management tools

This is the kind of assessment that benefits from external review, particularly in environments where institutional knowledge has eroded over multiple administrator handoffs. Through our SharePoint consulting services, we work with enterprise teams to run structured discovery of SharePoint estates of this kind, mapping not only the technical footprint but also the workflows, integrations, and content classes that need decisions before any migration tool is invoked.

Choosing the Right Target Environment

Once the assessment is complete, the next question is where the workloads should land. The answer is rarely a single destination. Most enterprises end up with a primary target and a secondary path for specific workloads. Understanding the core trade-offs between SharePoint Online and on-premises deployment is the right starting point before evaluating the options in the table below.

A useful framing question for leadership: if the organization were starting SharePoint today, with no legacy investment, where would it host the platform? The answer to that question, balanced against current contractual, regulatory, and architectural realities, usually points to the right target. For organizations leaning toward the cloud path, our Microsoft 365 services cover the full migration, deployment, and ongoing management journey beyond SharePoint alone.

The Enterprise Migration Checklist

The following checklist is structured around the phases most enterprise SharePoint migrations move through. It is written at a level an IT director or CIO can use to track progress, with the underlying technical work flowing from each item. For a deeper walkthrough of each stage, see our step-by-step SharePoint migration guide.

Phase 1: Discover and assess

• Confirm current SharePoint version and patch level across every farm

• Complete the inventory described in the previous section

• Identify business-critical workloads and their owners

• Map integrations with line-of-business systems

• Catalogue customizations, workflows, and forms

Phase 2: Decide the destination

• Define migration goals beyond compliance with the deadline (cost, modernization, security posture, user experience)

• Evaluate SharePoint Online, Subscription Edition, hybrid, and phased options against those goals

• Document data residency, regulatory, and licensing constraints

• Secure executive sponsorship and a clear budget envelope

Phase 3: Clean up and prepare

• Identify content to migrate, archive, or retire

• Resolve orphaned sites and dormant ownership

• Rationalize permissions and remove unnecessary external sharing

• Decide which customizations to rebuild, retire, or replace with native modern equivalents

• Replace InfoPath forms and SharePoint Designer workflows with modern alternatives such as Power Apps and Power Automate

• Update the information architecture, metadata model, and retention policies

Phase 4: Pilot

• Select a representative pilot group covering different content types, customizations, and user personas

• Run the migration end-to-end on the pilot scope

• Validate permissions, metadata, workflows, and integrations against pre-migration baselines

• Capture lessons learned and adjust runbooks before scaling

Phase 5: Migrate in waves

• Sequence sites and content by business criticality, risk, and complexity

• Communicate cutover windows clearly and in advance to affected users

• Maintain a rollback plan for each wave

• Track migration progress, errors, and remediation in a single source of truth

Phase 6: Validate and optimize

• Verify content integrity, permissions, and workflow behavior in the new environment

• Confirm search, sharing, and external access work as expected

• Decommission the legacy environment on a planned schedule, not by neglect

• Refresh governance, training, and adoption materials based on what users actually experience after migration

Handling Custom Code, InfoPath, and Legacy Workflows

The harder parts of most SharePoint migrations are not the documents and lists. They are the custom solutions that have quietly become business-critical over the years.

InfoPath forms are a clear example. InfoPath Forms Services reaches end of support on July 14, 2026, aligning with SharePoint Server 2016 and 2019. Forms that drive procurement requests, HR processes, or compliance attestations need a replacement plan, typically in Power Apps, with the underlying logic moved to Power Automate. Our apps development and automation team handles exactly this kind of rebuild, designing Power Apps and Power Automate solutions that replicate and often improve on what InfoPath delivered.

SharePoint Designer workflows, especially 2010-platform workflows, are in a similar position. Power Automate is the strategic destination for most of these. A few complex workflows may justify rebuilding in Azure Logic Apps or, in rare cases, custom code. The point is to make the rebuild decisions before migration starts, not after a workflow fails to run in the new environment.

Full-trust code, sandbox solutions, and older add-ins require an honest review. In many cases, the original business need can now be met with out-of-the-box modern SharePoint, a Power Platform solution, or an SPFx component. Carrying legacy code forward without that review reproduces the same maintenance burden in a new environment.

Governance, Information Architecture, and Adoption

Technical migration is only one part of the work. The other part is making sure the new environment is one users actually want to use.

This is where information architecture decisions made before the move pay off for years. A clear site taxonomy, consistent metadata, defined retention policies, and a thoughtful hub-and-spoke structure reduce sprawl and make content findable. Without those decisions, modern SharePoint can become as cluttered as the environment it replaces.

Change management deserves equivalent attention. Communications should reach users well before cutover dates, not on the morning of the change. Training should cover both the new interface and the new ways of working, for example, the shift from email attachments and shared drives to cloud collaboration on the same file. Champions within business units carry adoption further than any single training session.

When to Bring in Outside Support

Smaller migrations with limited customization and clean content can often be managed by internal teams using Microsoft’s SharePoint Migration Tool and standard runbooks. Larger and more complex environments usually benefit from outside help, particularly when:

• The estate spans multiple farms, geographies, or business units

• Internal SharePoint expertise has eroded and current administrators inherited the environment

• The migration is bundled with broader Microsoft 365 modernization, security uplift, or compliance work

• Custom workflows, InfoPath forms, or third-party integrations need to be redesigned, not just moved

• The organization wants an independent assessment before committing to a target environment

We support enterprise teams across these scenarios, from discovery and migration readiness assessments through information architecture design, pilot execution, phased migration delivery, and post-migration optimization. See how we handled this end-to-end in our SharePoint migrations and ongoing support case study. The aim of every engagement is less about running migration tooling and more about helping leadership make the right structural decisions before the tooling runs.

The Deadline as a Decision Point

July 14, 2026, is a deadline, but it is more useful to treat it as a decision point. Organizations that begin work now have time to make considered choices about target environments, clean up the content they have accumulated, redesign the workflows that no longer serve them, and build a SharePoint footprint that is easier to govern for the next decade.

Organizations that wait will face the same end-of-support reality, but with fewer options, less time to clean up, and more pressure to lift and shift whatever exists. The work is the same. The conditions under which it gets done are not. The remaining months are the difference between a migration that resolves the technical debt and one that simply moves it.