Last week at M365 Philly, I presented a session called “SharePoint at 25: Lessons from the Scars”. When I first envisioned that session, I thought I was giving a talk about 25 years of SharePoint decisions, but the more I worked on it, the more I saw the same shape repeating. The technology changes, the admin centers move, the buzzwords rotate, but the story keeps coming back.

A SharePoint scar usually does not come from one terrible decision. It comes from a reasonable decision that survived too long, picked up dependencies, dodged ownership, avoided cleanup, and eventually became someone else’s problem. Sometimes that someone else is the migration team. Sometimes it is compliance. Sometimes it is the poor admin who inherited the tenant. And now, because apparently we needed a flashlight with a Microsoft 365 Copilot license, sometimes it is AI. When I saw that pattern, the whole session started to look less like a list of lessons and more like an arc.

From there, the individual scars started to connect. The 25 Days of SharePoint series let me write about individual lessons from the platform: folders, metadata, permissions, homepages, search, retention, customization, migrations, Copilot, and the weird survival story of a platform everyone keeps trying to bury. The M365 Philly session pulled those lessons into one larger pattern. This post is not trying to repeat those articles. Think of it more like the scar tissue that connects them.

Ambition

Most SharePoint projects begin with a promise. This will replace the file share. This will become the single source of truth. This will make people stop emailing attachments. This will make content easier to find. This will finally give users one place to go, which is adorable because we all know there will be at least four places by the end of the quarter.

The ambition is usually fine. Sometimes it is even good. The problem starts when the ambition gets translated into the wrong work. Instead of talking about ownership, lifecycle, information architecture, search, and governance, we spend too much time making the homepage look impressive. Someone asks if we can make it “not look like SharePoint,” and before you know it, the project has become a branding exercise with a document library problem hiding underneath it.

That is why I keep saying most SharePoint homepages fail before users even scroll. The homepage was never the whole product. It was the lobby. Users were trying to get to the back office, where the actual work lives. When that back office is a pile of stale documents, vague links, broken permissions, and “Final_FINAL_v2” files, the hero banner or flexible layouts are not going to save anyone.

Shortcut

The shortcut is where the scar starts forming. Not because people are lazy or stupid, but because the project has a deadline. The intranet needs to launch before the town hall. The migration needs to finish before the contract expires. The department needs access before the meeting starts. The executive wants the page live by Friday. Someone needs the file now, not after we finish designing the responsible version of the thing.

So we say yes. We give someone Full Control. We break inheritance “just this once.” We launch with a temporary structure. We skip the metadata because users will complain. We keep the old folder structure because we do not have time to fight that battle. We promise ourselves we will fix it later, which is SharePoint for “this will become archaeology.”

This is where permissions get mistaken for governance. Permissions answer who can access something. Governance asks who should have access, for how long, under what conditions, and who owns that decision when the context changes. Those are not the same question. If the entire governance plan is “lock down the site and hope,” that is not governance. That is a control panel with anxiety.

I covered that more directly in SharePoint permissions are not governance, but the scar arc makes the pattern easier to see. The shortcut is rarely dramatic when it happens. It feels practical. It feels helpful. It feels like the fastest way to unblock the team. Then time passes, the context changes, and the shortcut becomes infrastructure.

Debt

The annoying thing about SharePoint debt is that it usually works for a while. That is what makes it dangerous. The shortcut gets the project launched. The custom form solves the immediate problem. The folder structure keeps users comfortable. The broken permission inheritance gets the right person into the right file just in time for the meeting. Nothing explodes, so everyone moves on.

Then five years pass. The original owner leaves. The department reorganizes twice. The custom thing nobody documented becomes business critical. The library has 40,000 files and three required metadata columns nobody fills out. The site still works, technically, which is the most dangerous kind of working. It works just enough to avoid fixing, but not well enough to trust.

This is why SharePoint migrations are emotional events. A migration inventory does not just show you files and sites. It shows you decisions. It shows you what nobody owned, what nobody retired, what nobody wanted to question, and what everyone quietly worked around. That is when the “lift and shift” fantasy usually dies, or at least it should.

Customization debt follows the same pattern. The clever thing we built in 2016 becomes the blocker in 2026. The custom web part nobody documented, the workflow nobody owns, the form nobody wants to rebuild, the branding decision that made sense at the time but now makes every upgrade more painful. I wrote about the hidden tax of over-customizing SharePoint, and that tax shows up here too. Every shortcut has a compound interest rate. You may not pay it today, but someone will.

And if history is any indication, that someone is probably you.

Exposure

For a long time, a lot of this was annoying but survivable. Bad search was annoying. Stale content was annoying. Oversharing was annoying. Broken permissions were annoying. Metadata nobody used was annoying. Then Copilot showed up, started grounding itself in tenant content, and suddenly the mess had a much better user interface.

Copilot did not create the governance problem. It revealed it. That is the line from the session that I think matters most, because it changes where the conversation starts. If Copilot surfaces the wrong document, the first instinct is to blame Copilot. If it summarizes stale content, people blame AI. If it finds something sensitive that a user technically had access to, everyone acts shocked, as if the permission model had not been quietly screaming into a pillow for years.

