Your on-prem SharePoint just hit end of life.

If you run SharePoint Server 2016 or 2019, the clock has run out. Microsoft ended extended support for both products on 14 July 2026. That does not make a server stop, but it does end the normal stream of security updates and supported fixes. You have to choose a supported path.

The question is move to what? Cloud migration is a valid answer for many organisations. It is not the only answer, and it changes more than the location of the files. Before treating the default as the decision, separate the patching problem from the control problem.

Why you have to move

• The normal patch stream is over. Microsoft’s lifecycle pages record end of support for SharePoint Server 2016 and SharePoint Server 2019 on 14 July 2026.
• Unsupported software becomes a governance issue. Auditors, customers and cyber-insurers may ask whether critical systems are supported and how known vulnerabilities are handled.
• Waiting narrows your options. A planned migration can preserve permissions, test retrieval and provide rollback. An incident-driven migration rarely offers the same calm.

The default path—& what changes with it

The frictionless route is the vendor’s managed cloud. It is supported, removes much of the local patching burden and may be exactly right. But you are not merely relocating files. You are changing the operating boundary: who administers the underlying service, what contract governs it, what external services process the content and which dependencies can interrupt access.

Residency is not the whole control story. Major providers make regional residency commitments. They also document limited circumstances in which data may move or be accessed across the boundary for security, support or legal obligations. Microsoft, for example, publishes both its EU Data Boundary commitments and a separate account of continuing transfers. The right question is not “cloud or no cloud?” It is whether the provider’s documented boundary matches your legal and operational requirements.

The commercial model changes. Subscription pricing can be predictable and worthwhile, but it converts an owned asset into an ongoing service dependency. AI features may add licences or consumption charges. Model the actual user count, retention, egress, support and AI workload rather than comparing one server invoice with one seat price.

The AI boundary changes too. If a hosted assistant indexes or reasons over sensitive documents, the organisation should know where that processing occurs, which logs or prompts are retained, who administers the service and how the feature can change. Provider dependence is not inherently bad. It is a dependency to choose deliberately.

The third door: modernise locally

A different path is to move governed document collections onto current infrastructure you own and operate, then run retrieval and AI against them locally. This is not a museum copy of the old intranet, and it should not be sold as a feature-for-feature SharePoint clone. It is a clean, current document layer—searchable, permission-aware and private—with the processing boundary inside your organisation.

That path can sit alongside a supported collaboration platform. The useful distinction is between systems of collaboration and the controlled corpus: the documents and intelligence that must remain under local authority do not necessarily need the same operating model as every calendar, chat and team site.

What you can gain

A plain answer about control. If the data, encryption keys, model weights and administration stay within the deployment boundary, you can give an assessor a direct account of who can reach or change the system.

A smaller exposed surface—if it is operated well. A modern local appliance with default-deny networking, controlled updates and no unapproved remote-management route can reduce exposed services. Local does not automatically mean secure; it makes the boundary yours to harden and attest.

Local AI on the controlled corpus. Search, summarisation, extraction and question-answering can occur without sending the source documents to a hosted inference endpoint. That is useful for contracts, health records, regulated files and any corpus whose processing location matters.

Costs tied to capacity rather than every interaction. Owned infrastructure shifts more cost to acquisition, power and operations. Depending on utilisation, user count and support needs, that can be more predictable than per-seat or per-token pricing—but the break-even point must be calculated for the actual workload.

Evidence instead of a diagram. A governed system should identify components, models, update authority, external routes and configuration drift. When compliance asks what is inside the boundary, the answer should be a signed report, not a promise.

What moving actually looks like

Use supported export and migration interfaces. The content belongs to the organisation, but the extraction method still matters. Inventory sites, libraries, workflows, customisations and retention rules before choosing tooling.

Treat permissions as the critical dataset. Copying documents is usually simpler than faithfully carrying inherited permissions, groups and item-level exceptions. Test one representative library and reconcile access before scaling the migration.

Begin with a read-and-search mirror. A governed, read-only copy lets users and security teams verify retrieval, metadata and permissions while the source remains in place. It creates evidence before commitment.

Move active processes deliberately. Retire workflows one at a time. Some belong on a supported collaboration platform; others may be simpler as local document processes. Decommission the legacy server only when it is no longer an unrecorded dependency.

The bottom line

End of support forces a decision, not a predetermined destination. Managed cloud solves real operational problems. A supported on-prem platform preserves a familiar operating model. A governed local document-and-AI layer can preserve direct control over the corpus and the intelligence that works on it.

Choose the boundary first. Then choose the product.