A Practical CMS Content Migration Plan (That Preserves SEO)

A CMS migration is rarely “just move the pages.” It is a change to your content model, your URLs, your editorial workflow, and often your site’s underlying assumptions about what a page is.

The good news: you can make migrations predictable. The trick is to treat content like data, decide what “correct” means before you copy anything, and rehearse the move with measurable checks.

This post walks through a practical migration plan that works for small teams and large sites alike. It focuses on preserving SEO fundamentals, minimizing broken links, and keeping editorial teams sane during the transition.

What a content migration is (and is not)

A content migration is the controlled transfer of content, structure, and meaning from one system to another. That includes not only body text, but also metadata, relationships, and presentation intent (like whether something is a “How-To,” a “Case Study,” or a “Product Page”).

It is not a copy-paste exercise. Copying pages into a new CMS without a plan typically breaks three things:

• Findability: URL changes and missing redirects lead to 404s and lost search equity.
• Consistency: headings, summaries, and structured fields become uneven across the site.
• Operations: editors lose confidence when content appears “mostly there” but is subtly wrong.

Think of migration as a small product launch: you define scope, create acceptance criteria, run tests, and ship.

Inventory and triage: the audit you actually need

Most teams overcomplicate audits. You do not need a perfect catalog of every historical artifact. You need enough information to make three decisions: what moves, what changes, and what dies.

Start with an inventory that captures, at minimum, the current URL, content type, owner, and a “keep/update/remove” decision. If you have time, add traffic or business value signals, but avoid spending weeks on analytics archaeology.

Real-world example: a services firm with 600 pages

Imagine a B2B services firm migrating from a legacy CMS to a modern one. They have 600 URLs: 200 blog posts, 120 service pages, 60 case studies, and a lot of outdated announcements.

In one working session per section, they label content:

• Keep as-is: evergreen case studies and core service pages.
• Keep but update: old posts with high inbound links, where headings and summaries need cleanup.
• Remove: event announcements and thin pages that do not serve a current purpose.

That triage immediately reduces migration risk because fewer pages means fewer edge cases.

URL and metadata mapping: the SEO safety net

For most sites, SEO impact is driven less by the CMS and more by what happens to URLs and on-page signals. Your goal is simple: users and crawlers should still find the same “things,” even if your CMS stores them differently.

Work through these elements explicitly:

• URL mapping: define the new canonical URL for every kept page. When URLs change, create a redirect map.
• Titles and meta descriptions: ensure they migrate into the correct destination fields and are not overwritten by templates.
• Headings: maintain a coherent H1 and H2 structure. Migrating rich text often introduces duplicated headings.
• Indexing rules: confirm that pages meant to be indexable stay indexable, and that “noindex” pages remain blocked.
• Internal links: plan to update links that point to old paths, not just rely on redirects.

A practical standard: every old URL should result in either (1) a 200 on the same content, (2) a 301 to the best equivalent, or (3) a deliberate 410/404 for removed content. Anything else is accidental.

Define a migration contract (schema + transformations)

A “migration contract” is the shared agreement between your old content and your new CMS: what fields exist, how they map, and what rules transform the data. Even if you are doing a manual migration, writing this down prevents drift and arguments later.

What to include in the contract

• Content types: the destination types (Post, Landing Page, Case Study) and the source types they pull from.
• Required fields: what must be present for a page to publish (title, slug, summary, hero text, category).
• Transform rules: how you normalize dates, strip junk HTML, convert shortcodes, and handle embedded media.
• Relationship rules: how you connect authors, categories, tags, and related content.
• Acceptance checks: what “done” means for a migrated page (for example, no empty summaries, correct canonical URL, correct status).

Here is a short, conceptual example of what this can look like. Keep it simple and editable; a document or spreadsheet is fine.

{
  "type": "CaseStudy",
  "source": "legacy.case_study",
  "fields": {
    "title": "source.headline",
    "slug": "transform.slugify(source.url_path)",
    "summary": "transform.trim(source.excerpt, 160)",
    "body": "transform.clean_html(source.body_html)",
    "industry": "map.lookup(source.vertical)",
    "published": "transform.to_boolean(source.is_public)"
  },
  "url": {
    "old": "source.full_url",
    "new": "/case-studies/{slug}/",
    "redirect": "301"
  }
}

