A Practical CMS Content Migration Plan (Without Breaking URLs)

Moving content between CMS platforms sounds straightforward: export, import, done. In practice, migrations are where good websites quietly lose years of discoverability and hard-earned trust.

The core challenge is not copying words. It is preserving meaning and behavior: what each piece of content is, how it is found, how it is linked, and how it is maintained after the move.

This post lays out a durable plan you can use whether you are moving from a legacy CMS to a headless CMS, consolidating multiple sites, or rebuilding a marketing website. The focus is on URLs, metadata, quality checks, and a workflow you can run repeatedly until it is correct.

Why CMS migrations fail (and how to avoid it)

Most migrations fail for one of three reasons: scope confusion, missing URL strategy, or lack of validation. Teams start with a “move everything” mindset, only to discover that the destination CMS has different content types, different routing rules, and different editorial expectations.

A practical way to avoid this is to treat the migration as a product: define what “done” means, define what must not regress, and then ship in controlled phases. That means you need a clear inventory, a mapping document, and a redirect plan before you move any content.

Real-world example: a regional training company has 600 blog posts, 80 course pages, and 200 “resource” PDFs. Their new CMS supports flexible page blocks, but it does not match the old “resource” structure. If they migrate blindly, resource pages may land as generic pages with missing downloadable files and no canonical URLs. If they plan first, “resources” become a dedicated content type with stable slugs and a consistent download field.

Inventory and content model mapping

Start with an inventory that is accurate enough to drive decisions. You do not need perfect data, but you do need coverage. At minimum, capture:

• All indexable URLs (pages that appear in search, not just drafts)
• Content type (blog post, landing page, documentation, product, author profile)
• Title, slug, publish status, and last updated date
• Key metadata (meta description, canonical URL if used, robots directives)
• Internal links count (which pages are heavily referenced)
• Owner (who can approve changes or deletions)

Map fields and behaviors, not just fields

When you map old fields to new fields, include behavior and presentation rules. A “body” field is not just text. It may contain embedded shortcodes, callouts, tables, or custom HTML that does not belong in the new system.

Write your mapping so it answers questions like:

• If the old CMS allowed arbitrary HTML, what is allowed in the new editor?
• How do you represent “featured image” if images are handled differently (even if you are not moving images yet)?
• Are tags and categories modeled the same way, and do they affect URL structure?
• What is the rule for authorship and bylines?
• How are “noindex” pages represented?

A good mapping document becomes your contract between content, engineering, and SEO concerns. If you ever need to rerun the migration, this is what makes it repeatable.

URL preservation and redirect strategy

URL changes are the most visible, most expensive failure mode. Even if search engines eventually catch up, humans do not. Bookmarks break. Old newsletters break. Support articles referenced in tickets break.

There are three practical strategies, listed from best to worst:

1. Keep URLs identical: same path, same trailing slash convention, same lowercase rules.
2. Keep most URLs, redirect the rest: preserve high-value paths, redirect legacy patterns to new ones.
3. Change everything: only acceptable if the old URLs are already a mess and you can tolerate a long recovery period.

Create a redirect plan as a dataset, not as a series of one-off decisions. You want a single source of truth that can feed your web server, CDN, or application routing.

# Conceptual redirect map (source -> destination)
"/blog/how-to-choose-a-crm"              -> "/blog/how-to-choose-a-crm/"
"/resources/employee-onboarding.pdf"     -> "/resources/employee-onboarding/"
"/category/marketing/page/2"             -> "/blog/?topic=marketing&page=2"
"/old-product/widget-2000"               -> "/products/widget-2000/"

Two details matter more than teams expect:

• Canonicalization: decide one URL format per page (with or without trailing slash, lowercase rules) and enforce it.
• Redirect chains: redirect A to B, not A to B to C. Chains slow users and dilute confidence during validation.

Metadata, on-page SEO, and structured data basics

Even if you are not doing “SEO work,” a migration changes page templates. Template changes are SEO changes. Plan to preserve the essentials:

• Title tags and meta descriptions where they existed (or establish a consistent fallback rule)
• Heading structure (avoid turning all headings into bold text or vice versa)
• Indexing controls (noindex, canonical URLs, pagination behavior)
• Internal linking (especially from evergreen pages to newer pages)

If your old CMS had custom fields powering structured data, or your templates emitted JSON-LD, treat that as part of “content behavior.” It is easy to lose during a redesign because it is not visible on the page.

A practical approach is to define “SEO parity checks” for a sample set of critical pages: compare old versus new title tags, meta descriptions, canonical URLs, and whether the page is indexable. You do not need a perfect match for every page, but you do need to avoid accidental regressions on your highest value content.

