The WordPress migration checklist (free download)

A site migration goes wrong in the gaps — the redirect nobody set, the meta description that got regenerated, the page that quietly 404s three weeks after launch. The fix is not talent or luck. It is a checklist you run every time, whether the site has five pages or five hundred. Below is the one we work through on every WordPress rebuild; grab the printable version to tick off as you go.

The five stages of a clean migration

Every migration moves through the same five stages. Skipping straight to 'move the content' is what causes the post-launch traffic dip. Treat these as gates: do not start stage three until stage two is signed off.

1. 1Before you start — confirm the stack, export your ACF field groups, and back everything up.
2. 2Inventory and URL mapping — crawl the old site and decide where every URL lands.
3. 3Migrate the content — classify each section into the right ACF block and import as drafts.
4. 4Protect your SEO — carry over metadata, set 301s, rebuild structured data.
5. 5Launch and verify — submit the sitemap, check redirects, and watch Search Console.

Stage 1: Before you start

Rushing past preparation is how you migrate the wrong environment or discover mid-project that the new build is missing a block type for half the homepage.

• arrow_rightConfirm WordPress, PHP and hosting requirements on staging and production.
• arrow_rightExport ACF field groups as JSON — see ACF JSON export explained.
• arrow_rightFull backup of old site: database, uploads, wp-config. Store off-server.
• arrow_rightDocument active plugins, especially SEO, forms, caching and security.
• arrow_rightAgree URL structure with the client before design locks navigation.
• arrow_rightSet up staging that mirrors production PHP version and permalink settings.
• arrow_rightIdentify integrations: CRM, analytics, payment gateways, email.

Stage 2: Inventory and URL mapping

You cannot redirect what you have not listed. Crawl the old site and export every indexable URL — pages, posts, categories, tags, custom post types, paginated archives and PDFs if they rank.

1. 1Crawl with Screaming Frog, Sitebulb or your migration tool.
2. 2Export sitemap and compare against crawl — find orphans.
3. 3For each URL, assign: keep same path, new path, merge with another page, or 410/remove.
4. 4Build redirect map CSV: old path, new path, status code. See redirect map guide.
5. 5Flag high-traffic and high-converting URLs for side-by-side QA after migration.
6. 6Note pages with query strings or faceted URLs — they often need explicit rules.

Stage 3: Migrate the content

Content migration is where builder shortcodes, broken images and mangled layouts appear. The goal is drafts on staging that an editor can open in Gutenberg — not a one-shot live import.

• arrow_rightRegister target ACF blocks on staging; confirm JSON matches production plan.
• arrow_rightCrawl rendered front-end pages, not raw shortcode soup in the database.
• arrow_rightClassify each section into a block; low-confidence sections fall back to editable text.
• arrow_rightImport as drafts — never straight to publish.
• arrow_rightSideload images into the new Media Library; verify attachments.
• arrow_rightRewrite internal links to new paths during import.
• arrow_rightPreserve categories, tags and custom fields where the new structure supports them.
• arrow_rightRun shortcode cleanup after builder deactivation.

Full workflow: how to migrate a WordPress site into ACF blocks. Leaving Elementor, Divi, WPBakery or Avada? Use the builder-specific guides — the checklist stages are the same, only the source markup differs.

Stage 4: Protect your SEO

Search engines have years of equity tied to your URLs, titles and links. Carry it over deliberately.

1. 1Migrate Yoast or Rank Math titles, descriptions and canonicals per page — Yoast preservation guide.
2. 2Import 301 redirect map into Redirection, Rank Math or server config.
3. 3Maintain one H1 per page and logical heading hierarchy.
4. 4Rebuild structured data: Organisation, Article, FAQ, Product as applicable.
5. 5Set self-referencing canonicals on every indexable URL.
6. 6Update robots.txt and XML sitemap for new paths.
7. 7Keep or improve Core Web Vitals — migration is not an excuse for a slow launch.

Companion reading: rebuild a WordPress site without losing SEO.

Stage 5: Launch and verify

Launch day is an exam, not a finish line. Run the migration QA checklist before DNS moves.

• arrow_rightPre-launch crawl on staging: 404s, redirect chains, broken images.
• arrow_rightSpot-check top 20 URLs by traffic side by side with old site.
• arrow_rightTest forms, search, menus and ecommerce checkout on mobile.
• arrow_rightDNS cutover with TTL lowered in advance.
• arrow_rightSubmit XML sitemap in Google Search Console.
• arrow_rightSpot-check old URLs return 301 to correct destinations.
• arrow_rightWeek one: second crawl, fix stragglers, monitor Coverage report.
• arrow_rightWeeks 2–4: post-launch monitoring for rankings and crawl anomalies.

Why a checklist beats memory

Migrations are bursty work — three in a month, then none for a quarter. That cadence is exactly when details get forgotten. A written checklist turns a high-stakes, infrequent task into a routine one.

• arrow_rightMakes invisible steps — redirects, canonicals, structured data — impossible to skip.
• arrow_rightWorks as a handover artefact; a teammate can pick up mid-project.
• arrow_rightDoubles as a client-facing scope document so expectations are set upfront.
• arrow_rightCreates an audit trail for regulated clients who need documented process.

