Everything in this report happens somewhere. This chapter is about that somewhere.

The governance gaps in the previous chapter did not appear from nowhere CH 3Governance→. They accumulated in an environment that is still half-built, and the shape of that environment explains a good deal about why they persist. It's tempting to treat the estate as settled background—the thing the interesting problems happen on top of. The data says otherwise. The Microsoft 365 estate most teams are governing in 2026 is still partly on-premises, still accumulating content faster than anyone retires it, and broader in composition than the file-and-mail picture most planning documents assume.

An estate like that changes for one of two reasons. Someone inside decides to change it, or someone outside sets a date. This year we got a good look at the second kind.

Microsoft ended support for SharePoint 2016 and 2019 in July 2026, which handed the industry something it rarely gets: a hard date attached to a piece of infrastructure work. Teams responded to it. What they didn't all do was respond by moving to Microsoft 365. Leaving unsupported software and arriving in the cloud turn out to be two different projects, and a good part of this chapter is about the space between them.

Nothing else in the estate came with a date. How much employees can create without asking, what happens to a workspace after the project that needed it ends, how much storage accumulates along the way: none of it generates a support notice, and none of it fails visibly enough to force a decision. That's the asymmetry worth carrying through the rest of this chapter. The estate got exactly one deadline, and it only ever covered one part of it.

Fully cloud, fully on-premises, and the 68% in between

Hybrid can be a real architecture choice, especially where it's set up for hybrid search and taxonomy. But sometimes it's just what ends up happening when an organization starts working in the cloud while holding onto its on-premises environment. Some of these teams are actively working toward being 100% in the cloud. Others have decided to keep maintaining two environments.

Let's start with the question everyone assumes is settled.

Cloud-complete has moved from 22% to 28% year on year—real progress, and slower than the industry narrative suggests. At that rate the majority of organizations will be running hybrid estates for years, not months.

Of the roughly seven in ten that still run on-premises infrastructure, half describe what's left as a small amount. The rest split their data evenly or have more on-premises. Hybrid covers all of those, which is part of why the word doesn't tell you much on its own.

What a split estate costs you

The number matters because of what sits downstream of it. A hybrid estate means two permission models, two audit trails, two backup and retention regimes, and two places a piece of sensitive content can live. It also sets a ceiling on AI: Copilot reaches cloud content CH 1Confidence ≠ control→. On-premises content is outside native Microsoft 365 grounding unless it's brought into scope through a configured connector. For many organizations that means what's on a file server is invisible to Copilot—sometimes a feature, sometimes a findability problem, and teams rarely have a clear view of which.

The self-perception gap is the interesting part. Most of these organizations don't describe themselves as hybrid. They describe themselves as cloud organizations with some legacy left over. That framing is comfortable, and it quietly removes the leftover from the governance plan.

Cloud-complete respondents self-reported more governance problems

A file share doesn't generate an oversharing alert. Neither does a SharePoint farm, and neither shows up in the Microsoft 365 unified audit log. Which is worth knowing before looking at how governance incidents break down by cloud footprint, because on paper the result reads backwards.

Both charts are percentages of all 943 respondents in each band, so the two gradients are directly comparable.

Sort the sample by how much of the estate sits in the cloud. The teams with the most data in the cloud report the most incidents. They can also see the most of their own tenant. Two gradients, same direction, same four groups.

There are two readings.

The first is surface area. A fully cloud estate is a bigger, more connected, more shareable thing—more sharing links, more guests, more cross-tenant collaboration, more of everything that produces the incidents on the governance chapter's list CH 3Governance→.

The second is detection, and it's the pattern that recurs throughout both studies. Cloud-complete organizations can see more. The file share we opened this section with may be producing exactly the same problems, unobserved and uncounted.

Two of the four move with the footprint

Two of the four types move with the footprint and two don't. Oversharing runs 32% down to 13%, stale access 44% to 28%. Audit gaps and shadow adoption sit flat across every band.

Which is the tell. The two that move are the two a connected tenant produces more of. The other two happen everywhere.

So how much of it is just better eyesight?

Most of it is real.

Hold visibility steady. Compare only the 435 teams who can see exactly what their agents reach, and the gap narrows from 19 points to 11. Better eyesight explains about two fifths of it. The rest is surface area. A cloud-complete estate isn't just better at spotting problems. It has more of them.

Which settles the migration question

Completing a cloud migration does not reduce your governance workload. It changes it, and usually enlarges it. Teams that treat migration as the project and governance as the phase that follows have the sequence backwards.

So what does help?

Which raises the more useful question. If where your data sits works against you, what works for you?

One answer turns up in every group. Teams who watch their tenant, with monitoring and automated alerts, had fewer incidents than everyone else. Nine points fewer, whether they are fully in the cloud or barely started.

And they are not simply missing things. They can see about twice as much of their estate as everyone else can. Looking harder normally turns up more problems. It turned up fewer.

