CMS Migration Checklist: Content, Data, Users, and Workflows

A CMS migration moves the system that stores and organizes website content, supports publishing, and feeds the public website. On an established website, that system may also control relationships between records, editor permissions, forms, search, integrations, analytics, and important public-facing paths.

That makes the project more than exporting pages from one system and importing them into another. The new CMS needs to preserve what the website already does, improve the parts that have become difficult to operate, and give the team a reliable way to manage the site afterward.

This CMS migration checklist is for teams moving a substantial website with meaningful content, search visibility, publishing workflows, structured records, or connected business systems. It is not a universal launch checklist for a small site with a handful of static pages.

What a CMS migration actually changes

The CMS is only one layer of a website. A migration may affect several connected layers at once.

These layers are related, but they should not be treated as one task. They can change independently: a CMS migration may leave URLs untouched, while a redesign may change templates without replacing the CMS. A domain move may require redirects even when the content model stays the same, and a frontend rebuild may expose CMS limitations without changing the CMS itself.

Define which layers are changing before deciding what the migration needs to include.

Inventory the current CMS before choosing the new one

Start by documenting what the current system actually operates. A page count will not show the relationships, workflows, or dependencies that make a CMS difficult to replace.

Review the current system’s:

• Content types, fields, records, taxonomies, and references.
• Authors, categories, tags, locations, courses, reports, resources, and other structured records.
• Reusable components, shared fields, and content displayed in more than one place.
• Images, documents, videos, embeds, and other assets.
• URL patterns, templates, metadata, canonicals, redirects, and structured data.
• Search, filtering, directories, catalogs, and other discovery experiences.
• Forms, gated resources, account-aware content, and conversion paths.
• Users, roles, permissions, approval states, previews, and scheduled publishing.
• CRM, AMS, LMS, identity, payment, analytics, email, and other integrations.
• Deployment, hosting, caching, backups, monitoring, and emergency procedures.

For each area, record the owner, source of truth, current behavior, known problem, and what would break if the system changed without a plan.

Do not assume that an export from the CMS represents the full website. Some important behavior may live in templates, plugins, frontend code, scheduled jobs, external services, or undocumented workarounds.

Decide what moves, changes, combines, or retires

Migration planning should produce decisions, not just an inventory.

Classify each important item as:

• Preserve.
• Transform.
• Consolidate.
• Retire.
• Investigate.

Apply those decisions to more than individual pages. They may also apply to content types, records, taxonomies, assets, users, permissions, workflows, integrations, and URL patterns.

Use these questions to make the decision:

• What purpose does this content or capability serve?
• Does it receive organic traffic, conversions, backlinks, or internal use?
• Is it connected to other records or workflows?
• Does the new site have a relevant replacement?
• Is the current version accurate, maintainable, and useful?
• Would moving it unchanged preserve a problem that should be fixed?
• What happens to its URL, references, assets, and reporting if it is retired?

Not every record needs a one-to-one replacement. Do not delete or consolidate content solely because it has low recent traffic without understanding its role in navigation, topical coverage, internal linking, or business operations.

Design the target content model before importing content

The target CMS should not reproduce every past workaround automatically. Before importing the full dataset, define how the new system will represent the content the team needs to publish and maintain.

Document:

• Content types and their purpose.
• Required and optional fields.
• References between records.
• Taxonomies and controlled values.
• Reusable content and shared components.
• Author, date, status, and ownership fields.
• Asset relationships and file handling.
• URL fields and metadata inputs.
• Structured-data requirements.
• Preview, review, approval, and publishing states.

The model should be understandable to the people who operate the site. If editors cannot tell where information belongs, which record is authoritative, or how a change will appear publicly, the new CMS has not solved the operating problem.

Validate the model with representative records before migration. Include ordinary content and difficult content: records with missing fields, unusual formatting, several references, large assets, legacy embeds, or relationships to content that is being consolidated.

Map and transform the data

Content migration is rarely a direct copy. Fields may be renamed, combined, split, normalized, or removed. References may need to be resolved in a particular order. Assets may need new paths or a different storage model.

Document the transformation for:

• Source fields and target fields.
• Data-type changes.
• Dates, authors, categories, and taxonomy values.
• References and relationship resolution.
• Images, documents, videos, and embedded media.
• HTML cleanup and formatting changes.
• Internal links and asset references.
• Duplicate records and canonical records.
• Missing values and fallback behavior.
• Character encoding and special characters.
• Import order and dependencies.
• Stable identifiers and migration steps that can be safely repeated.

The migration process should be repeatable. If an import fails halfway through, the team should be able to correct the problem and run the affected step again without creating duplicate records or corrupting relationships.

Run a representative sample first. Compare the source and target records, fields, references, assets, metadata, and rendered pages before applying the transformation across the full dataset.

Migrate users, permissions, and editorial workflows

The new CMS must support how the team actually works after launch.

Review:

• User accounts and ownership.
• Roles and permissions.
• Draft, review, approval, and publishing states.
• Preview behavior.
• Scheduled publishing.
• Version history and audit trails.
• Author attribution.
• Media access and management.
• Redirect management.
• Access to gated or account-aware content.
• Administrator ownership and recovery access.

Preserving every article does not make the migration successful if editors cannot safely create, review, approve, and publish new work afterward.

Ask each publishing group to test the target CMS with realistic tasks. A marketing editor, publisher, course manager, association administrator, or person responsible for location content may use different fields, relationships, and approval steps.

Do not postpone permissions until after launch. Permission mistakes can expose restricted content, prevent routine publishing, or leave the company dependent on one person who understands the new system.

Reconnect integrations and website functionality

The CMS is often connected to systems that the migration itself does not replace.

