A migration is judged by its numbers. And those numbers are the first thing it breaks. Most teams never plan for that, so they treat analytics as something that rides along with the move: the tags come across, the reports resume, the graphs pick up where they left off.

They don't.

The move quietly severs the measurement you rely on to judge whether any of it worked, and nobody notices until someone opens a report weeks later and the data simply isn't there. Measurement continuity is the ability to track, compare, and interpret the same metrics across a migration without a gap you can't see. It sounds like a technical footnote.

But it is the difference between knowing your migration worked and guessing.

This is Measurement Risk, one of the seven categories in Siteimprove's Enterprise Migration Risk Framework, and it hides better than the rest. Governance failures get postmortems, and broken redirects get flagged in the rankings, but a measurement gap leaves no mark until you go looking for a number and find nothing there. So this piece walks through what actually breaks and why your launch checklist won't catch it. The fix is a measurement baseline that sits outside your analytics platform, and it is what keeps you seeing through the cutover.

Dropped Tags and Orphaned Baselines Are How Measurement Actually Breaks

Migration analytics failures aren't mysterious: they're a short list of the same things going wrong every time. Tracking codes get dropped when a template gets rebuilt and the analytics snippet doesn't make it into the new one, so whole sections ship without the tag that sat on every page before. Tag configurations reset when the container is rebuilt or re-pointed, and events that used to fire go quiet. Event and dataLayer wiring breaks when the new build names things differently than the code your tags expect. Cross-domain tracking and referral exclusions get lost on a domain change, so your own checkout starts showing up as a referral. Consent banners and third-party tags get reinstalled in a different order, and scripts that depend on each other load out of sequence and drop data without a warning.

None of this shows up as a broken page.

The page looks fine, and the measurement behind it is gone. Here is the concrete version. A retailer rebuilds its product templates on the new platform, the analytics tag lives in the old footer rather than the new one, and every product page ships without it. Category pages kept the old layout, so they still report normally and the dashboards look roughly right. Top-line traffic dips a little.

But it takes three weeks and a tense revenue meeting before anyone connects that dip to a missing tag on the highest-value pages on the site.

The quietest failure is the one nobody looks for: orphaned historical baselines. When a site moves, the numbers from before often stop being comparable to the numbers after. A new property, a different measurement model, a fresh implementation, or filters that didn't carry over all mean you are no longer measuring the same thing the same way. You still have data, but you can't line it up against last quarter and say what actually changed, because the history that gave your metrics meaning is stranded on the old setup.

At enterprise scale this gets worse, not better. A large estate rarely runs one clean analytics implementation: it runs several, spread across properties and subsites, owned by different teams, wired up over years by people who have since moved on. Every one of those is a place continuity can break, and no single person holds the whole map.

So name the failure modes before you migrate, not after. If you know that tracking codes drop, tag configs reset, event wiring breaks, and baselines get orphaned, you know what to watch for, and you catch it in days. Miss the chance, and you find out weeks later, from a report that came back empty.

Launch-Day Checks Confirm Pages Work, Not That Tracking Survived

Launch-day QA confirms the site works, not that measurement survived.

Launch-day QA is built to answer one question: does the site work? Do pages load, do links resolve, do forms submit, does the checkout complete. That is the right question for a launch.

It is the wrong question for measurement.

A migration can pass every functional check and still be quietly failing to measure. The pages render, the buttons work, but the analytics behind them is reporting nothing, or half of what it should, because a tag didn't fire or an event lost its wiring. Function and measurement are two different systems, and only one of them is on the launch checklist.

The reason this survives QA is that a dashboard rarely announces its own failure. A report showing zero conversions looks identical whether conversions genuinely stopped or the tracking that counts them broke, and a metric down forty percent could be a real decline or a measurement gap. Someone has to go looking, compare against a known-good baseline, and rule out the boring explanation before trusting the alarming one. At launch, nobody is doing that, because everyone is watching whether the site is up.

None of this is any one person's fault, which is exactly the problem. The person who validated the checkout wasn't asked to validate the analytics behind it, the analytics owner wasn't in the launch room, and the launch owner assumed both were covered. Each of them did their job. Checking that measurement survived belonged to no one. This is where Measurement Risk stops being a solo problem and becomes Operational Risk too.

These are two of the seven categories in Siteimprove's Enterprise Migration Risk Framework, and here they reinforce each other. When tracking is owned by three teams and configured across two tag managers, no single group can say continuity held. Each one assumes another checked. That gap in ownership is an operational failure, and it is exactly the kind of thing a launch checklist built around page function will never surface. The work falls in the seam between teams, which is where migration work usually goes to die.

