Make address preservation an explicit requirement
A CMS replacement can change public paths even when the business sees it as a design project. Before import, agree which existing URLs must remain stable and which changes have a documented reason. Do not let the new system silently generate the final address plan from page titles. A renamed navigation label does not automatically require a renamed URL.
Give each content item a durable identifier that survives the import. Record its existing public address, language, content purpose and intended destination. This makes it possible to compare the old and new systems even when their database IDs differ. Keep the original export unchanged as a reference and work on a versioned copy.
Build an inventory beyond the current navigation
Google recommends drawing the old-URL inventory from sources such as sitemaps, CMS records, traffic evidence and links, and including relevant assets. Combine those sources rather than treating the menu as a complete list. An older guide or downloadable document may still have visitors even though it no longer appears in navigation.
For each source, record the collection date and scope. A short analytics window can miss seasonal content; an incomplete crawl can miss orphan pages. Add a reason for prioritizing each important address, such as an active customer workflow or documented inbound visits. Do not discard a page solely because one report contains no recent data.
Assign a disposition before configuring the new CMS
Use four practical dispositions: retain the same address, move to an equivalent page, consolidate into a page that actually covers the material, or retire without a replacement. Every old URL needs an explicit decision and reviewer. Flag conflicting destinations and multiple new pages claiming the same old content for editorial resolution.
Preserving an address means preserving the useful destination too. A successful response containing an unrelated page is not a completed migration. When a URL changes, Google recommends permanent server redirects where possible and warns against sending unrelated old pages to the homepage. Keep redirect implementation tests separate from this content mapping decision.
Reconcile a fictional import before launch
Illustrative example: an agency imports an English integration guide, its Arabic counterpart and a downloadable worksheet. The new CMS generates a different English slug, omits the Arabic page and stores the worksheet under a temporary media address. Comparing page counts alone would miss the relationships among these failures.
The team retains the original English path, restores the Arabic edition at its approved address and assigns the worksheet a stable public destination. The mapping records all three decisions with owners. No redirect is needed for a genuinely unchanged address; a changed asset address needs its own disposition. This is a hypothetical example, not a reported client outcome.
Use the mapping as a release and recovery artifact
Compare the deployed URL list against the approved mapping, then verify content identity, language and expected responses for important entries. Update internal links and applicable URL annotations when destinations change. Keep the mapping with the CMS export and release record so a reviewer can identify missing items without reconstructing decisions from memory.
Record exceptions explicitly and assign follow-up owners. Watch for newly discovered old addresses after launch and assess them against the same content rules. A crawl can help find broken destinations, but a person must judge equivalence. Neither retaining paths nor completing a migration guarantees unchanged rankings; search visibility can fluctuate while Google processes a move.