Zero-Downtime WordPress Migration to Getwebup

You've decided to move your WordPress site to Getwebup, but there's one thing you're not willing to negotiate on: the site cannot go dark, even for ten minutes. Good news - it doesn't have to. Zero-downtime migration isn't a marketing phrase, it's just a specific order of operations, and once you understand why each step exists, the whole thing stops feeling risky.

What "Zero-Downtime" Actually Means

Let's be precise about this, because the phrase gets thrown around loosely. Zero-downtime migration means:

• Your live visitors never see a "site not found" or a half-loaded page during the move.
• Your email keeps flowing in and out the whole time.
• Search engines don't see a gap in availability that could ding your rankings.

It does not mean the DNS switch is instant. DNS changes still take time to propagate globally - that's physics, not a Getwebup limitation. The trick to zero downtime is that both the old and new copies of your site stay live and in sync during that propagation window, so it doesn't matter which one a visitor happens to hit.

Before You Start: What You Need Ready

Don't start the file transfer until you have all of this sorted - most "migrations gone wrong" stories start with someone skipping this list.

• Full backup of the old site - files and database, dated, and downloaded somewhere off both servers.
• A Getwebup hosting account already provisioned - cPanel or your VPS control panel ready, with PHP version matched to what the old site was running.
• Registrar or DNS provider login - you'll need this for the final cutover, and possibly to lower TTL in advance.
• A list of every mailbox on the domain - migrating the site is only half the job if email lives on the same server.
• Staging access on Getwebup - a temporary URL or hosts-file entry so you can test the new site before anyone else sees it.

Step 1: Lower the DNS TTL Early

Do this 24-48 hours before you touch anything else. Log in to wherever your domain's DNS is managed and drop the TTL (time to live) on your A record down to something small:

Type: A
Name: @
TTL:  300  (5 minutes, down from a typical default of 3600 or 14400)

A low TTL means that when you do flip the record later, resolvers around the world stop caching the old answer for hours and start picking up the new one within minutes instead. Skipping this step is the single most common reason people see a "slow" cutover that isn't actually slow - it's just an old TTL doing exactly what it was told.

Step 2: Copy Everything to Getwebup Without Touching the Live Site

The old server keeps serving visitors the whole time you're doing this - nothing here is destructive.

1. Files: Compress wp-content, wp-config.php, and any custom root files into a single archive (zip or tar.gz) on the old server, then pull it over via SFTP, or use cPanel's Backup Wizard if both accounts are on cPanel.
2. Database: Export via phpMyAdmin (Export > Custom > gzip) or, faster for larger sites, over SSH:

   mysqldump -u dbuser -p dbname | gzip > site_backup.sql.gz

3. Upload and import both into the new Getwebup account. Create a fresh database and user in cPanel first, then import the SQL through phpMyAdmin or:

   gunzip < site_backup.sql.gz | mysql -u newuser -p newdbname

4. Update wp-config.php on the new server with the new database name, user, password, and host (usually localhost).

Step 3: Test on the New Server Before Anyone's DNS Changes

This is the step people skip, and it's the one that actually delivers "zero downtime." Edit your local machine's hosts file so your browser resolves the domain to the new server's IP, without changing anything for actual visitors:

# /etc/hosts on Mac/Linux, C:\Windows\System32\drivers\etc\hosts on Windows
203.0.113.10   yourdomain.com www.yourdomain.com

Now browse the site as if you were a real visitor. Check the homepage, a blog post, the checkout flow if it's WooCommerce, and the wp-admin login. Common things that break here: hardcoded old-domain image URLs, a caching plugin serving stale paths, or a security plugin blocking the new server's IP. Fix all of it now, while the live site is untouched and forgiving of mistakes.

If URLs are hardcoded in the database (common with older sites or after a domain change), run a proper search-replace with WP-CLI rather than a manual find-and-replace, which tends to corrupt serialized data:

wp search-replace 'http://olddomain.com' 'https://yourdomain.com' --all-tables

Step 4: Flip DNS and Watch Both Servers

Once the new site checks out clean, update the A record at your registrar or DNS provider to point to Getwebup's server IP. Because you lowered the TTL in Step 1, most visitors will be redirected within 5-30 minutes, though a small fraction of resolvers can take a few hours to catch up - that's normal, not a failure.

During this window, keep the old server running and untouched. Don't cancel the old hosting plan, don't delete files, don't take the database offline. Some visitors are still landing there while their ISP's DNS cache catches up, and that's exactly the safety net that makes this "zero downtime" instead of "mostly fine."

Handling Email During the Move

If mailboxes live on the same server as the site, this is where people get burned. Two safe approaches:

• Move email separately, ahead of the site. Set up the same mailboxes on Getwebup, forward or fetch mail from the old server for a few days so nothing is lost, then switch MX records once you've confirmed delivery on the new setup.
• Keep MX pointed at the old provider temporarily. If your DNS provider is separate from your host (e.g., Cloudflare), you can move the A record to Getwebup while leaving MX records exactly where they are, decoupling the two migrations entirely.

Either way, never flip both the A record and the MX records in the same five minutes without a tested fallback. Email delivery failures are much harder for customers to notice - and much more annoying to explain - than a slow website.

Common Pitfalls That Sneak "Downtime" Back In

Post-Migration Checklist

• Confirm SSL is active and forcing HTTPS on the new server.
• Re-check wp-config.php for the correct WP_HOME and WP_SITEURL if you set them explicitly.
• Submit the updated sitemap in Google Search Console - not required, but it speeds up re-crawling if anything shifted.
• Set up a fresh cPanel backup schedule on Getwebup so day one isn't also day zero for your safety net.
• Keep the old server around, powered down or suspended rather than deleted, for at least a week.

Prevention: Making the Next Migration Even Smoother

If you're likely to move hosts again someday (or split a site across environments for staging), keep wp-config.php database credentials as the only environment-specific values, avoid hardcoding the domain anywhere in custom code, and document your DNS records somewhere outside the registrar itself. The next migration - yours or someone else's - will take an afternoon instead of a weekend.