Continuous visibility is the alternative, and at this scale it is not a luxury. A migration without ongoing monitoring is flying blind. The blind stretch runs right up until the numbers you needed are already missing, and by then the cheapest moment to have caught the problem is long gone.

Measurement Continuity Comes From a Baseline Outside Your Analytics Platform

Measurement continuity comes from a second measurement that doesn't route through your primary analytics platform at all. Reconfiguring GA4 or Adobe faster won't do it, because that is still one system and one point of failure. You keep measuring when your primary tracking breaks by having a baseline that was never wired through it.

A platform-independent baseline is a measurement layer that runs on its own crawl and its own scoring, separate from your tags and your analytics account. It tracks the health of your site across quality, accessibility, and discoverability, scored the same way over time. When a tag drops or an analytics property resets, the baseline keeps reporting, because it was never wired through the part that broke. It gives you a fixed reference point to measure against while your primary tracking is in pieces.

Be clear about what this is and what it is not. It is not a replacement for your enterprise analytics platform: you keep GA4 or Adobe for the things they do well, which is session behavior, conversion paths, attribution, and audience detail. But the baseline is a complementary safeguard that sits alongside them, so a break in one doesn't leave you with nothing to see. It does not care which analytics vendor you run, or whether you switched vendors as part of the move.

Think of it as a second altimeter, not a new cockpit.

What makes it more than a backup is where it lives. This is the same governance layer already watching quality, accessibility, and discoverability across your estate, which is what Siteimprove's approach treats as one connected picture rather than four disconnected tools. That connection is the payoff, because it lets you tie a quality or accessibility change to a movement in traffic or engagement, so the baseline isn't only proof that measurement survived. It is evidence of whether the migration improved anything, or quietly left the site worse than the version you replaced.

The independence also changes when you find out. Because the baseline runs continuously rather than waiting for a scheduled report, a tracking break shows up as a divergence you can see within days. It is not a mystery pieced together at the quarterly review. That is the difference between a fix on Tuesday and a forensic exercise next quarter.

For a decentralized estate this matters more, not less. When quality, accessibility, and discoverability are scored the same way across every property, the baseline covers the whole estate at once, including the subsites nobody remembered to add to the analytics account.

Measurement continuity isn't bolted on after the fact.

It is a property of governing quality in the first place, and it is the connection a point-solution analytics tool or a standalone SEO crawler doesn't make.

Continuity Is Something You Verify at Cutover, Not Assume

Measurement continuity is something you verify around the cutover, not something you assume. Siteimprove's approach treats it as three verifiable checkpoints: a baseline before, parallel validation during, and reconciliation after. Before the migration, capture a baseline: record what your metrics say now, while everything still works, so you have something real to compare against later. This is the reference the whole exercise depends on, and it only exists if you take it before you move.

During the cutover, validate in parallel. Run old and new measurement side by side where you can. Check that events still fire, tags still load, and the numbers on the new site track against the baseline you captured. Watch the events that carry money first: purchases, form completions, and lead submissions, because those are the ones a broken tag hides most expensively. This is the window where a broken tag is cheap to fix.

Miss it, and the same tag becomes a month of data you will never get back.

After launch, reconcile. Line the post-migration numbers up against the baseline and account for every gap. A drop that reconciles cleanly is a real change you can act on. But a drop that doesn't reconcile is usually a measurement failure wearing the costume of a traffic decline. Telling those two apart is the entire job, and you can only do it if you captured the baseline in the first place.

Someone has to own this, and it is rarely obvious who.

Analytics continuity sits between the analytics team, the developers, and whoever runs the migration, so the checkpoints only happen if one person is named to run them. Put that ownership in the migration plan, not in the hope that a shared calendar invite covers it.

One rule holds all of this together: your verification can't depend on the platform that might have broken. If the only way you would know analytics failed is by checking analytics, you have no check at all. That is the whole argument for a baseline that measures from the outside, and it is still standing when the thing you are trying to verify is on the floor.

Take Away

Analytics doesn't survive a migration on its own, and the checks most teams run at launch are aimed at the wrong target. What protects your ability to measure isn't a sharper cutover checklist. It is a measurement baseline that lives outside your primary analytics platform and keeps reporting when your tracking breaks.

That makes measurement continuity a governance question, not a reconfiguration task. It belongs to the same layer already watching quality, accessibility, and discoverability, which is why the teams that treat quality as infrastructure are the ones still measuring on launch day.

So decide how you will keep measuring before you move, not after the numbers go quiet.

Get that right, and the next question is the good one: not whether you can still see your data, but whether the migration actually worked.