A pre-migration content inventory predicts what breaks at cutover only when it captures the signals that cause breakage — not just a list of URLs. The columns that matter are the ones tying a page to something fragile: an inbound link, a hardcoded path, a template that no longer exists in the target, or an asset no crawler can reach. If your spreadsheet has a title, a URL, and a word count, it will tell you what you own. It will not tell you what fails. This article covers the exact fields to add, why each one predicts a failure mode, and the thresholds that separate noise from a genuine cutover risk.
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
Before you trust the inventory, spot-check it: pick your top 20 pages by organic entrances and confirm each has a mapped target URL, a preserved or improved template, and its embedded assets accounted for. If any of those top-20 rows has an unresolved column, your inventory isn't done — and that page is a live cutover risk.