The Zero-Downtime WordPress Migration Checklist

A migration that goes well is invisible. Nobody notices, nobody emails, the client’s traffic and orders carry on as if nothing happened. A migration that goes badly produces a broken checkout, a mailbox full of 404 alerts, and an awkward call about lost form submissions. The difference is almost never technical skill — it is sequencing. This wordpress migration checklist is about the sequence.

What follows is the full run: pre-flight audit, staging build, verification, the cutover window itself, and the 72 hours afterwards where most of the real damage is either caught or missed.

What “zero downtime” actually means

It does not mean the site is never briefly unavailable. It means no visitor sees an error, no transaction is lost, and no content written during the switch disappears. On a static brochure site those are easy to satisfy. On a store or a membership site they are three separate problems, and the third one — writes happening mid-migration — is the one that catches experienced teams out.

So the first decision is what kind of site you are moving:

Site type	Write activity during cutover	Approach
Brochure / marketing	None, or content edits only	Copy, verify, switch DNS. Content freeze of a few hours.
Blog with comments or forms	Low but non-zero	Freeze plus a post-cutover sync of new entries.
WooCommerce / membership	Continuous	Maintenance-mode window, or a database delta sync at the moment of switch.
Multisite	Varies per site	Treat each network site’s risk separately; migrate the network as a unit.

Decide this before you touch anything. It determines your window, your rollback plan, and how much of the client’s Saturday you are about to need.

Phase 1: pre-flight audit

Do this a week out, not the night before. Everything that goes wrong on migration day was discoverable here.

1. Inventory the environment. PHP version, MySQL or MariaDB version, WordPress version, memory limit, max upload size, cron method, and whether object caching or Redis is in play. Note the same values on the destination.
2. Record the size of everything. Database size, uploads directory size, largest single table. A 4GB uploads folder and a 2GB wp_options table change your method — and the second one usually means autoloaded transients you should clean up first.
3. List every DNS record. Not just the A record. MX, TXT and SPF records get destroyed by nameserver changes more often than anything else, and the symptom is the client’s email silently dying two days later.
4. Find the external dependencies. Payment gateway callbacks, licence keys tied to a domain or IP, CDN configuration, webhooks, API allowlists, transactional email service, marketing automation, anything with a hard-coded URL.
5. Capture the baseline. Export a full URL list, top 200 pages by traffic, current Core Web Vitals, and a crawl of the live site. Without a baseline you cannot prove afterwards that nothing regressed.
6. Confirm access, all of it. Source host, destination host, registrar, DNS provider, CDN, and any third-party service you will need to update. Missing registrar access at cutover is the classic avoidable delay.

Write the findings into a short document and share it with whoever will run the cutover. If a partner is doing the migration, this document is the brief. It is also the artefact that turns a nervous client conversation into a calm one.

Phase 2 of the WordPress migration checklist: build and verify

Move the site to the new host and get it fully working there while the old site is still live and serving traffic. This is the part of the wordpress migration checklist that buys you the zero downtime.

• Take a full backup of the source: files and database, downloaded and stored somewhere that is not either host.
• Match the PHP and database versions on the destination before importing. Import first and upgrade PHP later and you will spend an hour chasing errors that were never real.
• Transfer files by the fastest reliable route available — rsync or an archive over SSH beats a plugin on any site of size.
• Export and import the database with a command-line tool for anything over a few hundred megabytes. Browser-based exports truncate silently.
• Run a serialisation-safe search and replace for the old domain and old file paths. Never a raw SQL REPLACE on serialised data — it corrupts widget, theme mod and page builder settings in ways that surface weeks later.
• Reissue SSL on the destination and confirm the certificate covers both www and the apex domain.
• Rebuild the redirect map, including anything previously handled at server level rather than in WordPress.
• Point your own machine at the new server with a hosts file entry, then test the real domain against the new host while the world still sees the old one.

Verify with a checklist, not a glance at the homepage. Crawl the staged copy and compare against the baseline crawl for status codes, titles and canonical tags. Submit every form. Complete a real test order end to end, including the payment gateway callback and the confirmation email. Log in as each user role and confirm the editor roles and permissions behave as they did before. Check that scheduled tasks are actually firing on the new host.

