Migranetix
Start a migration

Website migration checklist

A practical website migration checklist

Use this checklist before, during, and after a CMS or website migration to assign owners, protect content and URLs, test staging, control cutover, and monitor the live site.

Turn the checklist into a working handover

Assign an owner and a place to record the result for each check. “Redirects done” is hard to review; a dated URL map with observed responses tells the next person what was actually tested.

Include one old article, one page with embedded files and any private or translated content in the trial. Keep unresolved findings alongside the launch decision. The SEO migration plan covers the page and indexing checks in more detail.

Start before migration work

Define scope, owners, and the baseline

Confirm the migration type

Record whether the project changes the CMS, domain, URL structure, hosting, frontend, content model, design, or several layers at once.

Name one accountable owner

Assign the person who can approve scope, resolve cross-team decisions, and make the final go or no-go call.

List delivery owners

Name technical, content, SEO, analytics, security, infrastructure, support, and business reviewers with clear responsibilities.

Capture the current baseline

Record traffic, conversions, indexed URLs, top landing pages, crawl findings, performance, forms, integrations, and known defects.

Define success and acceptance

Document required entities, critical journeys, acceptable exceptions, validation evidence, launch criteria, and stabilization expectations.

Choose freeze or delta rules

Decide whether publishing stops before extraction or whether changes will be captured in a final delta migration.

Discovery checklist

Inventory the source and prepare the destination

Inventory systems and environments

List production, staging, APIs, databases, file stores, CDNs, domains, DNS, repositories, third-party services, and responsible owners.

Inventory content and data

Count pages, posts, custom types, taxonomies, users, comments, products, files, revisions, languages, redirects, and relationship records.

Confirm source access

Test approved API, export, database, filesystem, crawl, and administrative access before relying on the migration schedule.

Verify backups and restore ownership

Confirm backup coverage, retention, restore steps, credentials, responsible operators, and the last successful restore test.

Prepare the destination model

Create and review target types, fields, taxonomies, relationships, users, permissions, templates, upload limits, and publishing workflows.

List functionality boundaries

Separate portable content from forms, search, commerce, memberships, authentication, integrations, personalization, and custom applications.

Review sensitive data

Identify private, personal, regulated, licensed, or unnecessary records and define access, transfer, staging, retention, and deletion rules.

Approve the launch window

Choose a lower-risk period and confirm availability for migration, infrastructure, editorial, SEO, support, and business decision owners.

Mapping checklist

Approve content, data, and relationship rules

Map every in-scope entity

Define the destination type, stable identifier, required fields, status, ownership, dependency order, and expected outcome.

Map fields and transformations

Document direct copies, format changes, normalized values, fallbacks, split or merged fields, and values that cannot transfer.

Map relationships

Cover parent-child hierarchy, authors, taxonomies, references, menus, attachments, related content, and cross-language associations.

Map editorial state

Preserve or intentionally transform published, draft, scheduled, private, archived, deleted, and revision requirements.

Map users and permissions

Define identity matching, authorship, roles, private access, account activation, and password limitations.

Map media and files

Set rules for file sources, filenames, MIME types, dimensions, alt text, captions, private assets, duplicates, and failed downloads.

Map metadata and URLs

Cover slugs, titles, descriptions, canonicals, robots rules, structured data, internal links, source URLs, and redirect targets.

Record exclusions and exceptions

List unsupported entities, source defects, manual work, destination limitations, accepted transformations, and decision owners.

Staging checklist

Run and review a representative dry run

Select representative records

Include simple, complex, old, recent, draft, private, media-heavy, multilingual, and relationship-heavy examples.

Reconcile each stage

Compare source, extracted, transformed, loaded, skipped, rejected, failed, and unresolved totals by entity.

Inspect destination records

Check values, statuses, dates, authors, taxonomies, relationships, files, metadata, URLs, and stable identifiers.

Review rendered pages

Open priority templates and edge cases across desktop and mobile, including navigation, content, media, links, and visible errors.

Test operational workflows

Verify preview, edit, publish, schedule, search, permissions, forms, integrations, notifications, and support procedures that are in scope.

Crawl the staging site

Find broken links, redirect chains, missing assets, duplicate metadata, wrong canonicals, accidental indexation, and inaccessible pages.

Retest systematic corrections

