A CMS migration starts before a single redirect is written. The first problem is knowing which URLs exist, which receive traffic, which ones bots crawl, and which have editorial or commercial value. No single source answers all of those questions.
An inventory with provenance
We combine CMS exports, sitemaps, crawls, Search Console, and CDN logs. Every observation keeps its source and date: today's sitemap and a crawl from months ago describe different moments. We normalize host, trailing slashes, parameters, and protocols without deleting the original URL. That keeps discrepancies reviewable and prevents a silent transformation from hiding pages.
State and destination are different fields
For each URL we record HTTP response, canonical, robots directives, template type, internal links, and usage signals. Then we define the proposed destination in the new architecture. A page that returns 404 today may need investigation; a URL missing from the sitemap may still receive traffic or Googlebot requests. Absence from one source does not mean absence from the site.
Before and after cutover
The plan needs acceptance checks by template and by brand: redirects, canonicals, hreflang, structured data, sitemaps, and business pages. We freeze a baseline and repeat the checks after launch. Issues are grouped by pattern and severity so that engineering, SEO, and the newsroom work from the same list.
The value of the inventory is in making decisions visible: what stays, what changes, what retires, and who validates each exception.