Phase 3: the cutover window

Lower the DNS TTL to 300 seconds at least 48 hours before the switch. This single step is the difference between a five-minute transition and a two-day tail of visitors hitting the old server.

1. Pick a genuinely low-traffic hour based on the client’s analytics, not on your own timezone.
2. Announce a content and order freeze to everyone who might write to the site, and confirm it has been read.
3. Put the source site into maintenance mode if writes are possible during the window.
4. Sync the delta — anything created since your last import: new orders, new posts, new uploads, new users.
5. Update the DNS A record or nameservers. Verify propagation from several geographic resolvers rather than one.
6. Confirm the new server is serving the domain over HTTPS with a valid certificate and no mixed-content warnings.
7. Lift maintenance mode and place one live test order or one live form submission yourself.
8. Leave the old server running, untouched, for at least a week. It is your rollback and your evidence.

Have a written rollback trigger agreed in advance: a specific condition, such as checkout failing or a sustained 5xx rate, that means you revert DNS without further discussion. Deciding this while a client’s store is down is not the moment for a debate.

Phase 4: the first 72 hours

• Watch 404 and 5xx logs daily. A spike in 404s means your redirect map missed a pattern.
• Confirm transactional email is being delivered and not landing in spam because the new server’s IP has no reputation. If you did not move to an authenticated sending service before the migration, do it now.
• Check Search Console for crawl errors and confirm the correct property is reporting.
• Re-run the performance baseline. New hosts often need cache configuration tuned before they beat the old numbers; a fresh look at cache configuration and image delivery at this point is cheap and effective.
• Restore the DNS TTL to its normal value once you are confident.
• Re-point backups and uptime monitoring at the new host. This is the step everyone forgets, and it is only discovered when a restore is needed.

Then hand the site into an ongoing routine. A freshly migrated site is at its most fragile in the first month, which is a good argument for putting it straight onto WordPress maintenance and support rather than closing the ticket and moving on.

When to hand the migration to someone else

Migrations are unforgiving and low-margin. They take a senior person out of billable project work for a day, they usually happen outside business hours, and the downside risk sits entirely with you. That combination is why many agencies route them to a white label WordPress development partner and keep their own team on design and strategy.

Outsource when the site has real transaction volume, when the source environment is unfamiliar, when you are consolidating many sites at once, or simply when the cutover falls on a Sunday night. Keep it in-house when it is a small site on a host you know well — paying for coordination on a two-hour job makes no sense. Agencies doing this regularly usually run it through dedicated WordPress migration services with the pre-flight audit as the brief.

One more thing worth planning for: a migration is the ideal moment to fix the deployment habits that made the old environment painful. If the site had no staging, set up a proper staging to production workflow on the new host on day one, while nobody is depending on it yet.

Frequently asked questions

How long does a WordPress migration take?

A small brochure site is typically a few hours end to end. A WooCommerce store with plugins, integrations and a large media library is usually a one to two day job spread across a week, because the audit and verification take longer than the transfer itself.

Are migration plugins good enough?

For small sites on standard hosting, yes, and there is no prize for doing it the hard way. They become unreliable on large databases, sites with unusual directory structures, or hosts with tight execution limits. If the plugin fails halfway, you need the command-line method anyway.

Will migrating hurt SEO rankings?

A host move on the same domain should have no ranking impact if URLs, status codes and canonicals are preserved. Losses almost always trace to a broken redirect map, an accidental noindex left on from staging, or a robots.txt copied from the staging environment. Check all three before you sleep.

What about orders placed during the switch?

Either prevent them with a short maintenance window, or sync the delta from the source database immediately after the DNS change. For high-volume stores the maintenance window is safer and easier to explain to the client than a partial sync that might miss a row.

How long should the old host stay live?

At least seven days, ideally thirty. Cancelling immediately saves a small hosting fee and removes your rollback path at the exact point you are most likely to need it. Take a final archived backup before you shut it down.

If you have a migration coming up and would rather not run the cutover yourself, the team is happy to look at the pre-flight audit and tell you honestly whether it is a two-hour job or a two-day one.

If it is easier to compare on cost first, the dedicated plans page lists the hour tiers and monthly rates in the open.