Ask an enterprise team how they are handling content in their migration, and most will hand you a transfer plan: what moves, in what order, and into which templates.
That answer is the problem.
It treats content as inventory to relocate, but the real exposure sits somewhere else entirely. Quality, structure, and governance standards degrade the moment thousands of pages move at once, and nobody sees it happen until well after launch.
Content migration risk is not a data-transfer problem. It is a governance problem.
Most of the content failures that surface after a migration were not created by the migration at all. They were already there, sitting in the old site and waiting. The move simply exposed the standards nobody had been enforcing, then multiplied them by the number of pages you own.
Siteimprove's Enterprise Migration Risk Framework treats this as one of seven distinct risk categories, and it deliberately places Content Risk right next to Governance Risk, because in practice the two are far harder to separate than most teams expect. This piece works through what actually breaks when content moves at scale, why governance standards do not survive the move on their own, and why the teams that come through a migration clean are almost always the ones who could see their content clearly before they touched any of it.
The content failures that recur when pages move at scale
Here is what happens, over and over, on migrations that looked perfectly healthy on the project plan.
The damage is not random. When content moves at volume, the same failures come back every single time, in roughly the same order.
You get orphaned pages the new navigation never reaches. You get taxonomies that fracture the moment the URL structure changes underneath them. You get metadata stripped somewhere in the transfer, and voice that drifts across the whole library because no standard ever traveled with the content.
Each one of these looks small on a single page, but multiply it across your real page count and the picture changes fast.
One broken template is not a content problem. One broken template applied to four thousand product pages is a very expensive content problem, and migration is the moment that multiplication lands all at once.
You should also expect the quieter version of the same thing, the version that never trips an obvious alarm. Pages that technically moved across but quietly lost every internal link. Documents that arrived carrying broken references to images and downloads that were never migrated alongside them. Content that looks completely intact in a spot check and turns out to be subtly wrong across the long tail you never had time to review. Data integrity at content scale is not a question of whether the rows transferred, but whether each page still means what it meant before you moved it.
Now think for a moment about what each of these failures actually costs the person who has to answer for it later.
Orphaned content means pages you paid good money to produce that no user can now find. Broken taxonomies mean the filters, faceted search, and related-content modules your site quietly depends on start returning the wrong results. Stripped metadata means search engines lose the signals they used to rank you, and your own on-site search stops surfacing the right pages. Drifting voice means a brand that suddenly reads as though six different companies took turns writing it.
None of this shows up in a migration status report.
All of it shows up in a support queue, a traffic chart, or a compliance review a few weeks down the line.
Name the pattern and you can plan against it. Leave it unnamed and you will find it after launch, which is reliably the most expensive place to find anything.
Content problems survive migration because governance standards don't travel automatically
So where do content migration's recurring failures actually come from?
Not the migration itself. That is the genuinely uncomfortable part of the answer.
They come from standards that were never enforced in the first place. The old site tolerated inconsistent metadata, page ownership that nobody in the room could confidently name, and a taxonomy that had grown by accretion over a decade of quiet compromises. Migration does not repair a single line of that, but it happily picks all of it up and carries it into a brand-new system, at scale, and on a deadline that leaves no room to fix things in flight.
If governance does not travel with the content, the new environment simply inherits every problem the old one tolerated.
Governance here is not an abstraction. It comes down to three concrete things: who actually owns content quality, which standards are genuinely mandatory rather than merely encouraged, and how those standards get checked before any page is allowed to go live.
A migration puts all three of them under pressure at exactly the same time. The pages with no clear owner are precisely the pages nobody audits before they move. The standards that were treated as optional are the first ones dropped the moment the timeline tightens. And a quality check that only ever ran as a manual pre-launch pass cannot keep pace with thousands of pages moving inside a few short weeks.
This is exactly where Siteimprove's framework connects Content Risk to Governance Risk: quality failure at scale is a governance failure.
You cannot manage content quality at scale as a one-off cleanup task. You either manage it as an enforced standard, or you do not really manage it at all.
It is also why "we will clean it up after launch" almost never survives contact with reality. Post-launch cleanup is the same manual effort you already skipped before launch, except now the broken pages are live, real traffic is routing straight to them, and the project team is quietly packing up and moving on. The teams that avoid this trap build the check directly into the workflow instead, so a page that breaks a content standard gets caught the moment someone creates it, rather than discovered by an annoyed user three months later.
Enforcement is a capability your team needs continuous visibility into. It is not a one-time cleanup, and it is emphatically not something a platform quietly handles on your behalf while you look the other way. The standard itself is always yours to define and to own. What you need alongside it is a reliable way to see, at any given moment, exactly where your content is drifting away from that standard.
Why you cannot protect content you cannot see during migration
You cannot protect content you cannot see.
Every decision a migration forces on you about content runs through that one fact.
Teams that migrate blind tend to know the pattern even when they will not say it out loud. No real inventory of what they actually hold. No quality baseline captured before the move begins. No monitoring at all while the content is in flight. So they end up learning what broke the way everyone learns bad news, from a stack of complaints and a sinking traffic chart, weeks after any of it stopped being cheap to fix.
A content baseline taken before migration changes the entire character of the exercise. It tells you how many pages you genuinely have, which ones are stale, where the quality and structural problems already sit today, and what will carry real risk forward if you move it across untouched.
With that picture in hand, migration becomes a series of deliberate decisions: what to move, what to retire, and what to fix before it ever reaches the new system.
Without it, migration collapses into a bulk copy. And a bulk copy is exactly how you carry four years of neglected content straight into the expensive new platform you just finished building.
Continuous visibility is the throughline in Siteimprove's migration risk framework, and it has to run in two directions at once. A baseline before the move tells you what you are dealing with going in. Monitoring that keeps running through launch tells you what the move is actually doing to your content in real time, while you still have room to step in and correct it.
I am not going to walk you through how to run that baseline in this piece, because it is a discipline in its own right and the pre-redesign audit framework already covers it properly. The point for migration is narrower than a full audit method. Visibility is the deciding factor. The teams that can see their content are the ones that manage to govern it, but the teams that cannot will inherit whatever the old site had been quietly hiding, at precisely the scale they were trying to grow into.
Last Words
Put the three together and the shape is clear: recurring content failures, ungoverned standards, and missing visibility.
The failures repeat. They come from ungoverned standards rather than from the move itself. And they stay completely invisible right up until launch, unless you build the visibility in from the start.
Content risk at scale is not a transfer problem you get to solve once on migration day. It is a governance problem, and you will either manage it continuously or inherit it permanently.
So the real question to bring to your next migration plan is not how you are going to move the content. It is whether you can actually see the state of your content before you move it, and whether your standards will still be enforced the morning after you launch.