This “contract” makes it obvious where problems will occur, like missing excerpts or inconsistent vertical labels.

Run a rehearsal migration before launch

A rehearsal migration is a full end-to-end run on a subset of content, using the same process you will use for the real move. The goal is to find surprises while changes are cheap.

Pick a sample that forces edge cases. A good rehearsal set includes:

• A few pages from each content type
• At least one very old page with messy formatting
• At least one page with heavy internal linking
• A page with embedded assets (downloads, tables, or special formatting)

Then evaluate with a short scorecard. For each migrated page, check: URL correctness, redirect behavior, title/description, headings, internal links, and publish status. If you cannot verify those quickly, your process is not ready.

Rehearsals also help editorial teams: they see the new workflow earlier and can request changes before the big cutover.

Common mistakes (and how to avoid them)

• Assuming the new CMS will “generate” the right SEO: templates cannot recreate missing summaries, broken headings, or sloppy slugs. Decide what fields must be curated.
• Ignoring content type differences: a “page” in one CMS might contain multiple concepts. Split or remodel content instead of forcing a bad fit.
• Redirects without intent: pointing many old URLs to the homepage is a common anti-pattern. Redirect to the closest equivalent page or retire content deliberately.
• Forgetting internal links: 301 redirects help, but they are not free. Update internal links so your new site is internally consistent.
• No ownership: if nobody owns decisions like “remove vs keep,” the migration becomes a parking lot of unresolved questions.

A quick way to reduce mistakes: define a single “source of truth” document for decisions and require that every exception is logged there.

When not to do a migration

Sometimes the best migration plan is to not migrate yet. Consider delaying or narrowing scope if any of these are true:

• You cannot freeze content changes: if hundreds of pages are being edited daily and you have no content freeze window, you risk moving stale content or duplicating work.
• Your new information architecture is undecided: migrating into an uncertain structure doubles work. Decide navigation and content types first.
• You do not have redirect capability: if the platform cannot support predictable redirects, you need a different approach or a different platform.
• Key stakeholders are unavailable: migrations need quick decisions. Long approval loops turn small issues into launch blockers.

If you must move platforms anyway, a safer alternative is a phased migration: migrate one section at a time and keep the rest stable until ready.

Launch checklist you can copy

Use this as a practical minimum. Print it, paste it into a ticket, or turn it into a shared doc.

1. Scope locked: final list of pages to keep, update, remove.
2. URL plan complete: old URL to new URL mapping for all kept pages.
3. Redirect map ready: verified for top pages and all high-value inbound links.
4. Metadata validated: titles, descriptions, canonical rules, and index/noindex settings checked.
5. Navigation and internal links: primary nav updated; internal links updated for major sections.
6. Editorial workflow tested: draft, review, publish, and rollback behavior confirmed.
7. Spot checks: sample pages across content types visually reviewed in the new theme.
8. Error handling: 404 page exists; removed content returns intentional 404/410 or redirects.
9. Post-launch monitoring plan: who checks broken links, who fixes redirects, and what “done” means after launch.

After launch, plan a short stabilization window where the only work is fixing migration defects. Treat it like a mini-sprint dedicated to quality.

Conclusion

A CMS migration goes smoothly when you treat content like structured data, keep URL intent intact, and rehearse the process before you cut over. You do not need a perfect plan, but you do need a written contract, clear ownership, and a checklist that defines “done.”

If you build those pieces, the migration becomes an engineering and operations exercise, not a scramble.

FAQ

Do I need to migrate every page?

No. Migrating less is often the fastest way to improve quality. Keep what serves a current purpose, update what earns its place, and retire what no longer fits.

Are 301 redirects enough to preserve SEO?

They are necessary but not sufficient. Redirects help retain value from old URLs, but you should also migrate or rewrite titles, summaries, headings, and internal links so the new site stands on its own.

Should I keep the same URL structure?

If the current structure is reasonable, keeping it reduces risk. If it is confusing or inconsistent, change it deliberately and maintain a complete redirect map so every old URL has a clear outcome.

How big should a rehearsal migration be?

Big enough to include every content type and multiple edge cases. For many sites, 30 to 60 pages is enough to expose most formatting, metadata, and workflow issues.

What is the single most important migration artifact?

A URL mapping and redirect plan tied to your content inventory. Without it, you cannot control how users and crawlers move from the old site to the new one.