The problem is usually not that AI went rogue. The problem is that the content was stale, accessible, poorly described, badly owned, or never retired. Copilot just made the consequences easier to see and harder to ignore.

The same exposure patterns show up everywhere: overshared content, stale knowledge, permissioned theater, and orphaned ownership. None of those are new. What changed is the visibility. A document that was technically accessible to too many people for years is now easier to retrieve, summarize, and act on. An old policy that nobody retired can now sound current in an answer. A site that says “restricted” can still contain documents with permissions that tell a very different story.

That is why Copilot will expose your SharePoint mess still matters. AI did not make SharePoint governance important. SharePoint governance was already important. AI just made the consequences visible to people who previously had the luxury of ignoring them.

Clarity

This is the useful part of the scar. Once you see the pattern, you can stop treating every SharePoint problem like a brand-new disaster nobody could have predicted. The details change, but the arc does not. We have already seen folders become status fields, metadata become homework, homepages become executive theater, and cleanup projects fail because retention was never designed into the system. That is not nostalgia. That is data.

SharePoint has been teaching the same lesson for 25 years: it rewards clarity and punishes shortcuts. It rewarded clarity when we built team sites. It punished shortcuts when we over-customized portals. It rewarded clarity when we designed libraries people could actually use. It punished shortcuts when we treated permissions like governance. It is doing the same thing now with Copilot, only louder and with more executive attention.

That same pattern is also why I am watching SharePoint skills very closely. Skills are exciting, and I think they could become genuinely useful. The idea of turning repeatable AI-driven work into reusable site-level behavior makes a lot of sense. But this is also exactly how new scars form if we do not manage them carefully.

Microsoft’s current documentation says skills are stored as Markdown files in the site’s Agent Assets library, users with Edit permissions can create skills by default, and users with View permissions can use them. It also says there are no separate admin controls to turn skills on or off, although organizations can apply standard SharePoint file governance to the skill files themselves. That means the governance model is still very SharePoint: permissions, ownership, retention, auditing, and lifecycle matter because the behavior lives in the site.

That should make every SharePoint architect sit up a little straighter. Skills are not bad, but we have seen this movie before. Workflows, custom forms, scripts, page customizations, unmanaged metadata, broken inheritance, all of them started as helpful ways to get work done. Some stayed helpful. Some became undocumented behavior nobody wanted to touch because nobody knew what would break.

If we do not manage SharePoint skills intentionally, they could become the next layer of scar tissue: duplicated instructions, unclear ownership, stale workflows, site-specific AI behavior nobody reviews, and Markdown files quietly shaping how users interact with content. The answer is not to block people from creating useful things. The answer is to treat skills like governed content from day one, with ownership, naming standards, review cycles, retention, and a clear answer to the question every SharePoint decision eventually asks: who owns this six months from now?

That is the current version of the scar arc. The tool changed. The pattern did not.

So what do we do with it?

We stop treating scars like shame and start treating them like evidence. Most of the old decisions were made by people doing the best they could with the deadline, budget, licensing, platform limits, and executive patience they had at the time. The point is not to dunk on the past. The point is to stop repeating the pattern now that we have more evidence, better tools, and fewer excuses.

That means fewer sites, but better ones. It means owners, expiration dates, provisioning gates, and templates that bake governance into the moment of creation. It means metadata users earn, not endure. It means search-first information design. It means retention before cleanup. It means permission hygiene as a routine, not a special event we schedule after something embarrassing happens.

It also means treating AI readiness as architecture, not as a Copilot deployment checklist. If SharePoint is the memory layer underneath Microsoft 365, then content quality is not some dusty intranet concern. It is part of how the organization answers questions, makes decisions, and avoids confidently repeating old nonsense.

That is where the lessons I wrote earlier this year matter. SharePoint folders were never the problem because users were trying to express meaning somewhere. SharePoint metadata only works if people use it because architecture nobody can tolerate is just decoration with required fields. Search is the real SharePoint homepage because users have been telling us how they actually work for years. SharePoint retention beats cleanup every time because cleanup without lifecycle is just a temporary reduction in symptoms.

That was the real lesson from building the M365 Philly session. SharePoint at 25 is not just about what the platform survived. It is about what our decisions became after they had enough time to age. Some aged well. Some turned into scar tissue. Either way, they are telling us something.

Here is the uncomfortable part: many organizations are probably already licensed for governance capabilities they are not using. If your organization has Microsoft 365 Copilot licensing, there is a good chance SharePoint Advanced Management is part of that conversation already.

That means you may have tools for Data Access Governance reports, site access reviews, inactive site policies, site ownership policies, Restricted Content Discovery, and agent access insights sitting there while everyone keeps saying they are “getting ready for AI.“

So start there. Open SharePoint Advanced Management and pick one place to look: oversharing, inactive sites, ownership, or access reviews on the sites leadership uses. Not everything. Not the entire tenant by Friday. One report, one site, one setting, one owner, one fix.

Scars are useful when they teach you where not to cut again. Every future SharePoint scar starts the same way every old one did: with a decision that feels small at the time. We have 25 years of evidence now. Pretending we do not know better is how the next scar gets made.