The Pre-Migration Baseline: What to Capture Before Replatforming

A pre-migration baseline is the structured record of how your platform behaves before a migration, redesign, or replatforming — captured while the old system is still live, at the level of detail that lets you prove, weeks after launch, exactly what changed. It is the single highest-leverage artifact in migration risk management, and it is the one most teams skip, because it does not block launch and its value only becomes visible when something goes wrong.

Why a Baseline Decides Whether You Can Recover

When organic traffic moves after a migration, the team faces one question under pressure: is this normal post-launch turbulence, or is something structurally broken? Search engines take time to reprocess a changed platform — Google’s site move documentation says as much — so some fluctuation is expected. Real regressions hide inside that expected noise.

Without a baseline, the debate runs on memory and opinion. Someone thinks the old category pages had breadcrumbs. Someone believes the old templates rendered server-side. Nobody can say what the internal-link count on the money pages used to be. Every hypothesis requires an investigation, every investigation takes days, and the regression compounds while the team argues about what the old site actually did.

With a baseline, the same question is a diff. Rendered output: changed or not. Internal links into the affected template: count before, count after. Redirect behavior: matches the mapping specification or doesn’t. Structured data: present in both captures or dropped in the new one. The diagnosis that took three weeks of archaeology becomes an afternoon of comparison.

That is the core argument, and it is worth stating plainly: a migration without a baseline is a migration you cannot debug. All the evidence about the old system is destroyed at cutover. The baseline is the only backup of that evidence, and it can only be made in advance.

The Seven Layers of a Complete Baseline

Migrations break structural signals, and each signal fails independently. A useful baseline therefore covers seven layers — and covers each one per template group, because template-level variance is where migration damage actually lives.

1. URL inventory: what exists and what matters

The foundation is a complete list of URLs the old platform exposes — not the CMS’s page list, which routinely misses parameter URLs, pagination, legacy paths, and generated pages that search engines discovered years ago.

Build it from three sources and merge them:

• A full crawl of the live site, following links the way a search engine would
• Server logs, which reveal URLs that get crawler traffic without being linked internally anymore
• Search Console’s indexed-page data, which shows what the index actually holds

Rank the merged inventory by organic value — traffic, conversions, external links — so that redirect mapping and post-launch validation can prioritize the URLs that carry revenue. The top slice of that ranking deserves manual, one-by-one attention; the long tail can be validated in aggregate.

2. Rendered output: what a crawler actually receives

Capture the final rendered HTML for representative URLs of every template — not the raw source, the rendered result after JavaScript execution, because that is what modern crawlers evaluate. For each captured page, record the parts migrations most often silently change: the title and meta elements, canonical and robots directives, the main content block, navigation and breadcrumbs, and pagination handling.

This layer exists because replatforming usually changes the rendering pipeline itself — server-side to client-side, one framework to another, monolith to composed frontend. The new stack can produce visually identical pages whose machine-readable output is profoundly different: content moved below a rendering boundary, canonicals pointing elsewhere, navigation that no longer exists in the HTML at all. Only a rendered-output baseline makes that class of failure diffable.

3. The internal-link graph: how authority flows

For each template group, record which pages link into it, which pages it links out to, and the anchor text patterns involved. At minimum, capture inbound internal-link counts for the top pages of each template and the full outlink set of navigational surfaces — home, hubs, category pages, footers.

The internal-link graph is the layer teams most regret not capturing. Redesigns rework navigation as a matter of course, and the removal of a hub page or the collapse of a mega-menu can strip thousands of internal links from revenue pages in one deploy — invisible in functional QA, decisive for how search engines weight those pages. When rankings sag six weeks later, the question “how many internal links did this template lose?” is only answerable if the before-graph exists.

4. Structured data: the machine-readable claims

Extract the complete structured-data payload for each template: organization and site-level markup, breadcrumbs, product or article markup, FAQs — whatever the platform emits. Store the actual JSON-LD, not a checklist of which types exist, because migrations do not usually delete markup outright; they subtly degrade it. IDs change, relationships between entities break, required properties go missing, and the markup goes from valid-and-connected to valid-but-orphaned.

