How to Handle Difficult Client Migrations with Zero Downtime

Most agencies don’t lose sleep over the simple migrations. The ones that hurt are the 40GB WooCommerce store with a custom checkout, or the legacy site running PHP 7.2 on a host whose support desk answers once a day. Handling difficult client migrations with zero downtime is less about clever tooling and more about sequencing: you build the destination, prove it works, then move traffic only when there’s nothing left to guess.

Below is the process we use on messy transfers, including the parts that usually go wrong and how to keep a nervous client calm while you work.

What “zero downtime” actually means in practice

Zero downtime doesn’t mean the site is never touched. It means no visitor sees an error page, no order is lost, and no logged-in user gets kicked out mid-session. A migration can involve a brief read-only window and still qualify, as long as the front end keeps serving normally.

Set that definition with the client in writing before you start. Otherwise “zero downtime” gets interpreted as “nothing will change at all,” which is never true when DNS, SSL and caching layers are all moving.

Why some migrations turn difficult

The size of the database matters far less than the number of moving parts. In our experience the hard cases share a handful of traits:

• Live transactional data: stores, membership renewals or course progress writing to the database every few minutes.
• Hardcoded paths and absolute URLs buried in serialized options, page builder data or custom plugin tables.
• Locked-down access: no SSH, no WP-CLI, PHP timeouts at 30 seconds, and an old host that throttles large exports.
• Split infrastructure: email on the same domain, DNS at a registrar nobody has the password for, a CDN in front of everything.
• Undocumented customizations, usually a previous developer’s mu-plugin or a cron job nobody mentioned.

Each of those is manageable on its own. Stacked together on a launch night, they’re how you end up rolling back at 2am.

The pre-migration audit

Before touching a single file, collect the facts. This takes 30 to 90 minutes on a typical site and saves hours later.

• Current PHP version, MySQL/MariaDB version, and total disk usage split between files and database.
• Full plugin and theme inventory, flagging anything premium with a license tied to a domain or IP.
• DNS records exported as a text file: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, plus current TTL values.
• Registrar and DNS provider logins, confirmed working, not assumed.
• Every scheduled task, including server-side cron, payment gateway webhooks and third-party API callbacks.
• A baseline performance snapshot so you can prove improvement afterwards.

If the client can’t produce DNS access, stop there. That single blocker causes more failed launch windows than any technical issue, and it’s better discovered on day one than on cutover night.

The zero-downtime sequence

The order here is what protects you. Nothing public changes until step six.

1. Build the destination in parallel. Restore files and database onto the new host, running under a temporary hostname or hosts-file entry so the live site stays untouched.
2. Match or upgrade the environment. Set PHP to a version the site’s plugins actually support, then test upgrades separately rather than bundling them into the move.
3. Install and validate SSL on the new server before cutover. A certificate issued only after DNS flips means minutes of browser warnings.
4. Run a functional test pass. Checkout, contact forms, login, search, admin-ajax calls, image uploads, any REST endpoints a mobile app or headless front end uses.
5. Lower DNS TTL to 300 seconds at least 24 hours in advance, so resolvers pick up the change quickly when you flip it. Cloudflare’s explanation of how TTL controls DNS caching is worth sending to clients who ask why you need the lead time.
6. Do a final delta sync, then flip the A record. Keep the old server online and serving for 48 to 72 hours afterwards.
7. Monitor both origins. Watch error logs on the new host and incoming traffic on the old one until the old server goes quiet.

The official WordPress documentation on moving a site covers the file and database mechanics well. The sequencing above is what turns those mechanics into a launch nobody notices.

We cover this topic in more depth in Setting Client Expectations for WordPress Uptime and Maintenance.

Protecting live data during the cutover

This is where stores and membership sites get dangerous. Between your final database export and the DNS flip, the old site may still be taking orders, and those rows will not exist on the new server.

Three approaches, in order of preference:

• Pick a genuine low-traffic window. Pull 30 days of analytics and find the hour with the least activity. On most B2C stores that’s somewhere between 2am and 5am local time.
• Put the old site into a short read-only or maintenance state for the 10 to 20 minutes the final sync takes, with a branded notice rather than a raw 503.
• Re-sync only the transactional tables after the flip, importing new orders, subscriptions and user rows by ID range.

For stores, sessions deserve separate thought. Our notes on handling simultaneous logged-in users on WooCommerce explain why cart and session data behaves differently from ordinary content, and why a cart emptying mid-migration reads to the customer as a broken site. Anything running real payments should land on a platform built for it, which is the reason we point ecommerce clients toward WooCommerce-specific hosting rather than a generic shared plan.

Email, redirects and the things clients forget

Changing nameservers moves MX records too, which is how a migration silently kills a client’s email. Copy MX, SPF, DKIM and DMARC records across before the switch, and verify a test send in both directions afterwards.

If URLs change as part of the move, map old to new and serve 301 redirects from day one. Google’s guidance on site moves with URL changes is the reference to follow, and it’s worth keeping those redirects in place for at least a year.

Also re-check: cron schedules, transactional email deliverability, any hardcoded IP allowlists at payment gateways, and search console property verification.

Always build the rollback before you need it

A rollback plan is just three things written down: the old server stays untouched and running, you hold a pre-cutover snapshot of both file system and database, and you know exactly which DNS record to revert and who has access to revert it.

Define your abort criteria in advance. Ours are simple: checkout failure, sustained 5xx errors above 1% of requests, or any data loss that can’t be reconciled within the hour. A public status page helps here too, because it separates “the migration broke something” from “an upstream provider is having a bad day.”

Managing the difficult client, not just the difficult site

Hard migrations are usually hard because of expectations, not code. Send a one-page plan with the window, the definition of downtime you agreed on, what you need from them, and when you’ll report back.

Then bill for it properly. Migration work is skilled labour, and packaging it into a retainer alongside hosting is cleaner than absorbing it as goodwill, which is partly a billing systems question covered in our comparison of WHMCS and Stripe for hosting resellers.

Frequently Asked Questions

How long does a difficult WordPress migration take?

Plan on 4 to 12 hours of hands-on work for a complex site, spread across three to five days of preparation, testing and monitoring. The actual cutover window is usually 10 to 30 minutes; everything else is verification.

Can DNS propagation really take 48 hours?

Rarely, if you prepare. With TTL lowered to 300 seconds a day in advance, most resolvers update within 5 to 15 minutes, though a small number of ISP caches and corporate resolvers ignore low TTLs and can lag several hours.

Will I lose orders during a WooCommerce migration?

Not if you keep the old server running and re-sync transactional tables after the flip. The risk sits entirely in the gap between final export and DNS change, which is why a brief read-only window beats a hopeful “nobody shops at 3am.”

Should I upgrade PHP or plugins during the migration?

No. Migrate first on matched versions, confirm everything works for a few days, then upgrade as a separate task so you always know which change caused which problem.

Who should hold the DNS credentials?

The client should own the registrar account, with the agency added as a delegated user. It protects everyone, and it means a launch never stalls because one freelancer stopped replying to email.

Planning a migration you’d rather not do alone?

Our team handles free WordPress migrations, including the awkward ones with live checkouts and legacy PHP, and we’ll tell you honestly where the risk sits before booking a window. See how other agencies made the move in our customer case studies, then send us the site details and we’ll map the sequence with you.