For each integration, document:

• What data is sent to or received from the system.
• What event triggers the connection.
• Which credentials and permissions it uses.
• What happens when the connection fails.
• Who owns the integration.
• How it will be tested.
• What fallback process exists during launch.

Review integrations with:

• CRM and lead routing.
• AMS or member systems.
• LMS and course systems.
• Identity, SSO, and account access.
• Analytics, consent, and advertising platforms.
• Email and notification services.
• Search and filtering services.
• Payment systems.
• External APIs, webhooks, and scheduled jobs.

Test the behavior that visitors and staff rely on. A form can appear on the new site while sending incomplete data to the wrong system. A course page can look correct while its connection to enrollment or the LMS is broken. A directory can retain all of its records while its filters return incomplete results.

Protect URLs and search continuity

A CMS migration may leave visible URLs unchanged, or it may happen alongside changes to the information architecture, redesign, frontend, or domain. Treat those as separate decisions.

If the URL stays the same, validate the page on the new platform. If the path, domain, hostname, or protocol changes, map each old URL to its corresponding new destination or mark it for intentional retirement, then test the required permanent redirects. Also review:

• Internal links.
• Canonical URLs.
• XML sitemaps.
• Robots directives.
• Metadata.
• Structured data.
• Pagination and filtered URLs.
• Rendered content and links.
• Image and document URLs.
• Analytics and conversion tracking.

The Website Migration SEO Checklist covers this search-continuity work in greater detail.

Do not treat SEO continuity as a configuration setting or final checkbox that can be reviewed once at the end. Search behavior depends on the output of the new system, the relationships between pages, and whether important content and links still work.

Validate the migration in staging

Staging validation should cover representative content types, templates, workflows, integrations, and visitor or editor journeys.

Content and data checks

• Compare fields, references, taxonomies, authors, assets, and metadata.
• Check records with missing values, unusual formatting, and multiple relationships.
• Confirm that migrated content appears in every place where it is used.
• Check that internal links and embedded assets point to the correct locations.
• Confirm that each retired, consolidated, or transformed item matches its approved migration decision.

Editorial checks

• Test roles, permissions, approvals, previews, and scheduled publishing.
• Ask representative editors to complete ordinary publishing tasks.
• Confirm that authorship, version history, and ownership are correct.
• Test gated content and account-aware workflows.
• Verify that editors can find and update related records without developer help.

Public website checks

• Test templates, navigation, search, filters, directories, and catalogs.
• Submit forms and confirm routing, notifications, and tracking.
• Test mobile behavior, accessibility, performance, navigation, search, filters, forms, and other key interactions.
• Check CRM, AMS, LMS, identity, payment, email, and other integrations.
• Confirm analytics, consent, conversion events, and reporting continuity.

Search and technical checks

• Check status codes, redirects, canonicals, robots rules, and sitemaps.
• Validate metadata, structured data, rendered HTML, and JavaScript-dependent content.
• Check page, asset, and document URLs.
• Confirm that staging authentication, noindex directives, robots rules, and other test-environment restrictions will not reach production.

For a complex website, start with a representative sample. Correct the content model and transformation process first, then verify the import and validation steps before applying them across the rest of the site.

Plan the cutover and rollback

The launch plan should define the order of operations, monitoring responsibilities, and rollback criteria.

Before launch:

• Complete the final content freeze and backup.
• Run the final export and migrate any changes made since the initial import.
• Confirm that the latest content changes are included.
• Deploy and test redirects where URLs changed.
• Verify hosting, DNS, SSL, CDN, and server capacity where applicable.
• Confirm production canonicals, robots rules, sitemaps, and analytics.
• Test forms, lead routing, integrations, search, and gated experiences.
• Confirm editor access and launch ownership.
• Confirm access to the relevant Search Console and Bing properties.
• Define the conditions that require a pause, fix, or rollback.

Rollback is not simply turning the old website back on. The team should understand which content, user, permission, integration, and URL changes occurred during the cutover window. Preserve the access, backups, and deployment steps needed to reverse the change safely.

Monitor the website after launch

Post-launch monitoring is part of the migration plan. It is how the team finds problems that staging and launch checks did not expose.

Monitor:

• Crawl errors, unexpected status codes, and redirect failures.
• Indexing status, canonical behavior, and sitemap coverage.
• Search Console clicks, impressions, queries, and pages.
• Bing URL inspection and overall clicks, impressions, or visibility data where available.
• Organic landing pages and important templates.
• Forms, conversions, lead routing, and analytics events.
• Search, filtering, gated resources, and account access.
• Publishing, permissions, integrations, and editor reports.
• Customer, member, subscriber, or internal-team reports.

Separate a migration problem from changes in search demand, analytics tracking, or search visibility before making another large change. Compare affected and unaffected page groups, templates, workflows, and conversions. The Google traffic-drop guidance provides a useful starting point for investigating search changes.

When a CMS migration is not the right project

The current CMS may be viable if the actual problem is hosting, templates, plugins, deployment, governance, permissions, content quality, or one unstable integration.

Improving the current CMS may be the better project when:

• The content model still fits the team’s needs.
• Editors can publish safely after a contained workflow improvement.
• Performance problems are caused by hosting, templates, assets, or scripts.
• Integrations can be repaired or replaced without changing the platform.
• The team can maintain, secure, and hand off the system predictably.

A platform migration is more justified when the CMS repeatedly prevents the team from managing content, publishing reliably, connecting important systems, or adding capabilities to the website.

If the public experience and technical structure both need coordinated change, a website rebuild may be the better project. If the platform is the constraint, Valiance Labs helps companies plan and execute platform migrations. You can also read when to migrate off WordPress for a more specific platform-decision framework.