What the estate is actually made of

The composition question is worth asking separately from the location question, because assumptions about it are usually a decade out of date. When organizations move a tenant, here's what has to come with it.

Power Platform tops the list, ahead of SharePoint, Teams, and Exchange. That ordering should reset a few assumptions. The mental model of a Microsoft 365 estate as mail plus documents is obsolete. What teams are actually governing includes a substantial layer of apps, flows, and automations that were built by people outside IT, hold their own permissions and connections, and are now the most commonly in-scope workload when an estate changes hands. It's also the layer least likely to have an owner who still works there.

The migration mechanics are covered in their own chapter CH 6Migration→. The point here is what the list says about the surface area: the estate is broader than the org chart of the people who think they own it.

The SharePoint end-of-support moment moved almost everyone

Microsoft ended support for SharePoint 2016 and 2019 on July 14, 2026. Nothing switched off. It wasn't a power cut. A SharePoint 2019 environment runs today exactly as it did in 2025, except now there are no more security updates, no more bug fixes, and no more support calls.

Support ended on a Tuesday. Only 21% still had SharePoint 2016 or 2019 running on the Wednesday.

Versus last year, comparing like with like: in 2025, 66% of organizations were still actively running SharePoint 2016 or 2019, and 29% had not yet formed a firm migration plan. Today, roughly 21% still have those versions in play (17% mid-migration, 4% with no active plan), and the share with no plan at all has fallen to under 4%. That second pairing is the cleanest measure of what changed: nearly a third of organizations had no plan a year ago; now almost everyone does.

That's a twenty-five point move in twelve months, and it's worth being honest about what caused it. Not advocacy. Not architectural conviction. A date. Microsoft's July 2026 end-of-support deadline achieved in twelve months what years of migration guidance did not.

There's a lesson in that worth carrying into every other section of this report. The governance work in the previous chapter and the AI visibility work in chapter 1 have no deadline attached. Nobody sends an end-of-support notice for permission sprawl. Teams that want that work to happen have to manufacture the forcing function themselves, because the environment will not supply one CH 7The operating model→.

The third of the market that chose to stay

One number in that chart deserves more attention than it usually gets. 31% did not move to the cloud. They moved to SharePoint Server Subscription Edition—which is to say they deliberately chose a supported on-premises future.

That is not procrastination, it's a strategy, and it's nearly as common as completing the cloud migration. For those organizations the driver is usually a compliance or sovereignty requirement they cannot satisfy in a shared cloud, and the decision is often correct CH 5Compliance→. But it has a governance consequence that tends to go unplanned: they've committed to running two governance models indefinitely rather than transitionally. Everything in the governance chapter about continuous monitoring and lifecycle now has to work in two places, permanently, and native cloud tooling covers only one of them.

The teams who moved to Subscription Edition are more hybrid than average, not more on-premises.

43% have only a small amount left on-premises, seven points above the sample. 28% run roughly half and half. Just 8% are on-premises-heavy. And then there's the whopping 21% who say they're already fully in the cloud, while also saying they migrated their SharePoint 2016/2019 to Subscription Edition.

We had trouble squaring that. There are a few possible explanations. One is that you can run Subscription Edition on cloud infrastructure, so these teams could have migrated to it and then run it on IaaS. We didn't ask, but based on Microsoft's documentation that path doesn't look popular enough to account for one in five of the Subscription Edition migrators. It's also technically possible they migrated to Subscription Edition and then to the cloud, but then why not say they moved from SharePoint 2016/2019 to the cloud, which was one of the options?

The likelier reading is the one Richard Harbridge described earlier in this chapter. The server didn't stop existing. IT leaders stopped counting it. For most of this group Subscription Edition isn't the estate. It's one workload they've decided to keep while everything else runs in the cloud.

Two governance models, and it shows

Of the three SharePoint paths, this one had the most trouble: 87% had at least one governance incident in the past 12 months, against 72% of the teams who moved SharePoint to the cloud. Some of that is who's looking. Not all of it.

Compare only teams who monitor the same way and the gap narrows from 15 points to 8. It doesn't close. Eight points separate two groups finding problems the same way, and the difference between them is that one of them is doing it in two places.

What held the stragglers back

21% of organizations still had SharePoint 2016 or 2019 in play when support ended. We asked them the primary reason they hadn't finished, and the blockers are not primarily financial.

Complexity and capacity together account for nearly two thirds. Budget is a distant third. The teams still on legacy are not underfunded so much as under-resourced against a genuinely hard technical problem, usually one involving customizations somebody built a decade ago and nobody has owned since.

Prioritization by leadership came in last, which is worth holding against one of the data points from the governance chapter CH 3Governance→. Asked what would most improve their Microsoft 365 governance and security, executive buy-in was the second-most selected answer. Governance work stalls for want of a mandate. Migration work has the mandate and stalls anyway.