A migration workflow you can test and repeat

Successful migrations are rarely one big move. They are a loop: migrate a subset, validate, fix mapping rules, migrate again. The moment you treat it as repeatable, quality becomes achievable.

Conceptually, the workflow has four phases:

1. Extract: export content and metadata from the old CMS into a stable format (CSV/JSON), plus a URL inventory.
2. Transform: normalize fields, convert rich text, map taxonomies, and generate slugs and redirects.
3. Load: import into the new CMS with consistent content types and relationships.
4. Validate: check counts, spot-check rendering, verify redirects, and confirm indexing rules.

Hypothetical rollout plan for a small team:

• Week 1: migrate 20 high-traffic pages and 20 random pages to prove the workflow.
• Week 2: migrate all blog posts, validate redirects, and fix template parity issues.
• Week 3: migrate landing pages and resources, then handle edge cases.
• Week 4: final validation pass, freeze old content, cut over DNS or routing.

Copyable migration checklist

• Define scope: what content types are in, out, or archived.
• Export URL list and identify top pages by traffic or business importance.
• Draft content model in the new CMS (types, fields, relationships).
• Create a field-and-behavior mapping (including allowed formatting rules).
• Decide URL conventions (trailing slashes, lowercase, category paths).
• Build redirect dataset and include a rule for “unknown” or deleted pages.
• Run a pilot migration on a small slice and fix mapping issues.
• Validate: counts, rendering, internal links, canonical/noindex, and redirects.
• Plan editorial freeze window and a final delta migration for last changes.
• After cutover, monitor broken links and add redirects as needed.

Common mistakes to watch for

These are the failure patterns that show up across CMS migrations, even on experienced teams:

• Assuming “export/import” preserves meaning: rich text embeds, shortcodes, and custom blocks often need transformation rules.
• Changing URL formats without a redirect dataset: ad hoc redirects miss edge cases and create chains.
• Ignoring internal links: content might import fine but still references old URLs in the body text.
• Forgetting non-page content: author pages, tag pages, category archives, and search pages can be indexable too.
• Not handling drafts and duplicates: importing everything can publish old drafts or create multiple pages with similar titles.
• Skipping a freeze and delta plan: if editors keep publishing during migration, you will miss content unless you plan a final sync.

A simple mitigation is to keep a short “edge case backlog” as you pilot: every time you find a page that renders incorrectly, you add a named case (for example, “table-heavy posts” or “PDF resource pages”) and update the transformation rules until it is handled.

When not to do a CMS migration

Sometimes the best migration plan is not migrating. Consider alternatives if any of these are true:

• Your main pain is design, not content: if the CMS works, a theme or template refresh may solve most issues.
• You cannot commit time for validation: a rushed migration without QA is often worse than staying put.
• Your content strategy is undefined: migrating “everything” preserves past chaos. It can be better to prune and rebuild key sections intentionally.
• You need new features, not a new CMS: sometimes adding a search tool, a forms system, or a publishing workflow solves the problem.

If you do migrate, try to separate concerns: content migration first, then redesign second. Combining both increases variables and makes debugging harder.

Conclusion

A CMS migration is a data project disguised as a website project. The winning move is to define inventory, mapping, and URL behavior early, then execute the migration as a repeatable workflow with validation at every step.

If you do that, you can change platforms without losing what matters: stable links, understandable content types, and consistent metadata that supports both readers and search engines.

FAQ

How many redirects is “too many”?

There is no strict limit, but a large redirect map is normal for established sites. The real problem is redirect chains and missing high-value redirects. Aim for one-hop redirects and keep the map in a single, testable dataset.

Should we migrate comments, revisions, and drafts?

Only if they serve an ongoing purpose. For many sites, migrating published content plus essential author data is enough. Drafts and revisions can be exported for archive purposes without being imported into the new CMS.

Do we need to migrate tags and categories exactly?

Not always. If tag pages are indexable or heavily used for navigation, treat them as first-class content and preserve them. If tags are inconsistent and unused, a consolidation pass during migration can improve long-term maintainability.

What is the minimum validation we should do before cutover?

At minimum: verify redirects for your top pages, confirm canonical and noindex behavior on a sample set, and spot-check rendering for each major content type. Also check a handful of internal links inside page bodies.

How do we keep publishing during the migration?

Plan a short editorial freeze for cutover, then run a final “delta” migration of content changed since the last import. If you cannot freeze at all, you will need a more complex sync process and stricter coordination.