The CMS Nobody Owns

There is a question that tends to go in circles at most companies. Marketing says the developer owns the website. The developer says it belongs to marketing. The agency that built it three years ago says they handed it off and moved on. The result is that nobody actually owns the CMS architecture, and that gap is costing companies far more than they realize.

Not the content, Not the design. The structural layer underneath, where modules, content types, templates, and metadata all live. That layer runs on autopilot at most organizations, and it only becomes a problem when someone finally opens the hood and looks inside.

Everyone Builds.Nobody Governs.

Here is how the pattern plays out in practice.

The marketing team needs a new landing page for a campaign, so they ask a developer to build a custom module. The developer builds it, ships the page, and moves on to the next ticket. Six months later, a different campaign needs a similar page. A freelancer gets brought in, and because they do not know the first module exists, they build a new one with slightly different field names and slightly different markup but the same basic function.

A year after that, the company hires an agency for a site refresh. The agency builds their own set of components because they have their own process and nobody asked them to audit what already exists.

Three years into this cycle, the Hubspot portal has five banner modules, four hero sections, three CTA components, and two footer variants, all doing functionally the same thing. None of them are documented. Nobody knows the full count.

We saw this firsthand during a CMS migration audit of a 32,000-page site. The team estimated they had about 40 custom modules. The actual count was 166. Not because anyone made a mistake, but because nobody was responsible for keeping track.

The Ownership Vacuum

Every other system in the company has an owner.

The CRM has a RevOps team with naming conventions, review processes, and someone responsible for the data model before anyone adds a new custom property. The codebase has engineering leadership where pull requests get reviewed and duplicate functions get flagged. The design system has a team maintaining component libraries in Figma with brand guidelines and documented patterns.

The CMS has none of that. No component library governance. No review process for new modules. No documentation of what exists. No naming convention. No single person whose job it is to say "we already have a banner module, use that one."

The website is the most public-facing asset in the company. Every visitor sees it. Every piece of content lives on it. And its underlying architecture has no owner.

Why This Keeps Happening

Part of the problem is that CMS platforms do not make governance easy. Hubspot does not surface a module inventory dashboard where you can see all your custom modules, their usage counts, and when they were last modified in one view. We wrote about this broader gap in why CMS platforms do not give content teams a spreadsheet view. The tooling is built for working on one page at a time, one module at a time, and governance requires a bird's-eye view that does not exist natively.

But the bigger reason is cultural. Website architecture falls between teams. Marketing owns the content. Development owns the code. Design owns the look and feel. Nobody owns the structural layer where all three of those things intersect. And intersections without traffic lights create pileups.

What the Pileup Looks Like

Module sprawl is the most visible symptom, but it is not the only one.

On the 32,000-page site, the team thought they had 12 content types. The audit revealed 57. The same pattern was at work: different people creating different structures for similar content over time, with nobody maintaining a canonical list.

Metadata was inconsistent across the board. Some pages had meta descriptions and some did not. Some had alt text on images and some did not. Some followed a URL naming convention and others went their own way. There was never a standard, and there was never a person enforcing one.

About 25% of the modules on the site were not in use on any live page. They were ghosts from old campaigns, previous redesigns, and experiments that never shipped. Nobody deleted them because nobody knew they were there.

Internal links pointed to pages that had been moved, renamed, or deleted. Not because of negligence, but because content structure changes during migrations and redesigns affect link targets, and nobody was tracking those relationships.

None of these are catastrophic on their own. The site still works. Pages still load. But the compound effect is a CMS that is significantly more complex than it needs to be, significantly harder to maintain, and significantly more expensive to migrate when the time comes.

The Migration Tax

This is when the bill arrives.

You decide to move from Hubspot to Contentstack, or from WordPress to Hubspot, or from any platform to any other. The migration team starts by auditing the source site, and that is when everyone discovers what years of ungoverned building actually produced.

166 modules that need to be mapped to the new CMS. 57 content types that need transformation rules. Metadata gaps that need to be filled before migration or they carry over as gaps in the new system.

If someone had owned the CMS architecture from the beginning, the module count might have been 40 instead of 166. The content types might have been 15 instead of 57. The migration would have been scoped in weeks instead of months.

On our project, consolidating the module architecture from 166 down to 40 made 42% of the total migration automatable. That is roughly 13,000 entries that could be migrated programmatically because the component mapping was clean after consolidation. The other 58% required human review, but that number would have been much lower if the architecture had been governed from the start.

What Governance Actually Looks Like

It does not require a full-time hire. It requires a decision and a few habits.

Assign an owner: One person, not a committee. Someone who knows what modules exist, what content types are defined, and what the naming conventions are. This person does not need to build anything. They need to be the checkpoint before anyone else builds something new.

Create a module registry: A simple document listing every custom module, its purpose, its field structure, and its usage count. Update it when something new is created. Review it quarterly. Archive what is not in use.

Establish a "does this exist?" check: Before any developer, freelancer, or agency creates a new module, they check the registry first. If a similar component already exists, they use it or extend it instead of building a duplicate.

Run a quarterly audit: Count your modules, Count your content types, Check for orphans, This is basic website hygiene and it takes a few hours once you have the tooling to do it at scale.

Document your content model: Not a technical spec, but a simple map that shows what content types exist, what fields they contain, how they relate to each other, and which modules they use. This is the document that saves your migration team months of discovery work.

The Discipline That Does Not Exist Yet

Content engineering as a discipline is still forming. Most companies do not have a "content architect" role. There is no equivalent of a DBA for website content, and no equivalent of a DevOps engineer for CMS infrastructure.

But the companies that figure this out, that assign ownership, build governance habits, and treat the CMS as infrastructure instead of a dumping ground, are the ones that avoid the 166-module surprise. They are also the ones whose migrations cost half as much, take half as long, and deliver clean architecture on the other side instead of a slightly newer version of the same mess.