Most enterprise migration QA is a single sign-off dressed up as a process.
The team runs a checklist before launch, someone with authority approves it, the site goes live, and everyone treats that green checkmark as evidence the migration was clean. Then the traffic report lands three weeks later and a third of the redirect map is pointing at pages that no longer exist.
Here is what that checklist could never have told you: migration errors do not happen at launch. They accumulate across the whole timeline, from the first staging build to the template edit somebody ships two months after go-live.
So a QA process built around one gate is structurally blind to most of what goes wrong. It inspects a single moment in a project that fails across many of them. The checklist is not wrong, exactly. But it is aimed at the wrong shape of problem.
This is the pattern Siteimprove sees across enterprise migrations, and it is the reasoning behind Siteimprove’s Three-Stage Migration QA Framework: not a gate, but continuous validation across three stages, pre-launch baselining, launch-day verification, and post-launch monitoring, with the checks embedded in the editorial and development workflow rather than bolted on at the end. The value is not in running more checks. It is in running them at the points on your timeline where the errors actually appear.
This guide walks through all three stages and the reason each one catches failures the others cannot. It covers how to validate the migration itself. It does not cover redesign planning or stakeholder alignment. Those decisions sit upstream of QA, and they carry their own risks that deserve their own treatment.
One clarification before the stages, because the distinction matters. Siteimprove.ai is the visibility and monitoring layer in this picture. It surfaces the issues and tracks them over time. It does not run your testing for you, and it is not an agency you hand the migration to. The validation is your team’s work. The visibility is what makes that work possible across thousands of pages and a dozen owners who have never met.
Three stages catch errors a single launch gate never sees
Start with why one gate fails, because it explains everything that follows.
A launch-day checklist inspects one moment.
Migration risk does not live in one moment. Redirects break in staging, break again in production under real infrastructure, and break a third time weeks later when someone edits the template that generates them. Accessibility conformance drifts as components get rebuilt and re-themed. Analytics tags fire correctly in the test container and then go silent when the live tag manager loads a config nobody diffed. Each of those failures belongs to a different point on the timeline, and a single gate can only ever stand at one of them.
That is the case for three stages, and each one exists to cover a specific blind spot:
Pre-launch baselining catches what staging reveals. You capture a known-good picture of redirects, canonicals, accessibility conformance, content integrity, and analytics before anything moves, so you have something to measure against later.
Launch-day verification catches what only production exposes. Real infrastructure, caching, and a content delivery network behave differently than a staging box, and launch day is the first time you get to see that difference.
Post-launch monitoring catches regression that emerges over time. The migration is not finished when the site goes live, and the errors introduced afterward are precisely the ones nobody is still watching for.
Run a single scenario through all three and the point lands. A canonical tag gets set to the wrong host during the rebuild. In staging the page resolves and looks fine, so a launch-day-only check waves it through. But the baseline you captured recorded the correct canonical, so your pre-launch comparison flags the mismatch before you ever ship. Miss it there and launch-day verification still has a shot, because the live page now declares a canonical that contradicts the map you built. Miss it there too and post-launch monitoring catches the indexing drift a week later, once search engines start consolidating signals onto the wrong URL. One defect, three chances to catch it, but only if all three stages are actually running.
Read together, the three stages are not one checklist run three times. Each one sees a class of error the other two are structurally incapable of catching. Drop any one of them and you have not trimmed the process. You have decided which failures you would rather discover in public.
This is the Operational Risk category in Siteimprove’s Enterprise Migration Risk Framework: the risk that migration workflows, QA processes, and team coordination fail at the point of execution. Governance sets the standards. Discoverability protects the traffic. Operational Risk is where a good plan quietly dies in the doing, and Siteimprove’s Three-Stage Migration QA Framework is how you keep it alive.
A pre-launch baseline is what makes later regression detectable
You cannot detect regression against nothing.
That one sentence is the entire argument for baselining, so sit with it for a second. Regression means something got worse. Worse than what? If you never recorded the “what” before the migration started, every check you run afterward is a guess wearing a lab coat.
In Siteimprove’s methodology, the pre-migration baseline is the recorded state you measure everything else against. At enterprise scale, across thousands of pages and decentralized ownership, that baseline has to be captured systematically. Sampling a few templates by hand and calling it representative is how large sites carry hidden problems straight through a migration.
Enterprise scale is what makes this non-negotiable. On a fifty-page site you could eyeball the baseline and mostly get away with it. But you are not migrating fifty pages. You are migrating tens of thousands, owned by teams in departments that do not share a calendar, and the pages most likely to break are the ones no central owner is even looking at. A baseline captured by hand covers what you remembered to check. A baseline captured systematically covers what you forgot.
Here is what belongs in the baseline.
Redirects and canonicals. Map every indexed URL to its intended destination, and record which canonical each page declares. Google’s own guidance on moving a site treats this mapping as the non-negotiable core of a migration, and for good reason: it is the reference you will check on launch day and again every week after. A redirect map you did not capture before the move is a redirect map you cannot verify after it.
Accessibility conformance. Capture where the current site stands against international accessibility standards, at the page level and across the whole portfolio. You want this on record so that after launch you can prove conformance held rather than hoping it did. Migration is one of the most common ways a previously conformant page quietly breaks, because templates change and components get rebuilt, and you only know it happened if you knew where you started.
Content and link integrity. Inventory the pages, documents, images, and internal links before the move. Broken links and orphaned content that already exist do not repair themselves in transit. They get carried into the new environment, and now they are your problem to find, in a system you only just finished building. A baseline inventory tells you what to fix, retire, or leave behind before it reaches the new system.
Analytics continuity. Record what is being tracked and how it is wired, because tracking implementations are one of the first things a replatform breaks without announcing it. If you cannot see what changed, you cannot tell a real traffic drop from a measurement artifact, and you will spend the first month after launch arguing about which one it is.
Capture all of that in staging, and embed the capture in the workflow instead of treating it as a one-time export. A baseline you take once and file in a shared drive is already going stale the moment you save it. A baseline the platform holds and keeps current is the thing every later stage actually measures against. This is where “flying blind” stops being a metaphor. Teams that skip baselining are not moving faster. They are choosing to find out about their problems later, when the same problems cost more to fix.
Production is the first environment that can contradict your staging tests
Staging tells you what should happen. Production tells you what does.
Those are not the same environment, and launch day is the gap between them.
Picture the redirect you tested in staging. It passed. Then the site goes live behind a content delivery network, a caching layer sits in front of the origin, a load balancer routes a slice of traffic to a node running a stale config, and the redirect that passed every staging test now returns a 200 to a page that no longer holds any content. Nothing was wrong with your test, but the environment you tested in was simply not the environment your users are in.
So launch-day verification is not the pre-launch checklist run one more time for luck. It is a different job with a different question: does the baseline you captured actually hold under live conditions?
Here is what you verify on launch day.
Live redirects and canonicals, checked against the baseline map, in production, against the real infrastructure your users hit. This is the highest-value check of the day, because redirect failures bleed traffic silently and compound fast.
Analytics and tag firing, because a tracking setup that worked in the test container is exactly the kind of thing that breaks when the live tag manager loads. If measurement is broken at launch, you are blind for the entire window when you most need to see.
Accessibility, because a component that passed in staging can render differently once production styles, real content, and dynamic states are all in play. Conformance is not portable by assumption. You confirm it live or you do not know it.
Content and link integrity, because the pages that actually shipped are not always the pages you staged, and the internal links that resolved in the test build do not always resolve in the real one.
You also want a clear line for when a failure is bad enough to roll back. Launch day is not the moment to invent that threshold. Decide in advance which failures are cosmetic and which are stop-the-launch, because under live pressure every problem feels urgent, but only some of them actually are.
In Siteimprove’s approach, the mechanism that makes launch day survivable is page-level verification. You re-check the specific pages and paths that matter the moment they go live, rather than waiting for a full crawl of the whole site to come back around. When a check runs the instant a page is live, you catch the contradiction while you can still fix it quietly. Wait for the weekly audit and you are fixing it after your users, your stakeholders, and search engines have all already seen it.
Regression keeps arriving after everyone has declared the migration done
Launch is a milestone, not an ending.
The most expensive enterprise migration failure is rarely a bad launch. It is a launch that went fine, followed by six months of quiet decay because your project team disbanded and everyone moved on to the next thing.
Regression keeps arriving after go-live for reasons that have nothing to do with how careful the launch was. Templates get edited by people who were never in the migration meetings. Content gets republished. A third-party script pushes an update. A new section ships without the redirects the last one had. Each change is small on its own, and each one can undo something the migration got right.
Post-launch monitoring is the only stage positioned to catch any of that, because it is the only stage still running when it happens.
You watch the same four checks continuously: redirects and canonicals, accessibility, content and links, and analytics, now rather than in a one-day sweep.
Redirects and canonicals that break when fresh content reshapes the URL structure and nobody updates the map.
Accessibility conformance that drifts as pages get edited by contributors who were not trained on what the migration standardized.
Content and link decay as the inventory grows, pages get retired, and internal links quietly rot into dead ends.
Analytics gaps that open when someone touches the tag setup months later and no one notices the numbers stopped being real.
This is where continuous visibility earns its keep. Monitoring that runs automatically surfaces these issues as they appear, not at the next scheduled review. The difference is not cosmetic. An issue caught the day it appears is one broken page. The same issue caught at a quarterly audit is one broken page multiplied by every change that shipped on top of it in the meantime.
Siteimprove.ai sits at this stage as the visibility layer. It is what keeps someone able to see the site’s real state after the war room has emptied and the project budget has closed. Your team still owns the fixes, but the platform is what makes sure they get noticed before they turn into a pattern.
That shift, from a project that ends to a capability that continues, is the difference between a migration that holds and one that slowly comes apart while everyone assumes it is fine.
Checks embedded in the workflow catch errors a separate gate misses
Siteimprove’s Three-Stage Migration QA Framework only works if the checks live inside the editorial and development workflow, not beside it.
Here is the failure mode the entire framework is built to avoid. A team sets up QA as a separate step. Content gets created, code gets written, and then, later, on a schedule, someone runs the audit. By the time that audit runs, the broken thing has been live for days and has already been copied into a dozen more pages built from the same flawed pattern.
Embedded validation moves the check to the moment of creation.
In practice that means a few concrete things. Prepublish checks inside the content management system catch an accessibility or quality problem before the editor publishes, not after a reader lands on the page. Accessibility and technical checks in the development pipeline flag a regression while the code is still in front of the developer who wrote it, with the context still loaded in their head. The feedback arrives at the one moment when a fix is genuinely cheap: before the work has moved on and taken everyone’s attention with it.
Contrast that with a gate. A gate discovers problems, but it does not prevent them. By the time content or code reaches a gate, the work is finished, the author has context-switched three times, and every issue the gate turns up is rework that somebody now has to schedule.
There is an organizational tax to embedding, and it is worth naming plainly. Editors and developers do not love a check that interrupts them mid-task. But a check that interrupts you for ten seconds now is buying back the hour you would have spent unwinding the same mistake after launch. The interruption is the point. It is the cheapest moment the fix will ever have, and every stage you push it past makes it more expensive.
So the choice between embedded checks and a periodic gate is not really about thoroughness. Both can be exhaustive. It is a choice about when you find out, and finding out earlier is the whole game. A thorough gate that runs on Friday is still telling you about a problem you created on Monday, after four days of everyone building on top of it.
Embedding does one more quieter thing worth naming. It makes quality, accessibility, and discoverability move together instead of competing for your team’s attention as three separate audits. They share structural inputs. Clean, well-structured markup helps a screen reader, a crawler, and an editor at the same time. When the checks for all three live in one workflow, you stop paying three times for what is often one underlying fix.
The cost of a migration defect rises the later you find it
Every argument in this guide reduces to one economic fact.
A defect gets more expensive the later you catch it. That pattern is one of the most consistent findings in software engineering: a problem fixed at the point of creation costs a fraction of what the same problem costs once it reaches production, and the gap widens at every stage in between. The exact multipliers get argued over, and you should be skeptical of anyone quoting a precise one. The direction, though, is not in dispute, and the direction is all the argument needs.
Migration makes that cost curve steeper, because migration errors replicate.
Watch how a single defect compounds. A broken redirect pattern gets baked into a template. The template generates four hundred pages. Every one of those pages now carries the same broken redirect, and every internal link pointing at them is now pointing at a dead end. Caught in staging, that is one template fix before anyone sees it. Caught in a post-launch audit, it is four hundred broken pages, a pile of lost link equity, and a traffic chart your VP is now asking pointed questions about. Same defect. Wildly different bill.
So a periodic gate is not merely slower. It is more expensive by construction. A gate lets a defect ride from the moment it is introduced to the moment the audit finally runs, and every page published in that window inherits the problem for free.
I will be straight about one thing here, because the framing gets abused by people selling things. Accessibility and discoverability share structural inputs, but improving one does not automatically improve the other, and no honest QA process should promise that it does. The reason to run them in the same embedded workflow is efficiency and coverage, not a magic causal link. Anyone selling you the causal link is selling you something you should not buy.
The defensible claim is simpler, and it holds up under scrutiny: catching issues early is cheaper than catching them late, and migration is the exact moment when “late” gets very expensive very fast.
Take Away
Migration QA is a lifecycle, not an event.
Pre-launch baselining, launch-day verification, and post-launch monitoring each cover a blind spot the other two cannot, and embedding the checks in the workflow is what turns three separate audits into one continuous capability. Skip a stage and you are not saving effort. You are choosing which class of error you would rather find out about in public.
So go look at your own process and find the single gate it still leans on. That gate is exactly where your next migration will break.