5. Performance per template: the baseline search engines feel

Record real-user Core Web Vitals and server response times per template group, plus lab measurements for representative pages under a stable configuration you can rerun identically after launch. Aggregate scores are close to useless here: a migration that improves the homepage while doubling response time on the long-tail templates that carry organic acquisition will look fine in the aggregate and be a regression where it matters.

Server-side timing deserves specific attention, because it bounds crawl capacity on large sites. If the new platform answers crawlers more slowly, search engines process less of the site per session — a discovery and indexation problem no frontend metric will reveal.

6. Index coverage: what search engines currently hold

Snapshot index coverage from Search Console: indexed counts by section, the excluded categories and their sizes, and sitemap-by-sitemap coverage ratios. This is the layer that turns “traffic is down” into “traffic is down because indexed pages in this section fell 40%,” and it establishes the pre-launch denominator that post-launch coverage will be judged against.

7. Crawler behavior: the server-log record

Finally, keep server logs — or an extraction of crawler activity from them — for a meaningful window before launch: crawl volume by section, response codes served to crawlers, and how quickly newly published content gets fetched. Crawl behavior after a migration is the earliest external signal of how search engines are digesting the change; without the before-record, the after-record has no meaning.

Capturing It: Practical Discipline

Start 4-8 weeks out, snapshot again in the final week. A single capture is a photograph; two or more give you trends, which is what separates “this template was always slow” from “this template degraded at launch.” The last snapshot should be as close to cutover as the release process allows.

Freeze the method, not just the data. Every capture must be rerunnable identically against the new platform: same crawler configuration, same user agent, same test locations, same rendered-output extraction. A baseline you cannot reproduce post-launch is a baseline you cannot diff.

Store it outside the platform being replaced. The baseline must survive the migration it exists to police. It should live in version control or independent storage — never in the CMS, database, or analytics of the system being retired.

Assign ownership outside delivery pressure. In the final weeks before a launch, everything that does not block the launch gets cut, and baseline capture never blocks a launch. This is precisely the argument for independent oversight of consequential migrations: someone whose job is the preservation evidence, not the ship date. That structural role — establishing what must be preserved before rollout and validating it through launch — is what migration and redesign oversight exists to provide.

What the Baseline Buys You After Launch

The payoff arrives in the 4-12 weeks after cutover, in three forms:

1. Fast attribution. When a signal moves, the baseline converts open-ended investigation into direct comparison. The difference is not marginal — it is the difference between diagnosing in days and diagnosing in weeks, while a visibility regression compounds daily.

2. A rollback criterion that means something. “Roll back if things look bad” is not a decision rule. “Roll back if indexed coverage in the revenue sections drops more than X% against baseline, or if the redirect audit shows mapping errors above Y%” is — and it can only be written if the baseline defines the reference values before launch, when the team is calm, rather than after, when it is not.

3. An honest recovery narrative. If a regression does occur, remediation gets sequenced by measured deltas — which templates lost links, which sections lost coverage, which layers actually changed — rather than by whichever symptom is loudest in the room. And if the migration went well, the baseline proves that too, which ends the low-grade anxiety of wondering whether a slow week is the migration’s fault.

The Uncomfortable Summary

Most migration postmortems I have read or been part of share one property: the team could describe what the new platform does, but could no longer prove what the old platform did. The evidence was destroyed at cutover, because nobody’s job was to preserve it.

The baseline is cheap relative to everything else in a migration — it is crawls, log retention, markup extraction, and disciplined storage. What it insures is not cheap at all: the organic acquisition that took years to build, and the engineering quarters a blind recovery consumes. Capture the record while the old system is still alive to give it. Afterward is too late, permanently.

Related Advisory Notes

• Migration Failures That Destroy Search Visibility
• Core Web Vitals Regressions After Redesigns
• Migrations & Redesign Risk (hub)

Next Step

If a migration, redesign, or replatforming is on your roadmap and the baseline described here does not yet exist, that gap is the work — and the capture window closes at cutover. Discuss the migration or read how Migration & Redesign Oversight structures the preservation work end to end.