Self-service and workspace lifecycle: how the estate grows

Somebody decides they need a team or a site, and it exists, with a name, an owner, a purpose, and a line in a log. When the project ends, nothing corresponding happens. No request arrives, nobody signs anything, and the workspace carries on holding whatever it held. Every control in the governance chapter still applies to it CH 3Governance→.

What the three self-service postures get you

How much can people do without asking IT? Less than you might expect.

Only one in ten organizations gives employees broad autonomy in Microsoft 365. Nearly half route workspace creation through IT entirely. This is usually presented as a governance strength, and in one sense it is: fewer uncontrolled workspaces, fewer orphaned Teams, a cleaner tenant. The standard counter-argument is that tight control simply relocates the demand, pushing people toward personal drives, unmanaged SaaS, and AI tools nobody approved.

We tested that. It isn't what the data shows.

Shadow IT or shadow AI, by how much employees can do without IT

The sample rate is 25%. The full spread across all three postures is 2 points.

Locking it down doesn't help. Opening it up doesn't hurt. A quarter of organizations hit shadow IT either way, and the three postures land within two points of each other. Guided self-service is marginally the tidiest, for what it's worth.

That's worth reporting precisely because the opposite is so widely assumed—including by us, before we looked. Whatever produces shadow adoption is happening somewhere this setting can't reach: unmet needs, procurement speed, or tools that arrive through a browser without asking anyone's permission.

Which is useful, because it means the self-service decision can be made on its own merits, as a question about admin load and user experience, rather than as a governance gamble. The organizations doing it well tend to sit in the middle band—guided self-service with guardrails, templates, and automatic lifecycle attached—because that combination keeps the tenant tidy without making IT the bottleneck for every new project.

What happens to a workspace when nobody needs it

The most common way an inactive workspace gets dealt with is by hand, during a review somebody scheduled.

35% have something that runs on its own. The other 65% depend on a person. Every workspace that is never retired stays in the estate permanently: holding permissions, consuming storage, and remaining reachable by both people and AI.

Periodic manual cleanup works when the surface is small. It stops working when a tenant holds hundreds of workspaces, thousands of files inside each one, and permissions assigned years ago by people who have since left.

So every stale workspace nobody has reviewed is a workspace AI can still reach CH 1Confidence ≠ control→.

What automating lifecycle can tell you

Teams with automated retirement report the most AI exposure of any group. That isn't a reason to avoid automating it.

The incident column isn't a safety ranking. The automated group finds the most because it is looking hardest: 66% of them monitor AI use continuously, against 40% of the teams who review periodically and 23% of the reactive ones. Add the first two columns together and the two ends land in nearly the same place, 43% and 44%, either having had an incident or being unable to say. They got there from opposite directions. One found its problems. The other can't tell you whether it has any.

A low incident count on a manual process isn't evidence that less is happening. It's evidence that less is being found. It's a floor, and the teams who can't see their tenant have the lowest floor of anyone. What separates these groups isn't how much went wrong. It's how many of them can tell you what went wrong, and what they did about it.

Getting a workspace is hard. Losing one is nobody's job.

90% of organizations put something in the way of creating a workspace: a request queue, or a guardrail. 35% put anything in the way of one outliving its purpose. That's the mechanism connecting this chapter to every other one. The estate doesn't get messier because teams are careless. It gets messier because creation is gated and retirement is not.

They bought a better view. They didn't buy much more help.

318 organizations rate their own governance "highly automated and continuously monitored"—the top band of five. Measured against the sample, control by control, the claim only half holds.

On the controls that let a team see its estate, the top band runs 13 to 15 points ahead of the sample. On the controls that act without a person, 5 to 8. Automatic workspace retirement sits in the second group, 43% against 35%. The gap between those two clusters is the whole self-assessment: the top band has bought itself a much better view of the tenant and roughly the same amount of help.

Which means the most sophisticated governance operations in the study are still, in the majority of cases, retiring workspaces by hand.

What the estate charges you for holding it

The estate has a cost profile, and it grows on its own. Storage costs growing faster than expected affect 39% of organizations, second only to AI licensing in the cost rankings. Maintaining on-premises infrastructure alongside cloud affects 14%.

Storage growth is the purest expression of what an ungoverned estate does over time. Nobody decides to spend more on storage. Content accumulates, nothing gets retired, and the invoice reflects it. The cost chapter covers the economics in full CH 2The AI reckoning→; the point here is that this cost is a direct output of the estate's lifecycle practices, or the absence of them.

One cost is flat. The other tracks your footprint.

Storage pressure sits around 40% in every band except the most on-premises one, which comes in at 34%. That band has the least in the cloud to begin with, which is the whole explanation. Self-service posture doesn't move it either, running between 35% and 41%.

The cost of running on-premises alongside cloud runs the other way, rising as the footprint does, and it's the smaller number at every point on the chart.

Chose two environments, counts one