Most enterprises never built a web quality program. They bought a CMS and assumed quality came in the box.
That assumption holds right up until the platform changes. Then the rules, the checks, the thresholds, and the publishing standards that took your team three years to agree on all turn out to have been platform configuration. They do not travel with you. You rebuild them from memory, badly, while the migration is still on fire.
Nobody files this as a failure because nothing breaks loudly. Siteimprove sees the same silent reset across enterprise replatformings.
Quality just resets and starts climbing again, and the organization absorbs the cost as a normal part of replatforming. It is not normal. It is the predictable result of never deciding who owns the standard.
So here is the argument. Across the enterprise migrations Siteimprove has analyzed, the same pattern holds: web quality is not a property of any CMS. It is a program your organization defines, owns, and enforces, and everything you leave inside the platform is something you will lose the next time you move.
A quality program is what governance looks like once it becomes operational, which places it inside the broader governance framework rather than alongside it.
This piece moves from what that program actually is, through why your CMS can never be its source, to the components and governance that carry quality across a platform change intact.
What an enterprise web quality program actually is
An enterprise web quality program is four things your organization holds. A definition of what good looks like. Named owners at every level who answer for it. Mechanisms that enforce the definition when content is created and published. Monitoring that tells you when it slips.
None of those four has to live inside a CMS. All of them usually do, which is why so many programs are invisible until the platform moves.
That is the whole distinction. Platform-based quality control is your standard expressed as a setting. Program-based quality control is your standard expressed as a governed artifact that a setting happens to implement this year.
A small team gets away with blurring the two. One site, one platform, three publishers, and the difference between a documented standard and a configured one is mostly academic. You can hold the whole thing in your head, and when you move platforms you carry it across in an afternoon.
At enterprise scale you cannot.
Siteimprove works with enterprise digital teams across government, higher education, healthcare, and financial services, and the pattern holds across all of them. Once you are running thousands of pages, more than one CMS, and publishing rights spread across dozens of business units, the standard is the only thing keeping the estate coherent.
It is also the thing nobody has written down. It exists as a set of behaviors in the current platform and a set of assumptions in the heads of the people who configured it. Ask two business units what your accessibility threshold is and you will often get two answers, both confident, neither sourced.
Every enterprise has a quality standard.
But very few have one that exists anywhere other than inside the system currently enforcing it.
That is Governance Risk in its most literal form: quality with no owner outside a system the organization is eventually going to replace.
A CMS enforces quality standards but can never own them
Your content management system enforces the standard but can never own it, because every control it offers is a feature of the system itself. That system is genuinely good at quality assurance: required fields, approval workflows, template constraints, publishing gates, pre-publish validation. All of it is real, all of it is worth configuring, and none of it is the problem.
But the problem is where all of it lives.
Every one of those controls is a feature of the system you happen to be running. The alt text rule is a field validation in that system. The metadata requirement is a content type definition in that system. The approval routing is a workflow object in that system.
When the system goes, they go with it. What your organization is left holding is a new platform and a vague collective memory of what the old one used to stop people doing.
Ask your team the honest version of the question. If you lost your CMS tomorrow, could anyone write down the quality standard it currently enforces?
Most teams cannot.
The rules were never authored as rules. They were configured, one ticket at a time, over years, by people who have mostly moved on. The knowledge was real, but it was never held anywhere durable.
This is why replatforming failures follow such a consistent shape. The migration plan covers content, templates, integrations, and redirects, because those are visible and someone owns them. The quality standard is not on the plan at all, because it was never treated as an asset that could be moved.
So it is not moved. It gets reconstructed after launch, from whatever the new platform makes easy, which is a different standard wearing the same name. Six months later somebody notices that pages are shipping without descriptive link text and nobody can say when that rule stopped being enforced. It stopped at migration. It just took two quarters to surface.
Your CMS enforces the standard. Your organization owns it.
Confuse those two and you are renting quality on a lease that ends the day you replatform.
A platform-independent program rests on five governed components
A durable enterprise web quality program is built from five parts, and the test for each one is the same: does it exist somewhere your CMS cannot delete?
The five are standards definition, role-based ownership, a measurement baseline, enforcement mechanisms, and continuous monitoring.
Standards definition is the written answer to what good looks like on your estate. Not a style guide sitting in a shared drive. A governed document with a version, an owner, and a review cycle, covering accessibility conformance against WCAG, metadata requirements, readability, link integrity, and the content rules the business actually cares about.
Role-based ownership names who answers for the standard at each level. Central governance owns the definition. Business units own conformance in their own corner of the estate. Content operations and content owners own the pages they publish.
If you cannot name a person for each layer, you do not have ownership.
You have a policy, and policies do not survive contact with a decentralized estate.
The measurement baseline is how you know where you stand, expressed in a way that does not depend on the platform reporting it. Enforcement mechanisms are what happens when someone publishes below the line. Continuous monitoring is what tells you the line is moving before anyone files a ticket. Three of the five get dedicated sections below: the measurement baseline, enforcement mechanisms, and continuous monitoring.
Every one of those five can be written down, assigned, and governed outside your CMS. None of them require a particular vendor, and none of them require the platform decision to be settled first. That is what makes them portable.
Most organizations have all five in some form. But they hold three of them as platform settings, one as a spreadsheet somebody maintains privately, and one as folklore.
Often only one of the five survives a migration intact, which describes more enterprise quality programs than teams expect the week before a replatforming kicks off.
The other trap is documentation without operation. A standards document nobody enforces is not a program component. It is a binder.
Each of the five has to be operationalized, which means somebody runs it, somebody answers for it, and something checks it. A component that fails all three tests is not part of your program no matter how carefully it was written.
Standards governed outside the CMS get reapplied, not rebuilt
A program survives a CMS migration because your standards are governed outside the platform and reapplied to the new one. Here is the mechanic, and it is almost boringly simple.
If your standards, policies, ownership map, and measurement baseline are documented and governed outside the CMS, then replatforming becomes a reapplication exercise. You take the standard you already have and you configure the new platform to enforce it. The work is real but it is bounded. The standard on the other side is the same standard.
The public sector version of this is instructive. The UK government publishes its service standard as a governed document sitting above whatever technology any individual department happens to run, so the standard outlasts the systems built against it. It maintains shared content standards across thousands of distributed publishers the same way, which is what lets a decentralized estate hold a single definition of good.
If those things only ever existed as configuration, replatforming becomes a rediscovery exercise. Your team sits in a room trying to remember what the old system used to require, while the launch date moves toward them.
The two projects look identical on a Gantt chart.
But they produce completely different estates, and the difference compounds every time the organization moves again.
You can tell which one you are running by watching what your team does first on the new platform. Teams with a program open their standards document and start mapping rules to the new system's enforcement points. Teams without one start clicking through settings to see what the new platform can do, and let the platform's defaults decide what their standard becomes.
That second path is how quality quietly ratchets down across successive migrations.
Nobody chooses a lower standard. But the new system made a different set of things easy, and the standard drifted toward them. Do that twice and the estate you are governing bears very little relationship to the one you thought you had.
There is a practical version of this you can act on now, before any platform decision is on the table. Audit the rules your current CMS enforces, then write them out as rules, in a document your organization owns, with an owner's name on it.
That exercise usually takes a week.
It is also the single highest-return week of work available to most enterprise web teams, because it converts a pile of configuration into a portable asset. Nothing about it requires budget, a vendor, or permission.
This is Content Risk and Transformation Risk arriving together, two of the seven categories in Siteimprove's Enterprise Migration Risk Framework. The content moves, the digital governance does not, and the organization treats the platform change as a project with an end date rather than a transition inside an ongoing program.
A composite quality score survives the platform it measured
A standard needs a number attached to it, and that number needs to outlive the CMS.
A composite quality score does that work. It rolls accessibility, content quality, and discoverability into a single digital quality measure of the estate, tracked over time and comparable across properties, so quality stops being a matter of opinion between teams who each brought a different dashboard.
The reason it matters at migration is narrower and more useful than most measurement arguments.
A composite score gives you a before and an after that the platform change cannot invalidate. You know what the estate scored the week before launch. You know what it scored thirty days later. The gap between those two numbers is the honest answer to whether quality held, and you get it without waiting for organic traffic to confirm the bad news.
Analytics rarely gives you that. Tracking codes break during migration, historical data becomes hard to reach, and the measurement most needed is the one most likely to be disrupted at exactly the wrong moment.
A quality baseline that never touched the tag manager does not have that problem.
Siteimprove.ai maintains the composite quality score independently of the content management system, which is what makes it a baseline rather than a report. The score persists across the platform change because it was never a function of the platform.
One caution worth stating plainly. A composite score is a measure of the estate, not a substitute for the analytics platform your business runs on. It tells you whether quality held. It does not tell you whether revenue did, and you still need both.
But a score is only a baseline if someone reads it on a schedule and someone answers for the trend.
Continuous monitoring keeps the number live. Your governance model decides what happens when it falls. A quality score with no consequence attached is a vanity metric with better branding.
The score is evidence. The decision about what the evidence obliges anyone to do stays with the organization.
Enforcement is what separates a standard from a suggestion
Enforcement is what turns your web governance standard into an operating constraint. Every organization I have worked with has more standards than it enforces.
The gap between the two is where quality actually gets decided.
Enforcement in a platform-independent program has three moving parts. Automated checks that test published content against the standard. Role-based alerts that reach the person who can fix the thing, not a shared inbox. Escalation paths that trigger when the fix does not happen.
All three can run outside the CMS, and that is the point.
Checks that run at the platform layer only test what the platform knows about. Checks that run against the live estate test what users and regulators actually encounter, across every property, whatever system produced it. That difference gets sharper the more platforms you run, and most large organizations run more than they admit.
Siteimprove's analysis of enterprise web quality programs draws one line here. Siteimprove.ai operates as the enforcement and visibility layer: it scans the estate against the rules your organization has defined, surfaces what falls short, and routes the finding to the owner.
What it does not do, and should not do, is decide what your standard is or absorb the accountability for meeting it.
That distinction is worth being pedantic about. The platform surfaces and enforces. The organization defines and answers.
Teams that blur this end up with a monitoring subscription and no governance, which produces a very well documented decline.
Sustained visibility is what makes governance operational instead of theoretical. Without it, your standard is a claim you make in a deck. With it, your standard is a number your business unit leads have to explain every month.
Standards defined centrally, owned locally, answerable across every team
In a decentralized estate, quality has no owner unless someone assigns one by role at every level. Content governance across your estate is an ownership problem before it is a tooling problem. This is the part organizations skip, and it is the part that determines whether the program is still running in three years.
The operating model that works is not complicated, and it sits between the centralized and decentralized content ownership models most organizations pick one of. Standards are defined centrally, because a standard that varies by business unit is not a standard. Enforcement and remediation happen locally, because the person who published the page is the person who can fix it fastest. Accountability is tracked across teams, because a score nobody has to explain is a score nobody improves.
Central governance without local ownership produces a quality team filing tickets into the void.
Local ownership without central standards produces forty definitions of good and no way to compare them. Both failure modes feel like governance from the inside. Neither one holds an estate together.
You need both, and you need the seam between them written down. That seam is usually where governance quietly fails, because everyone assumes the other side owns the part in the middle. Write down who escalates, to whom, and on what trigger, and most of the ambiguity disappears.
Governance documentation is the unglamorous mechanism that holds it together. Who owns the standard. Who reviews it and how often. What the escalation path is when a business unit sits below threshold for two quarters. Who inherits all of this when the person currently doing it leaves.
But that last question is the real durability test.
Most quality programs are one departure away from folklore. The program was never written down because the person running it did not need it written down, and when they go, the standard goes with them as surely as it would have gone with the CMS.
Review cycles matter for the same reason, because governance is an ongoing review and ownership discipline rather than a launch task.
A standard nobody has revisited in three years is not being governed, it is being remembered. Remembered standards decay at roughly the speed of staff turnover.
None of this is expensive. But it is deliberate, and deliberate is the part organizations skip when the launch date is close.
This is what carries the program past the moment the redesign team disbands. That moment is when most organizations lose control of quality, and the gap between losing it and noticing is usually measured in quarters.
Take Away
Every part of your quality program that lives inside the CMS is a part you will lose and rebuild at the next migration. Standards, ownership, measurement, and enforcement held above the platform are what make quality durable, and that is the entire difference between a program and a platform feature.
So stop asking which CMS enforces quality best. Ask whether your quality would survive losing that CMS tomorrow, and if the honest answer is no, the program is what needs building.