CMS Migration During a Website Redesign: Planning Content, URLs and Workflows

A CMS migration during a website redesign is not simply a matter of exporting pages from one platform and importing them into another. It combines information architecture, content decisions, URL management, technical SEO, workflow design, analytics and launch operations.

The safest approach is to treat the migration as a controlled change to the whole publishing system. Before design and development are finalized, decide what content will be kept, revised, consolidated, redirected or retired. Then map the old and new URL structures, preserve important search signals, recreate measurement, and test the publishing workflow before launch.

This article focuses on implementation planning and decision support. For broader project scope, timelines and redesign considerations, see the website redesign overview.

What a CMS migration includes during a redesign

A CMS migration may involve moving to a different platform, changing hosting, rebuilding templates, reorganizing content or changing how teams publish and govern pages. A redesign often introduces several of these changes at once.

Typical migration work includes:

• Auditing existing pages, assets, metadata and structured content.
• Defining the future information architecture and content model.
• Mapping old URLs to new URLs or documenting valid retirements.
• Rebuilding templates, components, forms and navigation.
• Transferring, rewriting or consolidating content.
• Recreating canonical tags, schema, redirects and indexation controls.
• Reconnecting analytics, search tools, marketing integrations and consent systems.
• Testing editorial workflows, permissions, previews and approvals.
• Monitoring the new site after launch and resolving defects quickly.

The migration boundary should be written down early. A move from one CMS to another may be relatively contained if URLs and templates remain stable. A simultaneous change to domain structure, navigation, content hierarchy and page types creates substantially more risk because several variables change at once.

Start with an inventory, not a redesign mockup

The first practical deliverable should be a source-of-truth inventory. Export the current URL set from the CMS, crawl the live site, and compare the results with XML sitemaps, analytics landing pages and search performance data. No single source captures every page that matters.

Useful inventory fields include:

• Current URL and page type.
• Title, meta description, heading structure and canonical URL.
• Indexation status and response code.
• Organic entrances, conversions and important referral sources.
• Links from other site pages and known external links.
• Content owner, last review date and business purpose.
• Associated images, downloads, videos, forms or embedded tools.
• Proposed action: keep, revise, merge, redirect or retire.

Do not use traffic alone to determine value. A low-traffic page may support a sales process, answer a niche customer question, attract qualified links or provide context for a high-value page. Conversely, a page with visits may be outdated, duplicative or disconnected from current business priorities.

Classify content before moving it

Each URL should receive an explicit disposition. “Migrate everything” usually transfers obsolete content and creates unnecessary cleanup. “Start from scratch” can remove useful search equity and institutional knowledge.

Design the future content model before importing content

A CMS migration exposes the difference between page content and structured content. If every page is stored as a large body field, editors may struggle to reuse author information, case-study details, FAQs, service attributes or related resources consistently.

Define the content model before building the migration script. Document content types, required fields, optional fields, relationships, allowed components, image requirements and publishing states. A practical model might separate:

• Landing pages and service pages.
• Articles and resource pages.
• Case studies or project records.
• Authors, team members or subject-matter experts.
• FAQs, testimonials, downloads and related resources.

For each type, identify which fields are editorial, which are system-generated and which affect search presentation. Decide how redirects, canonical URLs, open graph fields, schema data and noindex controls will be managed inside the CMS rather than through ad hoc code or spreadsheets.

Migration scripts should transform data deliberately. A direct field-to-field import may preserve text while breaking links, formatting, image references, author relationships or taxonomy. Build a sample migration first, review it with content owners, and only then scale the process.

Plan URL changes as a separate workstream

URL mapping is one of the highest-risk parts of a CMS migration during a website redesign. Create a redirect map that lists every relevant old URL, its proposed new URL, the redirect status and the reason for the change.

A good mapping process follows these principles:

• Preserve URLs when there is no strong reason to change them.
• Map each retired URL to the most relevant equivalent, not automatically to the homepage.
• Use permanent redirects for genuine permanent moves.
• Avoid redirect chains by pointing old URLs directly to final destinations.
• Account for trailing slashes, capitalization, parameters, file extensions and legacy paths.
• Include PDFs, image paths, feed URLs and other indexable assets where appropriate.
• Remove internal links that still point to old locations.

A redirect is not a substitute for content relevance. If an old article has no equivalent, redirecting it to an unrelated service page may create a poor user experience and weak signal. Document the rationale for removals so future teams understand what changed.

Build canonical and indexation rules into templates

Canonical tags should be generated consistently from the final URL rules, not copied blindly from the old site. Check how the new CMS handles duplicate paths, filtered listings, preview URLs, pagination, language variants and trailing-slash conventions.

Also define indexation behavior for search results, internal filters, staging environments, thin taxonomy pages, attachment pages and unpublished content. Test that noindex directives, canonical tags and robots rules work together. A technically valid tag can still create confusion if it points to a page that is not indexable or does not represent the same content.

Preserve SEO and structured data deliberately

SEO preservation extends beyond redirects. Capture current title tags, descriptions, headings, internal links, image alternatives, schema properties and XML sitemap behavior before migration. These elements may be redesigned, but they should not disappear accidentally.

Create a preservation checklist covering:

• Page titles and meta descriptions.
• Primary headings and meaningful subheadings.
• Internal links and breadcrumb paths.
• Image filenames, alternative text and dimensions.
• Canonical tags and robots directives.
• Organization, article, breadcrumb, product or other applicable structured data.
• XML sitemaps and their last-modified behavior.
• Open graph and social sharing fields.

