CMS Migration Content Inventory: Build a Safe Map
- Inventory every public URL before deciding what moves
- Collect URLs from more than one source
- Give every row enough context
- Normalize URLs without erasing distinctions
- Assign one approved action per item
- Map content components, not just body text
- Build the redirect map before launch
- Validate a representative sample early
- Control the cutover
- Close rows only with evidence
Inventory every public URL before deciding what moves
A CMS migration content inventory is a read-only map of current URLs, page types, status, ownership, dependencies, traffic relevance, and intended destination. Build it before changing content or infrastructure, then assign each item an explicit action: migrate, merge, redirect, archive privately, or retire through an approved process. Never delete the source because a spreadsheet row says “done”; verify the new site and the rollback plan first.
CMS, hosting, database, DNS, and deployment procedures vary. Use current official documentation and qualified administrators for production changes. Back up first and test restoration, not merely backup creation.
Collect URLs from more than one source
No single export necessarily contains the full site. Combine read-only sources appropriate to the environment:
- CMS content export or listing;
- current XML sitemap where used;
- analytics landing-page reports;
- search-performance URL reports;
- server or CDN request logs when authorized;
- internal crawl of public pages;
- navigation, footer, and manual campaign lists;
- media library and downloadable-file listings;
- redirect configuration and known vanity URLs.
Respect access controls and personal data. Do not crawl restricted areas or export private user content without authorization and an approved handling plan.
Give every row enough context
Recommended fields include:
| Field | Purpose |
|---|---|
| Current URL | Exact source address |
| Page type | Article, landing page, profile, file, form, taxonomy |
| Status | Public, draft, redirected, restricted, error |
| Title and owner | Identification and decision responsibility |
| Last meaningful review | Freshness evidence, not automatic quality |
| Incoming links | Known navigation and internal dependencies |
| Media or form dependencies | Assets and functions that must move |
| Proposed action | Migrate, merge, redirect, archive, retire |
| Destination URL | Approved future address |
| Validation status | What has been tested and by whom |
Keep decisions and facts separate. “Low traffic” is an observation from a named period; “retire” is a decision requiring approval and dependency checks.
Browse site maintenance for more evidence-first workflows.
Normalize URLs without erasing distinctions
Record protocols, hosts, paths, trailing slashes, query parameters, case differences, and fragments as they currently behave. Some variants may resolve to one canonical page; others may produce genuinely different content or tracking.
Do not merge rows solely because they look similar. Test current responses and canonical signals using authorized tools. Preserve query patterns required by search, forms, campaigns, filters, or integrations until owners confirm their future handling.
Assign one approved action per item
Use definitions the migration team agrees on:
- Migrate: recreate the page and its required function at an approved destination.
- Merge: combine distinct useful material into one destination with ownership and redirect decisions.
- Redirect: route an old public URL to a relevant replacement under the approved redirect standard.
- Archive privately: preserve for records without presenting it as current public content.
- Retire: remove public availability only after approval, legal retention review, dependency checks, and rollback planning.
Retirement and bulk redirects are destructive production changes. They require exact target lists, backups, review, and authorization. A redirect to an unrelated homepage is not a meaningful substitute for a missing page.
Map content components, not just body text
A page may depend on author records, taxonomies, reusable blocks, embeds, forms, downloads, image transformations, scripts, structured data, comments, permissions, and scheduled states. Note each dependency and its owner.
Identify personal or regulated data before export. Follow organizational policy and applicable law for retention, minimization, transfer, and deletion. Generic migration instructions cannot determine those obligations.
Build the redirect map before launch
For every approved URL change, map one old URL to the most relevant new destination. Check for chains and loops in staging. Preserve query handling only where intended and ensure the destination returns the expected public result.
Do not deploy redirects from an unreviewed concatenation formula. Special characters, encoding, patterns, and server syntax differ. Generate configuration only through the current platform’s documented method and have a qualified administrator review it.
Validate a representative sample early
Before moving everything, test examples of each content type and edge case: long articles, galleries, downloads, forms, special characters, restricted pages, redirects, metadata, and pages with many internal links.
Use the CMS pre-publish checklist on migrated samples. Compare source and destination for content meaning, media, accessibility, canonical settings, structured fields, and interactive behavior.
Control the cutover
Define a content freeze or change-capture process so edits made during migration are not lost. Record who approves launch, how DNS or routing will change, what monitoring will run, and exactly how rollback works.
DNS, database, file deletion, and production configuration changes can interrupt service or destroy data. They belong to authorized administrators using validated targets, current documentation, backups, and a tested recovery procedure.
After cutover, test priority URLs, redirects, forms, assets, search visibility controls, logs, and error reports. Keep the source environment intact for the approved fallback period; do not erase it to celebrate early.
Close rows only with evidence
A migrated row is complete when its destination works publicly as intended, required content and components are present, internal links are updated, redirect behavior is correct, ownership is recorded, and the reviewer has logged evidence.
Continue monitoring errors and missed URLs after launch. New findings return to the inventory with an owner and action. The sheet is not merely a pre-migration list; it is the migration’s memory, which is useful because production cutovers are not famous for improving anyone’s recall.