WordPress Migration Checklist: Before, During, and After

The full guide already walks you through every step. This is the tick-box version you print, work through in order, and hand to whoever else is touching the move.

What’s actually on a WordPress migration checklist?

A migration checklist is the tick-box version of the move, three phases, before, during, and after, with the SEO-preservation and rollback items most checklists leave out. It’s not a rewrite of the process itself.

The full narrative walkthrough, meaning what actually happens at each step and why, already lives in the WordPress migration guide. This piece assumes you’ve read that, or you already know your migration type, and just need the list you can print, pin next to your monitor, and work through without re-reading a paragraph every time you finish a task. If you’re moving to a specific new host or server, the mechanics of that particular move are in the host-move guide, and if something breaks after you go live, the errors guide has the fix for each symptom.

What do you need to check before you start a WordPress migration?

Work through this list before you transfer a single file. Nearly every migration that goes sideways lost the fight here, not during the actual copy.

1. Inventory the site. WordPress version, active theme, full plugin list, database size, and the total size of wp-content/uploads. Note anything custom: cron jobs, .htaccess rules, hard-coded paths.
2. Take two full backups. Files and database, with one copy stored off the server entirely, on your own machine or in cloud storage. This backup is the whole of your rollback plan.
3. Export your current URL list and XML sitemap. You need this baseline before anything changes, so you have something to check your redirects against later.
4. Draft the redirect map. If the domain or URL structure is changing at all, pair every old URL with its new destination now, before the transfer, not after something 404s.
5. Confirm the new host meets requirements. PHP version, MySQL or MariaDB version, HTTPS support, matched against what your theme and plugins actually need.
6. Inventory your DNS and email records. A, MX, SPF, DKIM, and any domain-verification TXT records (Google Workspace, Microsoft 365, third-party tools). Write down what exists now so nothing gets missed when you recreate it.
7. Lower your DNS TTL. Drop it to 300 seconds a day ahead of the move, so the eventual cutover propagates in minutes rather than hours.
8. Schedule the content freeze window. Tell anyone who publishes, sells, or takes comments on the site exactly when to stop, so nothing gets created mid-migration and lost.

What do you check during the actual transfer?

This is the part most guides focus on, and it’s genuinely the shortest phase when the before-list above is done properly.

1. Package or export the site. Plugin archive, or files over FTP plus a database export, per the full process walkthrough.
2. Transfer everything to the new host and create the destination database.
3. Update wp-config.php with the new database name, user, password, and host.
4. Recreate SPF, DKIM, and DMARC records on the new host before touching MX. Authenticate first, cut over second. Moving mail before authentication is configured is one of the fastest ways to land in spam folders mid-migration.
5. Run a serialized-safe URL search-and-replace if the domain or path changed. Never a raw SQL update, it corrupts serialized data silently.
6. Test everything on a temporary URL or staging domain before DNS changes at all. Homepage, key pages, forms, checkout, images, admin login.
7. Cut over DNS only once that test pass is clean. Not before.

What’s on the post-launch checklist after cutover?

The move isn’t finished when DNS flips. This phase is where SEO value either survives or quietly leaks away over the following weeks, and it’s the phase most DIY checklists cut short.

1. Confirm DNS has propagated and the new site is serving all visitors, not just you.
2. Flush permalinks (Settings → Permalinks → Save Changes) and clear every cache layer, plugin, server, CDN, browser.
3. Verify SSL is valid on the new host before anything else gets checked.
4. Test every redirect, don’t just trust the map. Actually request a sample of old URLs and confirm each one lands where it should. A redirect that exists on paper and a redirect that fires correctly are not the same thing.
5. Confirm canonical tags point at the final URLs, not a staging domain or an old address left behind in a template.
6. Regenerate the XML sitemap on the live new site and resubmit it in Google Search Console.
7. File a Change of Address in Search Console if the domain changed, for every verified version of the old domain, including www and non-www.
8. Check email delivery on both old and new mail records for about a week while MX propagation settles, since messages can land on either server during that window.
9. Monitor Search Console’s Coverage and Performance reports for several weeks. A brief dip after a move is normal; a sustained slide usually means a redirect or indexing problem.
10. Keep the old host running for at least a week or two as your rollback window before cancelling anything.
11. Retire the old sitemap a few months out, once Google has fully re-crawled and the redirects are confirmed working.

The full checklist, one table

Print this, or keep it open on a second screen. Every item from the three phases above, in one place.

What SEO-preservation items does a migration checklist need that a backup checklist misses?

A generic backup-and-transfer checklist protects your data. It says nothing about protecting the years of ranking signal attached to your URLs, and that’s a separate list, worth treating as its own line item rather than an afterthought bolted onto the transfer.

