CMS Migration Checklist: The Complete 5-Phase Guide (2026)

A CMS migration has five phases: content audit, content model redesign, data transformation, SEO and URL preservation, and cutover. Most migrations fail in phase two — not phase five. This guide walks through every phase in the order you actually need to execute them, with the specific decisions that determine whether you end up with a cleaner system or just the same mess in a new container. If your team is handling the migration in-house, this is the checklist. If you're evaluating whether to hand it off, the Payload CMS migration service page covers what that engagement looks like.

---

I've run enough CMS migrations to know exactly where they break. The pattern is consistent: a company treats migration as a data transfer problem, copies their existing content structure into the new system, and ships a site that inherits every piece of technical debt from the old one. Six months later they're asking why the new CMS feels exactly as painful as the old one.

The real work of a migration isn't moving data. It's making the architecture decisions that the original CMS setup never got right. That happens in phase two, before a single ETL script runs. If you skip it or rush it, the rest of the checklist doesn't matter.

---

Before You Start: Is Migration the Right Move?

Migration is a meaningful investment of both capital and engineering time. It's worth doing when your current system has become a genuine bottleneck — not because someone on the team read about a new CMS and got excited.

Signals that migration is the right move:

Plugin debt that eats engineering capacity. If your team spends more time patching security vulnerabilities and fighting plugin conflicts than building features, the hidden cost of staying is higher than the migration cost.

SaaS API billing that scales faster than your traffic. Contentful and similar platforms charge per API record, per space, per environment. When those bills start forcing architectural compromises, you've crossed the threshold.

AI integration that your current CMS can't support. If you're trying to build custom AI agents, RAG pipelines, or semantic search and the CMS's closed ecosystem makes every integration fragile, you're fighting the wrong battle.

Multi-tenant or multi-market requirements. Managing multiple brands on a system that charges per site or per space doesn't scale. A unified backend with proper access control changes the economics entirely.

Signals that you should wait:

No internal developers. Code-first CMSes require engineering involvement. If your team doesn't have that capacity, a migration will fail at the maintenance phase even if the initial build goes well.

A genuinely simple site. Five static pages that change quarterly don't need a full migration. The ROI isn't there.

Budget constraints below the minimum threshold. A migration done cheaply enough to cut corners on SEO preservation and data integrity will cost more to fix than a proper migration would have cost.

---

The Two Migration Strategies: Big-Bang vs. Incremental

Every other checklist in this space skips this decision. It's the most important one you'll make before any technical work begins.

Big-bang migration means you build the new system in parallel, run a full cutover on a fixed date, and redirect traffic all at once. The old system goes dark. The new system goes live. This is simpler to manage and creates a clean break, but it concentrates all the risk into a single go-live moment. If something breaks at cutover, everything is broken.

Incremental migration means you run both systems simultaneously and route traffic progressively — one section, one content type, or one route at a time. You use nginx, middleware, or a reverse proxy to direct specific URLs to the new system while the rest still serve from the old one. The risk is distributed across multiple smaller cutovers. No single moment of maximum exposure.

Most companies with active publishing, e-commerce, or customer-facing systems should default to incremental. The parallel running period is longer and the routing logic adds complexity, but losing a week of revenue to a botched cutover costs more than the extra engineering time.

For incremental migrations, the checklist phases below still apply — they just repeat for each section of the site rather than running once for everything.

---

Phase 1: Content Audit and Inventory

Before a line of code is written, you need to know exactly what you're migrating. This sounds obvious. It almost never gets done properly.

The deliverable is a content inventory: every content type, every field, every asset, and every piece of content that has ever been published. Most teams discover during this phase that their CMS holds years of accumulated content that nobody has looked at since it was published. Blog posts from 2014. Campaign landing pages for offers that ended three years ago. Product pages for items that are no longer sold.

The harder task in this phase isn't cataloging what exists — it's deciding what shouldn't migrate at all.

ROT analysis (Redundant, Obsolete, Trivial) is the right framework here. For each content type, you're asking: is this content still accurate, is it still relevant to the business, and does it have any meaningful traffic or conversion value? Content that fails all three criteria stays behind. The new system should start cleaner than the old one, not inherit its full archive indiscriminately.

A practical approach: export your full URL list, cross-reference it against Google Search Console for trailing 90-day click data, and flag anything with zero traffic and no strategic reason to exist. You'll typically eliminate 20–40% of the content inventory before migration even begins. Every page you don't migrate is a page you don't have to transform, test, redirect, and maintain.

Phase 1 checklist:

