Your CMS hands you an export and, honestly, it looks great. Every page present, the columns squared off, three thousand rows sorted so neatly you almost want to frame it. Title, URL, word count, done. You feel ready. And then a week after cutover a landing page goes quiet and you realise the tidiest sheet you ever built told you nothing about the one row that mattered. That gap is the whole reason I keep re-checking this. A clean export lists what you own; it does not predict what breaks, because breakage lives in the things an export never bothers to record: the inbound link nobody mapped, the hardcoded path, the template with no home in the target, the asset no crawler can reach. Word count is a receipt. It tells you about the past and shrugs at the future. This piece is about the exact fields to add instead, why each one predicts a specific failure, and the thresholds that separate real cutover risk from noise you can ignore.
Why most inventories miss the breakage
Teams build inventories from a CMS export or a single crawl, then treat the row count as the finish line. But cutover failures don't come from pages you know about. They come from the gap between three different views of the same site: what the CMS thinks it publishes, what actually renders and gets crawled, and what the outside world links to. A page can exist in all three and still break because its template maps to nothing in the target, or because its canonical points at a URL you're about to retire.
The fix is to reconcile those three sources into one row per URL, then attach the fields that predict each failure mode. Do this before you touch the target platform, because the inventory is what turns a redirect map, a content-model mapping, and a kill list into evidence-based decisions instead of guesses.
The columns that actually predict breakage
Start with identity and reach, then add the risk signals. The right-hand column below is the failure each field lets you predict.
| Column | Source | Failure it predicts |
|---|---|---|
| Canonical URL + status code | Live crawl | Redirect chains, soft 404s, canonical pointing at a to-be-killed URL |
| Inbound internal links (count + sources) | Crawl link graph | Orphaning after cutover; broken nav if the target IA changes |
| External referring domains | Backlink data | Lost link equity when a high-authority target 404s or 301s to a weak page |
| Organic entrances (last 90 days) | Analytics / GSC | Traffic loss you can size in advance; prioritization of the redirect map |
| Template / content type | CMS export | Content-model gaps, a type with no home in the target |
| Embedded asset paths | HTML parse | Orphaned images, PDFs, and hardcoded absolute URLs that break on the new domain |
| Duplicate / near-duplicate cluster ID | Content similarity | Cannibalization carried forward; ambiguous redirect targets |
| Last modified + last-published author | CMS export | Stale content that should be killed, not migrated |
| Structured data present (Y/N + type) | Crawl | Lost rich results and weakened AEO signals after template swaps |
Set thresholds before you score
Raw columns don't make decisions; thresholds do. Agree on these before the inventory is populated, so the numbers aren't argued into whatever conclusion someone wanted.
- Redirect risk: any URL with external referring domains and a status code that isn't a clean 200 is a must-map row, not a maybe.
- Orphan risk: zero inbound internal links but non-zero organic entrances means the page lives on search, not navigation. A template change can strand it silently.
- Model gap: any content type representing fewer than ~1% of pages still needs a target mapping; long-tail types are where migrations lose editorial fields.
- Kill candidates: zero organic entrances in 90 days, no external links, and a near-duplicate cluster sibling: migrate one, kill the rest.
Reconcile three sources, not one
The single most valuable step is the join. Pull your CMS export, a full live crawl, and analytics/GSC + backlink data, then merge on normalized URL. The interesting rows are the mismatches:
- In CMS, not in crawl: published but unreachable, often behind broken nav or requiring parameters. These get lost at cutover with no error to warn you.
- In crawl, not in CMS: orphaned assets, legacy static files, or output from a system nobody remembers. These are the classic quiet killers.
- In analytics/backlinks, not in crawl: URLs the outside world still uses that your site no longer serves, your highest-priority redirect targets.
Each mismatch category maps to a specific pre-go-live task. This reconciliation is the core of what a pre-migration scan should produce, and it's the layer Replatform Radar automates by crawling the source site and cross-referencing reachability, links, and search signals into one scored row per URL.
Turn the inventory into a migrate / rewrite / kill plan
Once the columns and thresholds exist, every row resolves to one of three verdicts:
- Migrate as-is. Clean status, has traffic or links, maps cleanly to a target type. Preserve the URL or map a 1:1 redirect.
- Rewrite / consolidate: part of a duplicate cluster, or a content type with no direct target home. Merge into a canonical winner and redirect the rest.
- Kill: no traffic, no links, stale, duplicative. Let it 410 or redirect to the nearest parent, deliberately.
Do this and the redirect map writes itself from the inventory rather than from a last-minute crawl of the staging site. The difference between a calm cutover and a traffic cliff is almost always whether these fields existed before anyone started building in the target platform.
A quick validation pass
So here's what I actually think, plainly: the inventory is not finished when the row count settles, it's finished when you've reconciled the three sources and personally looked at the pages that matter most. Take your top 20 by organic entrances and go through them one at a time. Each one needs a mapped target URL, a template that's preserved or improved, and every embedded asset accounted for. Yes, it's tedious, and yes, a tool can do most of the joining for you, but this last pass is where I'd spend the hour by hand. If even one of those 20 rows still has a column that's a shrug and a maybe, the sheet isn't done, no matter how confidently the completion bar reads a hundred percent. A gorgeous export that can't answer for its own best pages isn't a plan, it's a page waiting to go quiet on you.