Support for SharePoint Server 2016 and 2019 ended in July 2026, which changes the position for organizations still running either version. Because Microsoft offers no extended security updates for those farms, vulnerabilities discovered after the deadline stay open. Continuing either version now means operating an unsupported SharePoint platform, which is a different decision from simply choosing to remain on-premises.
That does not make SharePoint Online the only path forward. SharePoint Server Subscription Edition remains Microsoft’s supported on-premises option. IT leaders therefore face a broader question than whether to migrate, since they need to determine which SharePoint operating model makes sense for the organization going forward.
For some organizations, that will mean SharePoint Online. Others may have requirements that justify Subscription Edition or a hybrid environment.
In this article, we look at how to test whether those requirements still hold, what changes when Microsoft runs the platform, and what an existing farm tends to carry into the cloud.
Which Requirements Still Justify Keeping SharePoint On-Premises?
Start by identifying why SharePoint is still on-premises. For some organizations that approach us for SharePoint consulting, it is a deliberate architectural decision. For others, the environment has simply remained in place because there has been no compelling reason to change it.
If there is a specific requirement, define it precisely. Data residency, for example, once meant running separate SharePoint infrastructure in every country with a local storage obligation. Multi-Geo, a paid add-on for eligible enterprise plans, now lets a single Microsoft 365 tenant store SharePoint content in the supported geographies for each part of the business needs.
Sovereignty and regulatory obligations deserve the same scrutiny as integrations and control requirements. Evaluate each against what SharePoint Online can support, rather than treating it as a general reason to remain on premises.
If Microsoft 365 can meet those requirements, SharePoint Online becomes a viable target. Where Microsoft 365 falls short, SharePoint Server Subscription Edition provides a supported path for keeping SharePoint on-premises. A hybrid model fits when some workloads can move to Microsoft 365 while others need to stay within SharePoint Server.
The objective is to find the operating model that satisfies the organization’s actual requirements with the least unnecessary complexity. Where SharePoint Online meets that test, the practical question becomes what the IT team stops managing once Microsoft runs the platform and what it still owns.
What Changes When You Move from SharePoint Server to SharePoint Online
Moving to SharePoint Online changes the boundary between what Microsoft manages and what your IT team manages. With SharePoint Server, the organization maintains the hardware and applies the patches. Upgrades also have to be timed around Microsoft’s support deadlines, which is how an organization that adopted SharePoint Server 2013 ends up on a version that no longer receives security updates.
SharePoint Online moves responsibility for the underlying service infrastructure to Microsoft. Capacity planning changes, since an on-premises farm that starts with 10 TB will eventually fill up and force another hardware expansion. For many eligible plans, storage starts at 1 TB per organization plus 10 GB per eligible license, which gives a 50-user organization roughly 1.5 TB before it buys more.
The same boundary runs through Teams, which stores channel files in SharePoint Online and chat files in OneDrive. An organization using Teams while keeping SharePoint on-premises therefore manages content across two separate environments.
None of this removes the need for SharePoint administration. Responsibility shifts from running servers to governing the information inside the service, including site architecture, permissions and the policies that decide who owns each site. That information layer carries more weight now that organizations are introducing Microsoft 365 Copilot, because AI value depends partly on whether organizational content is accessible and properly governed.
Copilot Has Changed the SharePoint Migration Business Case
The business case for SharePoint Online is no longer limited to reducing the infrastructure required to operate SharePoint. Because Copilot does not run natively on SharePoint Server, content that remains on-premises sits outside the environment where Microsoft 365 AI experiences are built unless it is indexed through the SharePoint Server Copilot connector, which adds another component to deploy and maintain.
SharePoint is one of the main sources Copilot draws on, since Teams channel files are stored in SharePoint sites and OneDrive runs on the same platform. Copilot respects the access users already have and answers from whatever each user is authorized to see, which makes the quality of the underlying SharePoint environment far more consequential.
For years, oversharing barely registered as a concern because the data was internal. Once employees could retrieve information conversationally, many started seeing content they were never supposed to see. Oversharing has since become a roadblock organizations must clear before Copilot adoption can proceed.
Enabling Copilot and being ready for Copilot are therefore separate milestones. Moving content into Microsoft 365 supports AI adoption, although migration alone does not make the information environment ready. Treat permissions and information governance as part of the migration decision rather than a cleanup exercise after Copilot is deployed.
Why a Lift-and-Shift Migration Creates Problems Later
Migration falls short on its own because a move that transfers every file successfully can still carry the old farm’s problems into Microsoft 365. Older SharePoint farms often contain subsites nested several levels deep, each carrying permissions and structures built around requirements the business no longer has. Moving those structures without reconsidering them changes the infrastructure while leaving the information architecture unchanged.
The problem compounds during acquisitions. In one SharePoint migration scenario, one organization acquired four or five companies and handed the migrations to people who were not SharePoint specialists. Each acquired business was lifted into the existing structure as a subsite under the root site, which turned 50 to 100 sites per acquisition into 50 to 100 subsites.
Managing that root site became a mess, from usage reporting to permissions. Every acquisition after the second or third made it worse, because each new business deepened an architecture never designed for repeated integration.
Modern SharePoint avoids that pattern with a flatter architecture, where independent sites are associated through hubs. A finance function that once ran Finance Internal, Finance Clients and Finance Vendors as subsites can run each as an independent site joined to a Finance hub. The hub supplies shared navigation and a common theme, while each site keeps its own permissions and shorter file paths.
A migration succeeds when the organization leaves its information architecture and governance debt behind the old farm. Organizations that expect to acquire, divest or consolidate again should also document how they assess environments and map sites and permissions. That record hence turns the next integration into a repeatable exercise.
What Should You Assess Before Planning the Migration?
Leaving that debt behind starts with knowing exactly what the current environment contains. An assessment that stops at content volume misses where much of the effort lies: customizations, permissions and identity.
1) Inventory the Environment and Decide What Moves
Count every farm, site collection and subsite, then record how large each one has grown. Last-modified dates show which sites people still use and which business processes still depend on SharePoint.
Because a file carrying 1,000 or more versions rarely needs all of them in SharePoint Online, agree with business owners how much version history each library should keep. Inactive content can go to a third-party backup service or into Microsoft 365 Archive once it reaches SharePoint Online. Duplicate files, libraries and sites should stay behind entirely.
2) Identify Customizations That Will Not Transfer
Several customizations that organizations had within on-premises will not run in SharePoint Online. InfoPath forms and SharePoint 2010 and 2013 workflows have been retired, farm-level solutions and server-side event receivers were never supported, and remote event receivers stop working on July 1, 2027. Each one needs a decision: rebuild it with Power Apps, Power Automate, SharePoint Framework or webhooks, redesign the underlying process or retire it altogether. Custom integrations that connect SharePoint to other systems need the same decision.
3) Review Permissions and Identities Separately from Content
Broken inheritance can sit at almost any level of an on-premises farm, from the site collection down to individual files. Migration tools can carry unique permissions across at every level, down to individual folders and files, but SharePoint Online supports only 50,000 unique permission scopes per list or library and recommends staying under 5,000. That limit forces a decision about which permission levels to carry across. Permission reports expose the excessive access and unclear ownership that Copilot would otherwise surface, and they do so before the target structure is decided.
Permissions only land correctly when every user already exists in the target environment. In a hybrid environment, confirm that Entra Connect Sync is healthy. Organizations moving from on-premises accounts to cloud identities should create those accounts in advance and map each source account to its cloud counterpart, typically through a CSV file.
4) Find the Technical Blockers
Deeply nested folders inside nested subsites often block content because SharePoint Online limits the length of a file’s full path. Files above the 250 GB maximum need to be split or reduced. Item-level reports should surface both problems before the migration tooling does.
5) Classify Workloads and Establish Scope
Use those findings to classify workloads by migration complexity. A large document library with straightforward permissions may be easier to migrate than a smaller site that depends on custom workflows. Those classifications give IT a defensible basis for estimating scope and remediation effort.
Define the Target SharePoint Environment Before You Migrate
The assessment describes the environment the organization is leaving, and those scope estimates hold only if the target environment is defined as well. Before moving content, decide how SharePoint Online should be structured and managed after the migration. That design rests on several decisions; all made before the first workload moves.
- Start with the site and hub architecture. Determine which business functions need separate sites and which hubs should associate them, without recreating legacy hierarchies.
- Give every site an accountable owner who decides who gets access and whether the site still serves a business purpose. A site nobody owns is where oversharing goes unnoticed until Copilot surfaces it.
- Define the permissions model before mapping users. Existing permissions should inform the migration without automatically becoming the permissions used in SharePoint Online.
- Decide who can create new sites after migration and what happens to content once it goes inactive. Each site also needs a review point where its owner confirms whether it should stay.
- Configure Multi-Geo before migration if data residency applies, so each workload lands in the correct geography from the start.
- Build Copilot’s access and governance requirements into the design now, since treating readiness as a later project means revisiting permissions already mapped.
With that model agreed, the migration team maps each workload to a known end state instead of deciding where content belongs while it moves. The remaining question is which workloads should be moved first.
Plan the Migration Around Business Risk, Not Just Data Volume
Group workloads by business importance and migration complexity, not data volume. A small HR site hosting the onboarding form every new hire depends on can carry more migration risk than a multi-terabyte archive of closed project files.
Start with a representative pilot that exercises the hub architecture and permissions model the full migration depends on. Users in the pilot should find their files in the correct sites and see only what their permissions allow. The business processes on those sites also need to keep working in SharePoint Online.
Resolve issues before expanding the migration. Sites that need extensive remediation can run on a separate track instead of holding up straightforward migrations. Incremental passes that move the bulk of a library ahead of time leave only recently changed files for the cutover window.
Sequence business-critical workloads around acceptable disruption and user readiness, not tooling readiness. A finance site should not move during quarter-end close, no matter how clean its assessment looks.
Before You Commit, Know What the Assessment Needs to Tell You
A SharePoint migration assessment should tell decision-makers whether the proposed migration is viable before significant work begins. It should confirm whether SharePoint Online is the right target or whether specific requirements justify Subscription Edition or a hybrid model. It should also show what can move as-is and what needs remediation, redesign or retirement.
If those answers are still unclear, committing to a migration timeline or selecting tooling is premature. Waiting carries its own cost, since every month on an unsupported farm leaves newly disclosed vulnerabilities unpatched.
Conclusion
The end of support for SharePoint Server 2016 and 2019 makes the decision more urgent, but it does not make SharePoint Online the right target by default. That choice rests on the requirements your organization can verify and on the condition of the environment it would be moving.
A SharePoint migration assessment should settle both before significant work begins. It should confirm whether SharePoint Online, Subscription Edition or a hybrid model is the right target, then show what can move as-is and what needs remediation, redesign or retirement.
If those answers are still unclear, committing to a migration timeline or selecting tooling is premature. Waiting carries its own cost, however, since every month on an unsupported farm leaves newly disclosed vulnerabilities unpatched.
Find out what your SharePoint environment will take to move before you commit to a timeline. To get started, review our SharePoint migration services or schedule a SharePoint migration assessment to identify which workloads are ready to move and which need work first.