• Full content type inventory documented
• Field-by-field catalog for each content type
• Asset inventory (images, PDFs, video embeds, file attachments)
• Internal link map (pages that reference other pages)
• ROT analysis complete — "do not migrate" list finalized
• Content that remains tagged by priority (must-have at launch vs. can migrate post-launch)

---

Phase 2: Content Model Redesign

This is the phase that determines whether the migration was worth doing. It's also the phase most teams underinvest in.

Your current CMS has a content model — even if nobody consciously designed it. WordPress stores content as post types with custom fields and metadata scattered across a dozen tables. Contentful has content types with reference fields pointing to other content types. Sanity has schemas with Portable Text blocks that have evolved through years of editorial decisions. The common thread is that all of them reflect the decisions (and compromises) made by whoever set up the CMS, often years ago, often without a clear architectural intent.

Migrating that model directly into a new system preserves every mistake.

The right approach is to treat the new system's content model as a greenfield design that happens to need to accommodate your existing content. Start with what the business actually needs the content to do — not what the current CMS happens to store. Define your collections, your fields, your relationship structure, and your access control model as if you were starting fresh. Then map your existing content to that new structure.

For teams moving to Payload CMS, this means designing typed TypeScript collections that reflect your actual content relationships. A product page isn't just a post with a custom field — it's a typed collection with specific fields, specific relationships to other collections (categories, variants, related products), and specific access control rules. The admin interface your editors use every day is generated directly from that TypeScript definition.

The hard work in this phase is handling the cases where old content doesn't map cleanly to the new model. WordPress often stores rich content as HTML blobs in the post content field — years of Gutenberg and Classic Editor output that needs to be parsed and converted to structured blocks. Contentful's Rich Text JSON format has a specific structure that needs to be converted to Payload's Lexical format. Sanity's Portable Text blocks map reasonably well to Lexical but still require a transformation pass.

Every edge case you identify in this phase — malformed HTML, inconsistent field usage, broken internal links, embedded shortcodes — needs a transformation rule before the scripting phase begins. Discovering them in phase three, mid-import, is expensive.

Phase 2 checklist:

• New content model designed independently of old CMS structure
• Collections and globals defined in the target system
• Field types selected for each piece of content (rich text, relationship, array, block, etc.)
• Relationship mapping complete (which collections reference which)
• Access control model defined
• Content type mapping table: old content type → new collection, field by field
• Edge cases and exceptions documented with transformation rules
• Rich text conversion strategy defined (HTML/portable text/rich text JSON → target format)

For platform-specific guidance on the content model mapping step, the WordPress to Payload migration guide, Contentful to Payload migration guide, Sanity to Payload migration guide, and Strapi to Payload migration guide cover the specifics for each source platform.

---

Phase 3: Data Transformation and Scripting

With the content model defined and every edge case documented, the technical extraction and import work can begin.

The approach is ETL: extract data from the source system, transform it to match the new schema, and load it into the target. For most CMS migrations, this means custom Node.js scripts that hit your source system's API (REST or GraphQL), apply transformation logic for each content type, and use the target system's API to create records in the correct structure.

For Payload CMS, the Local API is the right tool for the import phase. It bypasses HTTP overhead, runs in the same Node.js process, and gives you full access to hooks and validation — which means your imported content goes through the same data integrity checks as content created through the admin UI.

A few practical notes on running the import reliably:

Start with a subset. Run your first import script against 5–10 records of each content type, verify the output in the admin UI, and fix transformation issues before processing the full dataset. The edge cases you documented in phase two will show up immediately and are far cheaper to fix on 10 records than on 10,000.

Handle relationships in the right order. Collections that other collections reference need to exist before the referencing records are created. Map your dependency graph before you write the import scripts and run collection imports in the correct sequence.

Log everything. Every record that fails transformation, every field that falls back to a default, every relationship that can't be resolved — all of it needs a log entry. You'll need this log to verify completeness and to catch data integrity issues before cutover.

Assets are usually the most time-consuming part. Images, PDFs, and other media files need to be downloaded from the source, uploaded to your new storage layer, and their references updated in the transformed content. For large asset libraries this step dominates the total import time.

Phase 3 checklist:

• Extraction scripts written for each content type
• Transformation logic covers all edge cases documented in Phase 2
• Import scripts written using target system's API/local API
• Dependency order for collections mapped and respected
• Subset test import run and verified
• Asset migration script written and tested
• Full import run in staging environment
• Import logs reviewed — all failures resolved or explicitly accepted
• Record count reconciliation: source count vs. target count per content type

---

Phase 4: SEO and URL Preservation

The biggest risk in any CMS migration is losing search rankings. It's also the most predictable risk — which means it's entirely preventable with the right preparation.