Repeat the same deterministic sample after mapping or code changes instead of accepting one successful rerun.

Approve the dry run gate

Document results, open exceptions, owners, severity, remediation, accepted limitations, and permission to prepare cutover.

SEO migration checklist

Protect URLs, crawlability, and measurement

Export the complete URL inventory

Combine sitemaps, analytics landing pages, Search Console data, crawl results, linked assets, and important manually maintained URLs.

Approve one-to-one URL mapping

Map each valuable old URL to the closest relevant destination and flag removed, consolidated, or intentionally excluded pages.

Prepare permanent redirects

Implement server-side permanent redirects, avoid irrelevant homepage redirects, and test status, target relevance, chains, loops, and query handling.

Update internal URL references

Change navigation, body links, canonicals, hreflang, structured data, feeds, media references, and campaign destinations to final URLs.

Review indexation controls

Remove staging noindex rules at launch where appropriate and verify robots.txt, meta robots, canonicals, authentication, and firewall access.

Prepare the new sitemap

Include canonical indexable URLs only, publish it at the expected location, reference it in robots.txt, and prepare Search Console submission.

Preserve metadata and structured data

Compare titles, descriptions, headings, social metadata, schema, image attributes, and page-specific indexation requirements.

Prepare measurement

Confirm GA4 consent behavior, key events, Search Console properties, conversion paths, annotations, dashboards, and launch-day owners.

Go or no-go checklist

Prepare cutover and rollback

Write the cutover runbook

List the execution order, commands or interfaces, expected durations, dependencies, owners, checkpoints, and communication path.

Confirm the final backup

Record the backup or snapshot timestamp, coverage, location, restore owner, access, and rollback decision deadline.

Confirm final or delta content

Close publishing or capture every change since the dry run, then reconcile the final migration scope.

Prepare infrastructure changes

Confirm hosting, DNS, TLS, CDN, caching, environment variables, domains, email, redirects, and monitoring changes.

Define rollback triggers

Agree which data, security, availability, conversion, or critical-journey failures require rollback rather than continued repair.

Run the pre-launch review

Verify approvals, unresolved blockers, accepted exceptions, support coverage, stakeholder availability, and the final go or no-go decision.

Launch-day checklist

Execute, record, and smoke-test the release

Follow the approved sequence

Record actual start and finish times, run IDs, operators, deviations, incidents, and decisions as cutover progresses.

Reconcile the production load

Confirm final loaded, skipped, rejected, failed, and unresolved outcomes before declaring content migration complete.

Test priority journeys

Check the homepage, key landing pages, navigation, search, forms, account paths, downloads, contact routes, and conversions in scope.

Test priority URLs and redirects

Sample high-traffic, linked, campaign, deep, parameterized, removed, and edge-case URLs from the approved map.

Check production controls

Verify canonicals, robots directives, sitemap, analytics consent, security headers, certificates, caching, monitoring, and error reporting.

Make a documented decision

Approve launch, continue under an exception plan, pause, or roll back based on the agreed criteria—not pressure or elapsed time.

First 24 hours

Watch the live site for immediate defects

Crawl old and new URL sets

Check destination responses, redirects, loops, chains, soft errors, canonical targets, broken links, and missing assets.

Review errors and infrastructure

Monitor 4xx and 5xx responses, application logs, CDN behavior, DNS, certificates, capacity, queues, and failed background jobs.

Confirm leads and conversions

Test forms, chat, email, analytics events, consent, CRM delivery, notifications, and other agreed conversion paths without polluting production data.

Inspect priority pages manually

Review business-critical, high-traffic, complex, private, multilingual, and media-heavy pages on representative devices.

Submit search signals

Submit the new sitemap, inspect priority URLs, and use the appropriate Search Console site-move workflow when domains change.

Triage with the exception register

Assign every issue a severity, impact, owner, response, target time, and decision on whether launch remains acceptable.

First 30 days

Monitor stabilization and close the migration

Track indexation and canonicals

Review discovered, crawled, indexed, excluded, redirected, duplicate, and canonical-selected URLs by important template or section.

Compare traffic and conversions

Use the recorded baseline to investigate meaningful landing-page, channel, device, geographic, and conversion changes without assuming every fluctuation is migration-caused.

Maintain redirects

Keep useful redirects available, monitor misses and chains, and update important external, campaign, profile, and internal links where possible.