Schema should describe visible, accurate page content. Do not carry forward markup that no longer matches the redesigned page. Validate representative templates, including edge cases such as author pages, articles with missing images and pages with multiple content blocks.

For a related planning perspective, the article on website redesign and content migration can help connect editorial decisions to the broader redesign process.

Recreate analytics and conversion tracking before launch

Measurement often breaks when forms, buttons, URLs and page templates change. Document the current tracking setup before development begins, including analytics properties, tag-management rules, form events, phone clicks, downloads, search events, CRM handoffs and consent behavior.

For each important conversion, define the event name, trigger, parameters, destination system and test method. Then test both the technical event and the business outcome. An event may fire successfully while failing to send a lead to a CRM or while attributing the conversion to the wrong page.

Preserve campaign continuity where possible. Confirm that UTM parameters survive redirects, that referral exclusions remain appropriate, and that cross-domain measurement still works for payment, scheduling or application systems. A separate guide to analytics and tracking in a website redesign provides a useful companion checklist.

Test editorial workflows, not just page rendering

A CMS can produce visually accurate pages while still failing the people responsible for publishing them. Test the full workflow with representative users and realistic content.

Workflow testing should cover:

• Role permissions and approval stages.
• Drafts, scheduled publishing and unpublishing.
• Preview links and responsive previews.
• Revision history and rollback.
• Required fields and validation messages.
• Image cropping, compression and alternative text.
• Related content, taxonomy and author assignment.
• Redirect creation and URL editing permissions.
• Form ownership, notification routing and spam controls.
• Accessibility checks within reusable components.

Ask editors to complete common tasks without developer assistance. Record where they hesitate, where fields are ambiguous and where the system permits risky changes. Workflow defects become expensive after launch because they recur across every future publishing cycle.

Use staged migration and launch gates

Separate migration into repeatable stages rather than treating launch day as the first full rehearsal:

1. Discovery: inventory URLs, content, dependencies, tracking and integrations.
2. Modeling: define content types, fields, templates, workflows and URL rules.
3. Trial migration: import a representative sample and review transformations.
4. Content preparation: revise, approve, tag and resolve exceptions.
5. Full migration: load approved content and generate redirects.
6. Quality assurance: crawl the staging site and test templates, forms, tracking and permissions.
7. Cutover: freeze changes, migrate final deltas, switch systems and verify infrastructure.
8. Monitoring: review errors, indexation, rankings, conversions, speed and user feedback.

Use explicit launch gates. Do not approve a migration because the homepage looks correct. Require evidence that priority URLs resolve correctly, redirects work, canonical rules are valid, forms submit, analytics records events and editors can perform essential tasks.

Post-launch monitoring should be planned before cutover

The first days after launch are for observation and fast correction, not assumption. Prepare a dashboard or reporting routine that compares pre-launch baselines with post-launch behavior.

Monitor:

• Server errors, redirect errors and redirect chains.
• 404 pages and unexpected soft 404 behavior.
• Organic landing pages and indexation coverage.
• Search impressions, clicks and branded versus non-branded traffic.
• Form submissions, calls, downloads and other business conversions.
• Page speed, mobile usability and broken interactive elements.
• Analytics volume, attribution and consent-related changes.
• CMS publishing errors and editorial support requests.

Prioritize issues by business impact. A broken lead form, widespread redirect failure or accidental noindex rule should be addressed before minor visual inconsistencies. Keep a dated migration log so changes can be correlated with performance shifts.

Common CMS migration mistakes

Changing everything at once without a dependency map

Platform, navigation, URLs, content and measurement changes can interact in ways that are difficult to diagnose. Identify which changes are necessary and phase lower-value changes when practical.

Importing outdated content unchanged

Migration is an opportunity to remove duplication, clarify ownership and improve content quality. Set review rules for pages that have no owner, no current purpose or no approved destination.

Testing only the homepage and top templates

Many defects appear in less common page types, old campaign URLs, downloads, author records, filtered listings and forms. Test a representative sample that includes edge cases.

Leaving redirect mapping until the end

URL decisions influence navigation, content planning, analytics baselines and development. Start the map during discovery and keep it version-controlled.

Ignoring the publishing team

A workflow that looks efficient to developers may be difficult for marketers, subject-matter experts or compliance reviewers. Include actual editors in acceptance testing.

A practical readiness checklist

• Every important old URL has a documented disposition.
• New content types, fields and relationships are approved.
• Redirects point directly to relevant final URLs.
• Canonical, robots, sitemap and structured-data rules are validated.
• Internal links and navigation use final URLs.
• Forms, CRM connections and notifications are tested.
• Analytics and conversion events are verified in production-like conditions.
• Editors can create, review, publish, update and roll back content.
• Staging is blocked from search indexing and production is configured correctly.
• Monitoring owners, thresholds and escalation paths are assigned.

For organizations aligning migration with a broader technical build, the web development resource offers additional context. If the redesign also changes visual systems and reusable interface patterns, review the relevant design guidance alongside the technical plan.

Final takeaway

A successful CMS migration during a website redesign protects more than page content. It preserves useful URLs and search signals, gives editors a dependable workflow, reconnects measurement, and creates a clear operating plan for the weeks after launch. Treat inventory, content modeling, redirect mapping, SEO preservation, analytics and QA as connected workstreams from the beginning. When you need to evaluate the broader redesign scope, use the website redesign page as the next planning resource.