The core requirement is 1:1 URL mapping. Every URL that existed in the old system and had any meaningful traffic needs to either exist in the new system at the same path or have a 301 redirect to its new location. A 301 redirect tells search engines that the content has permanently moved, passes the ranking equity of the old URL to the new one, and ensures that any bookmarks or external links don't result in 404 errors.

The mapping process starts from the content inventory you built in Phase 1. For every URL in the old system that you're migrating, document the old URL and the new URL it will resolve to. For content you've decided not to migrate, decide whether to redirect to the nearest relevant page or let it return 404 — the latter is appropriate for content that was never indexed or has no ranking value.

The implementation depends on your infrastructure. For an incremental migration, you're adding redirects progressively as each section cuts over — routing specific URL patterns to the new system while others still hit the old one. For a big-bang migration, you're implementing the full redirect map at cutover. In both cases, the redirect map needs to be tested in staging before it touches production.

Beyond redirects, metadata preservation matters. Page titles, meta descriptions, canonical tags, and schema.org structured data should all be preserved or improved during migration. Most migrations that cause an SEO dip do so because content was migrated without its metadata — the content arrived, but the signals that told Google what it was didn't come with it.

For incremental migrations, there's an additional concern: duplicate content during the parallel running period. While both systems are live, you need to ensure that content served from the old system has canonical tags pointing to the final URL in the new system, or that the old system's pages are noindexed during the transition. Running two versions of the same content without a canonical signal is the fastest way to lose ranking equity you've spent years building.

Phase 4 checklist:

• Full 301 redirect map built from content inventory
• Old URLs with no migration path — decision documented (redirect or 404)
• Redirect map tested in staging (no redirect chains, no loops)
• Page titles and meta descriptions confirmed present in new system
• Canonical tags configured correctly
• Schema.org structured data preserved or improved
• XML sitemap updated for new URL structure
• For incremental migrations: canonical/noindex strategy for parallel period defined

---

Phase 5: Staging, Cutover, and Stabilization

Everything in phases one through four has been preparation. Phase five is execution — and the goal is to make it boring.

The parallel running period is the safety net. Before any production traffic changes, the new system runs in staging with a full copy of the migrated content, accessible to your team for verification. This is not user acceptance testing of the UI — it's data integrity verification. You're checking that every record migrated correctly, that every relationship resolved correctly, that every redirect works, and that every piece of metadata arrived intact.

The content freeze is the mechanism that makes cutover clean. At a fixed point before the final import — typically 48–72 hours before DNS change — the old system goes into read-only mode. No new content is published, no existing content is edited. This ensures that the final delta import (the pass that catches any content created after the initial bulk import) doesn't miss anything.

For incremental migrations, "cutover" is a series of smaller events rather than a single moment. Each section of the site cuts over independently — you update the routing configuration to send a specific URL pattern to the new system, verify it's working correctly, and move on to the next section. The content freeze applies per-section rather than site-wide.

The go-live sequence for a big-bang cutover:

1. Final delta import from source system
2. Verify record counts and spot-check content in staging
3. DNS change (TTL should have been reduced to 5 minutes 48 hours prior)
4. Verify redirects are firing correctly on production
5. Check Google Search Console for crawl errors within 24 hours
6. Monitor Core Web Vitals and ranking positions for 2–4 weeks post-launch

The stabilization period is 2–4 weeks of active monitoring. Most ranking fluctuations after a well-executed migration are temporary — Google re-crawls, reassesses, and typically restores positions within a few weeks. What you're watching for is anything that shouldn't fluctuate: a sudden drop in a previously stable high-traffic page, crawl errors that indicate broken redirects, or 404s that indicate URLs that weren't in your redirect map.

Phase 5 checklist:

• Staging environment fully populated with migrated content
• Data integrity verification complete (record counts, spot checks, relationship checks)
• All team members have verified their content sections in staging
• DNS TTL reduced 48 hours before cutover
• Content freeze date communicated to editorial team
• Final delta import scripted and tested
• Go-live sequence documented and rehearsed
• Monitoring setup: GSC crawl errors, Core Web Vitals, ranking tracking
• Rollback plan documented (how to revert DNS if critical issues emerge within first hour)

---

The Full CMS Migration Checklist

For reference, the complete checklist across all five phases:

Phase 1 — Content Audit

• Content type inventory documented
• Field-by-field catalog complete
• Asset inventory complete
• Internal link map built
• ROT analysis complete — do-not-migrate list finalized
• Remaining content tagged by launch priority

Phase 2 — Content Model Redesign