Four things carry the actual SEO weight. A complete redirect map, every old URL paired with its real new destination, not a blanket rule. Correct canonical tags pointing at the final live URLs once the move is done. A regenerated XML sitemap, resubmitted in Search Console so Google finds the new structure fast. And, for any domain change, a Change of Address filed through Google’s own Change of Address tool in Search Console, submitted for every verified version of the old domain, including both the www and non-www variants.

Per Google’s own site-move documentation, redirects need to stay live for at least a year so ranking signals fully transfer, and per Google’s redirects documentation, a 301 is what actually carries that signal forward. Taking either of those down early is how a technically successful migration still bleeds traffic for months afterward. If the URL structure genuinely changed, meaning you’re coming off a different platform entirely, mapping that redirect surface by hand is real work, not a checkbox, and it’s covered in more depth in the migration cost breakdown, since it’s usually where a quote’s price actually comes from.

What should your rollback plan actually cover?

A rollback plan is one thing. Know exactly how to point traffic back at the old, working site within minutes if the new one fails a check you didn’t catch during testing. It’s not a backup on its own, it’s the decision already made in advance about what you do with that backup.

Three things make a rollback plan real instead of theoretical. First, the old host stays live and untouched for a defined window after cutover, a week or two at minimum, so reversing DNS is the only step needed if something goes wrong. Second, your DNS TTL is already low from the before-phase, so a rollback propagates just as fast as the original cutover did. Third, someone owns the decision. Write down, before launch, what specifically triggers a rollback (a broken checkout, a data-loss symptom, a sustained ranking drop) so nobody’s debating the call while the site is down.

The quiet failure mode is cancelling the old hosting the same day you go live, because everything looked fine for an hour. Don’t. Keep it running through the whole monitoring window in the after-phase above.

What DNS and email records break during a WordPress migration?

Website and email run on entirely separate DNS records, and moving the wrong one first is how a migration takes down inboxes instead of just moving a site. MX records route mail. SPF, DKIM, and DMARC records authenticate it. A records point your domain at the website itself. Change the wrong one, or change them out of order, and mail starts bouncing or landing in spam while everyone’s attention is on whether the website loaded.

The safe order is authenticate first, cut over second, verify third. Recreate your SPF, DKIM, and DMARC records on the new host or provider before you touch MX at all, since an unauthenticated sender gets flagged fast. Once MX changes, check both the old and new mail systems for roughly a week, because during propagation some senders will still be routed to the old server. Don’t forget domain-verification TXT records either, Google Workspace, Microsoft 365, and third-party marketing or analytics tools often rely on one sitting quietly in your DNS, and it’s easy to lose track of during a host move if it wasn’t on your inventory list from the before-phase.

Where do you go from here?

Print the table above, or copy it into your project tracker, and work it in order. Nothing on this list is complicated on its own. What breaks migrations is skipping a before-phase item because it feels like paperwork, or declaring victory the moment DNS flips instead of watching Search Console for the following weeks.

If you want the full narrative behind any single step, that’s the complete WordPress migration guide. Moving to a specific new host or server has its own detailed walkthrough in the host-move guide, and if something on this list turns up broken after launch, the errors guide has the exact fix. Want a real number for your own move before you budget it? The migration cost guide breaks down what actually drives the price. And if you’d rather someone else own this whole checklist, redirects and rollback included, that’s what jbe.works WordPress Migration does, start with a free pre-migration audit at /audit.

Frequently asked questions

Quick answers to what comes up most when people build their own migration checklist.

What are the three phases of a WordPress migration checklist?

Before, during, and after. Before covers backups, inventory, and the redirect map. During covers the actual file and database transfer. After covers verification, SEO resubmission, and the monitoring window that most checklists cut short.

What SEO steps belong on a WordPress migration checklist?

A complete redirect map, correct canonical tags pointing at the final URLs, a regenerated and resubmitted XML sitemap, and, for any domain change, a Change of Address filed in Google Search Console held for at least a year.

What DNS records break during a WordPress migration?

MX records for email routing, plus SPF, DKIM, and DMARC for authentication, and domain-verification TXT records for tools like Google Workspace or Microsoft 365. Recreate authentication records before changing MX to avoid mail landing in spam.

How long should I keep the old host running after migrating?

At least a week or two as a rollback window. Some visitors and mail servers still reach the old host during DNS propagation, and it’s your fastest recovery path if something surfaces after launch.

Do I need to lower my DNS TTL before migrating WordPress?

Yes. Drop it to 300 seconds about a day before cutover so the eventual DNS change propagates in minutes instead of hours, both for the initial cutover and for a rollback if you need one.

How is this checklist different from the full WordPress migration guide?

The full guide explains each step and why it matters. This is the tick-box companion, the printable before/during/after list plus the SEO-preservation and rollback items condensed into a single table you can work through directly.