SharePoint implementation in 2026: what actually matters now

Why I rewrote this guide

The first edition of this guide was a 32-page consulting document. It treated SharePoint implementation as an intranet project: architecture diagrams and adoption plans. That framing is now incomplete. SharePoint is the corpus that Microsoft 365 Copilot and your agents read. A messy implementation used to mean an ugly intranet. It now means an AI assistant that confidently quotes a draft from 2019 or exposes a salary file someone overshared six years ago.

We have shipped 200+ production deployments since 2014, for clients including Bayer, Takeda, Adidas and Rockwell Automation. The pattern across all of them is the same: the implementation decisions in this guide are cheap to get right at the start and expensive to fix later. This page replaces the PDF. Everything useful from it is here, updated for June 2026.

The deadline: July 14, 2026

SharePoint Server 2016 and SharePoint Server 2019 reach the end of extended support on July 14, 2026. After that date there are no security patches and no Microsoft support incidents. Unlike Windows Server, Microsoft has not announced a paid Extended Security Update program for these versions. If you run either one, the clock is real.

You have three honest options, each with a cost you should price in before choosing.

Architecture: flat, hub-connected, no subsites

Every site is its own site collection. Hubs provide the hierarchy. That has been the right model for years and nothing in 2026 changes it. Subsites couple permissions and lifecycle to a parent you will eventually want to restructure. Do not create them, and unwind them when you migrate.

Keep the hub structure shallow. One layer of hubs for major functions, sites attached beneath them. If you find yourself wanting hubs of hubs more than one level deep, your information architecture is modelling the org chart instead of how people actually look for content. Model the work, not the hierarchy.

Permissions: the part that breaks Copilot

Copilot does not widen access. It respects permissions exactly. The problem is that most tenants have years of accumulated oversharing that nobody noticed because nobody searched for it. An AI assistant searches for it on every prompt. The week Copilot goes live is the week your permission debt becomes visible to every employee.

The repeat offenders I find in almost every tenant:

1. Sites or libraries shared with "Everyone except external users", usually from a migration years ago.
2. Default sharing links set to "People in your organization", which silently grants tenant-wide access every time someone shares a file.
3. Anyone links that never expire, created before anyone set an expiry policy.
4. Broken permission inheritance at item level, where a folder was shared once and the grant outlived the project.
5. Orphaned sites whose only owner left the company, so nobody can review or revoke anything.

Two platform facts make this cheaper to fix than most teams expect. First, if your organization has even one Microsoft 365 Copilot license assigned, your SharePoint admins get SharePoint Advanced Management features included. That covers data access governance reports, site access reviews, inactive site policies and restricted access controls. Check whether you already have it before buying anything. Second, Restricted SharePoint Search exists as a containment measure: admins can limit organization-wide search and Copilot to a curated allowed list of up to 100 sites. It is off by default.

Migration: the steps that actually matter

Whether you are leaving a 2016 farm or consolidating tenants, the sequence below is the one I use. The ordering is deliberate: every step reduces the cost of the next one.

1. Inventory first. Pull site inventory and last-activity reports from the admin center before anyone debates scope. People argue with opinions. They do not argue with a usage report.
2. Cull before you copy. Anything untouched in years gets archived or deleted, with a named owner signing off per site. Migrated junk costs money twice: once to move, forever to confuse search and Copilot.
3. Retire customizations that will not port. Classic workflows, farm solutions, InfoPath forms and custom web parts need a rebuild decision, not a lift-and-shift attempt. Rebuild the few that earn it in Power Automate or Power Apps. Kill the rest.
4. Pilot one real department, not an IT sandbox. You want real permissions and real complaints before you scale the pattern.
5. Map permissions explicitly. Decide what "Everyone" groups and broken inheritance become at the destination. A migration that copies permission debt has merely relocated the problem.
6. Verify search and Copilot results against the pilot content before declaring success. Ask ten real questions a team member would ask. Wrong or stale answers are an implementation defect, treat them like one.
7. Set a decommission date for the source and publish it. Sources without a shutdown date live forever, and people keep saving files to them.

Governance people will actually follow

Governance fails when it is a 40-page policy document. It works when it is three or four automated defaults that nobody has to remember. Set these once:

1. Provisioning through a request flow, not the raw admin center. Capture the owner and the sensitivity at creation time. A simple form plus an approval is enough.
2. Two named owners per site, enforced. When one leaves, the other gets a renewal task. Ownerless sites are where permission debt breeds.
3. An inactivity policy. Sites with no activity for a defined period get flagged to their owners, then archived. Decide the period once and automate it.
4. Default sharing set to "Specific people" with expiry on external links. Make the safe path the lazy path.

What SharePoint is bad at

Part of implementing well is refusing the wrong workloads. SharePoint lists are not a transactional database: high-volume writes and relational queries belong in a real database with SharePoint as the front door at most. Large lists degrade without indexed columns and disciplined views. Heavy media production workflows outgrow document libraries quickly. And cross-tenant collaboration still carries enough friction that you should pilot it with one partner before promising it to the business.

When a team asks for one of these, the answer is not a more clever SharePoint workaround. It is a small purpose-built tool that reads and writes SharePoint where that helps. We build a lot of those.

Your first 30 days

1. Week 1: pull the inventory and the data access reports. Find every site shared with "Everyone". Confirm whether a Copilot license already unlocks SharePoint Advanced Management in your tenant.
2. Week 2: fix the defaults. Sharing links to "Specific people", expiry on external links, provisioning behind a request form. If Copilot is imminent and the tenant is messy, enable Restricted SharePoint Search as a temporary gate.
3. Week 3: run access reviews on the ten most sensitive sites. Assign second owners everywhere one is missing.
4. Week 4: if you are on SharePoint Server 2016 or 2019, get the migration plan signed with named owners, milestone dates and a source shutdown date. Support ends July 14, 2026. Plan against that date, not against the next budget cycle.

What we would build

Most of this guide is work you can do yourselves. Where teams bring us in is the connective tissue: a permission-review workflow that opens tickets instead of spreadsheets, a provisioning flow with the governance defaults baked in, a migration triage agent that reads the inventory and drafts the cull list, or a Copilot readiness check that asks the ten real questions and grades the answers.

Our first build is always the same shape: one workflow, $10,000, two weeks, built in your environment. You sign the acceptance criteria before we start and pay only after every criterion passes. Larger programs run as two-week sprints, each with its own signed criteria.