• New content model designed for target system
• Collections and globals defined
• Field types selected
• Relationship mapping complete
• Access control model defined
• Content type mapping table built (old → new, field by field)
• Edge cases documented with transformation rules
• Rich text conversion strategy defined

Phase 3 — Data Transformation

• Extraction scripts written per content type
• Transformation logic covers all documented edge cases
• Import scripts using target API/local API
• Collection dependency order respected
• Subset test import run and verified
• Asset migration script tested
• Full staging import complete
• Import logs reviewed
• Record count reconciliation complete

Phase 4 — SEO Preservation

• 301 redirect map built
• Unmigrated URLs — redirect or 404 decision documented
• Redirect map tested in staging
• Metadata confirmed in new system
• Canonical tags configured
• Structured data preserved
• XML sitemap updated
• Parallel period canonical/noindex strategy (incremental only)

Phase 5 — Cutover

• Staging data integrity verification complete
• DNS TTL reduced 48h prior
• Content freeze communicated
• Delta import scripted and tested
• Go-live sequence documented
• Monitoring configured
• Rollback plan documented

---

FAQ

How long does a CMS migration take?

For a mid-sized site (500–5,000 pages, standard content model), plan for 8–12 weeks end-to-end. The content audit and content model redesign in phases one and two typically take longer than teams expect — two to three weeks for a thorough job. The scripting and import phase depends heavily on how clean the source data is. Enterprise migrations with custom integrations, multi-tenant architecture, or high-volume datasets run 12–20 weeks. Timelines compress when phase two is rushed and expand when edge cases surface mid-import.

Will we lose SEO rankings when we migrate?

Not if phases four and five are executed correctly. A well-implemented 301 redirect map passes ranking equity to new URLs. Improving page speed and structured data during the migration often produces an SEO lift in the weeks after launch. The risk is concentrated in two areas: missing URLs in your redirect map (which produce 404s) and metadata that didn't migrate with the content (which weakens the ranking signals for individual pages). Both are preventable with the verification steps in the checklist.

Can we migrate without rebuilding the frontend?

Yes. If you already have a modern React or Next.js frontend consuming your old CMS via API, you can swap the data source from the old CMS to Payload without touching the frontend. The work is purely on the backend: new Payload installation, content model design, data import, and API endpoint mapping. Most teams choose to rebuild the frontend simultaneously to take advantage of Payload's Next.js integration, but it's not a requirement.

What's the hardest part of migrating from WordPress?

WordPress stores rich content as HTML in the post content field — years of Gutenberg blocks, Classic Editor output, shortcodes, and inline styles that need to be parsed and converted to structured blocks. The transformation scripts for this step are the most complex part of a WordPress migration. Custom post types with ACF fields are usually straightforward; the post content blob is where the edge cases multiply. See the WordPress to Payload migration guide for the specifics.

When does incremental migration make more sense than big-bang?

When any of the following apply: the site has active e-commerce or transactional flows that can't have downtime, the editorial team publishes daily and can't freeze content for a week, the existing system has integrations with CRMs or marketing tools that need to stay live during transition, or the team has limited QA capacity and needs to verify each section before moving to the next. The routing complexity of incremental migration is a known cost. The risk of a botched big-bang cutover on a live business is an unknown cost with a potentially very high ceiling.

---

When to Hand This Off

The content audit and SEO phases are largely systematic — given the right tools and enough time, a capable team can work through them. The content model redesign in phase two is where specialist knowledge makes the biggest difference. Getting the collection structure, relationship model, and access control right the first time prevents expensive re-architecture later. Getting it wrong means running the migration a second time or living with a system that accrues new technical debt from day one.

If your team is hitting uncertainty in phase two — how to model this content type, how to handle this relationship, how to structure access control for this workflow — that's the engagement point. The $500 System Mapping Session is a 60-minute architecture session that works through exactly these decisions. It applies toward any larger engagement if the project moves forward.

For teams that want the full migration handled end-to-end, the Payload CMS migration service covers principal-led migrations from WordPress, Contentful, Sanity, Strapi, AEM, Wix, and Drupal — architecture-first, no handoffs.

---

Conclusion

A CMS migration done well leaves you with a cleaner system, better-structured content, and an architecture that can actually support where the business is going. The checklist isn't long, but phase two — content model redesign — is the one that requires the most care and produces the most leverage. Every decision you get right there compounds positively through phases three, four, and five.

The platforms you can migrate to are ultimately secondary to the quality of the architecture decisions you make before the first import script runs.

Let me know in the comments if you have questions about any of the phases, and subscribe for more practical development guides.

Thanks, Matija