If you want to automate the heaviest stages — crawling, classifying content into ACF blocks, sideloading media and generating the redirect map — that is what AIRA does. The checklist still applies; AIRA handles the slow parts so your team focuses on review and launch.

Checklist by site type

Marketing site (page builder source)

Add builder-specific migration guides to stage three. Budget extra review on homepage and landing pages. Plan header, footer and global elements as template parts — they do not live in page body migration alone.

Ecommerce (WooCommerce)

Product URLs, category archives, cart and checkout testing are launch blockers. Redirect every product and category slug. Verify schema for Product and BreadcrumbList.

Multisite or multilingual

Per-site inventory, hreflang, and language-specific redirects. WPML adds migration volume — extend timelines in stage three, not launch weekend.

Pre-migration backup checklist (detail)

Backups are stage one for a reason. A migration without a restorable old site is a one-way door.

1. 1Full database export (mysqldump or host backup tool).
2. 2wp-content/uploads directory — often larger than the database.
3. 3wp-config.php and .htaccess for rewrite rules reference.
4. 4List of active plugins with versions.
5. 5DNS and SSL certificate expiry dates.
6. 6Export redirect rules from Redirection or Rank Math on old site.

Redirect map quality checks

Before importing redirects to production, validate the CSV on staging:

• arrow_rightNo redirect loops (A → B → A).
• arrow_rightNo chains longer than one hop for internal navigation targets.
• arrow_right404 old URLs you care about each have a destination or deliberate 410.
• arrow_rightTrailing slash behaviour matches new site permalink settings.
• arrow_rightWWW and non-WWW consolidated to one canonical host.

Post-launch monitoring schedule

Detailed monitoring steps: post-launch monitoring guide.

Roles and ownership

Named owners prevent 'I thought you were checking redirects' conversations on launch night. The checklist is also a RACI document if you fill in names beside stages.

Staging environment checklist

• arrow_rightPHP version matches production target.
• arrow_rightPermalink structure matches production plan.
• arrow_rightACF JSON synced from dev to staging.
• arrow_rightSEO plugin installed and configured (no staging noindex on pre-launch copy).
• arrow_rightRobots.txt blocks crawlers until launch rehearsal complete.
• arrow_rightBasic auth or IP allowlist if client staging is public URL.

Documentation to leave behind

A migration is not complete when the site goes live — it is complete when the client can operate without calling you for every redirect question. Deliver a handover pack: final redirect CSV, URL mapping spreadsheet, list of manual-review pages, plugin changelog, staging credentials, Search Console property access, and annotated sitemap. Include which ACF blocks map to which old page sections for their top ten templates. Agencies that skip documentation earn repeat migration support at zero revenue. The checklist doubles as the table of contents for that pack — tick boxes, then export the ticks into the client wiki.

Common launch-week failures

• arrow_rightRedirect plugin not flushed — rules exist but server cache serves old 404.
• arrow_rightSSL certificate on new host not matching www/non-www choice.
• arrow_rightForm notifications still pointing at old site email templates.
• arrow_rightCaching plugin minifying HTML differently on production vs staging QA.
• arrow_rightSearch Console property still verified on old host only.
• arrow_rightClient publishing on old site during DNS propagation.

Stage-by-stage time budgets

Use these budgets in proposals. If inventory finishes in four hours, you gain buffer for QA — do not absorb it as free design time. The checklist is a scope tool as much as a quality tool.

Working with clients during migration

Set a weekly migration status email: pages migrated, pages in review, redirects loaded, blockers. Clients who see progress tolerate longer timelines. Silence reads as stagnation — especially when their old site still looks better than staging.

Name a single client decision-maker for URL mapping and content sign-off. Committee review adds calendar time, not quality. Escalation path when they disagree on redirect targets should be in the SOW.

Offer a staging walkthrough before launch week — screen-share top pages, forms and mobile nav. Surprises on launch day are almost always failures of communication, not technology.

Checklist for agency project managers

Project managers without WordPress depth can still run this checklist with a technical buddy. Your job is sequencing and sign-off: no launch ticket until redirect CSV is attached, no content freeze exception without change order, no client demo on staging until QA pass one completes. Translate technical blockers into client language — "internal links on six service pages still point at old domain" not "ACF link field meta stale." The printable PDF version exists so PMs can literally tick boxes in stand-ups. Pair with the rebuild timeline guide when building the MS Project or Linear timeline so migration stage is not a single day squeezed between dev complete and launch.

Version the checklist PDF in your project folder with the date — clients reference outdated checklists from Google and miss new SEO steps you added last quarter.

Final sign-off before DNS

The last checklist gate is a named approver — tech lead plus client — ticking: redirects tested, top URLs compared, forms send, analytics fires, sitemap submitted, rollback plan documented. No tick, no DNS. Agencies that treat launch as a team high-five without sign-off sheet inherit weekend fire drills.

Keep the completed checklist in the project Drive folder — it is evidence of process for ISO, public sector tenders, and insurance if a migration dispute arises.

Deep dives for each checklist stage

The checklist is the spine — these guides are the detail per stage. Inventory and URLs: redirect map. Content: migrate into ACF blocks and how to use AIRA. CPTs and portfolios: custom post type migration. SEO: rebuild without losing SEO. Launch: QA checklist and post-launch monitoring.