Resolve migration defects

Correct agreed content, relationship, asset, URL, metadata, permission, workflow, and rendering defects within the support scope.

Review editor and support feedback

Capture publishing friction, missing records, customer reports, operational workarounds, and defects that automated checks did not expose.

Complete formal closure

Reconcile remaining exceptions, confirm temporary-data handling, hand over documentation, record acceptance, and assign deferred work.

Approval checklist

Collect evidence before final sign-off

Content and data acceptance

Approved reconciliation, representative samples, relationships, assets, metadata, exceptions, and responsible reviewer.

SEO acceptance

Approved URL map, redirect tests, internal links, canonicals, indexation rules, sitemap, measurement, and priority-page checks.

Technical acceptance

Approved availability, performance, security, integrations, workflows, monitoring, backups, and rollback disposition within scope.

Business acceptance

Approved priority journeys, conversion paths, support readiness, operational handoff, known limitations, and deferred work.

Final accountable sign-off

One named owner confirms the evidence, accepted exceptions, stabilization status, and formal project closure.

Checklist boundaries

What this checklist does not replace

A mapping contract

The checklist confirms mapping is approved; it does not define every source-to-target field, transformation, identifier, and relationship rule.

A validation report

The checklist names validation tasks; the report provides record counts, test evidence, exceptions, decisions, and sign-off.

Review validation evidence →

A cutover runbook

The checklist identifies launch controls; the runbook contains environment-specific commands, access, timings, owners, and rollback procedures.

Specialist implementation

Design, development, SEO remediation, infrastructure, security, analytics, and application work still require qualified owners and explicit scope.

Related planning

Turn the checklist into an approved migration plan

Migration timeline

Connect scope, readiness, dry runs, decisions, cutover, and stabilization to a realistic schedule.

Review timeline →

Migration validation

Define reconciliation, sampling, exception, and acceptance evidence for each delivery gate.

Review validation guide →

Migration methodology

Place checklist tasks inside discovery, mapping, dry run, cutover, and stabilization stages.

Review methodology →

CMS migration cost

See how volume, model complexity, media, SEO, cutover, and validation requirements affect scope.

Review cost factors →

CMS migration workflows

Review content migration deliverables, boundaries, supported paths, and destination requirements.

Review migration scope →

Security and data handling

Plan access, staging, sensitive-data controls, retention, backups, rollback, and incident ownership.

Review security controls →

Google site-move guidance

Review Google Search Central guidance for URL mapping, redirects, canonicals, sitemaps, Search Console, and monitoring.

Read Google guidance →

Clear answers

Website migration checklist questions

A website migration checklist is an ordered set of ownership, inventory, mapping, staging, SEO, cutover, launch, monitoring, and acceptance tasks used to control a website or CMS move.

Start before selecting the launch date. Scope, owners, baselines, source access, destination readiness, URL inventory, and acceptance criteria affect the plan and should not wait until cutover.

One accountable migration owner should maintain it, while technical, content, SEO, analytics, security, infrastructure, support, and business reviewers own their evidence and decisions.

Yes. A CMS, hosting, frontend, or content-model migration can affect data, relationships, rendering, workflows, permissions, analytics, crawlability, performance, and integrations even when public URLs remain stable.

The checklist coordinates tasks and owners across the project. Validation produces evidence that records, relationships, assets, URLs, pages, workflows, and exceptions meet agreed acceptance criteria.

At minimum, approve scope and mappings, complete a representative dry run, reconcile results, test priority journeys and URLs, prepare backups and rollback, assign launch owners, and resolve or accept blockers.

Immediate checks start during cutover and the first 24 hours. Indexation, redirects, traffic, conversions, errors, editorial feedback, and migration defects should continue through the agreed stabilization period.

No. A checklist reduces avoidable migration risk and improves diagnosis, but it cannot guarantee rankings, traffic, indexing speed, conversion performance, or platform equivalence.

Next step

Turn your checklist into a migration plan

Get an estimate based on the type, volume, and complexity of the data you want to migrate. Select the source and target systems, enter the migration details, and receive a calculated estimate. Online payment activation is being prepared. Until automated payment processing is available, plan activation and billing may be handled through a separate onboarding process.

Optional expert assistance

Calculate my migration estimateReview validation guide