Sharjeel TahirYour everyday toolkit
Menu
WORDPRESS GUIDE

WordPress migration checklist: move hosts without downtime

Moving WordPress to a new host is stressful because everything can break at once. This professional checklist breaks migration into pre-flight, migration day and post-launch — so the move is boring, which is exactly what you want.

Published October 9, 20269 min readBy Sharjeel Tahir

What should you check before migrating WordPress?

Before migrating: take a full backup, record PHP/MySQL versions and plugin list, check the new host meets requirements, note DNS TTL values (lower them 24h ahead), verify domain registration access, and test the new host with a staging copy. Most migration disasters are pre-flight failures — incompatible PHP, forgotten email accounts, or DNS you don't control.

Professional migrations are boring because the excitement happens *before* migration day. Run this pre-flight:

  • Full backup — verified. Files + database, stored off your current server. Download it; don't trust 'the host has backups'.
  • Document the current setup. PHP version, MySQL version, plugin list with versions, theme, custom code, cron jobs. The new host must match or exceed these.
  • Check new host compatibility. PHP version support, MySQL/MariaDB, required PHP extensions, SSL availability, and whether the host offers free migration or staging.
  • Lower DNS TTL to 300 seconds 24–48 hours before the move, so the switchover propagates in minutes not days.
  • Confirm domain access. You need registrar login to change nameservers — migrations have stalled for days on a forgotten registrar account.
  • Inventory the extras. Email accounts on the old host (migrate or move to Google Workspace first), subdomains, staging sites, CDN/firewall configs (note Cloudflare settings).

Use the free interactive migration checklist to track all of this — it keeps the 40+ items organized so nothing slips. Migrations fail on forgotten details, not hard problems.

The most skipped pre-flight step: testing on the new host first. Upload the site to a temporary URL or staging subdomain on the new server and click through everything — forms, checkout, logins — before touching DNS. Discovering a PHP incompatibility *after* the switch is how downtime happens.

How do you migrate WordPress with zero downtime?

Copy the site to the new host and verify it on a temporary URL while the old site still serves visitors, then switch DNS — visitors move to the new server as DNS propagates, with no interruption. Keep the old site live for 48–72 hours after the switch as a fallback, and never cancel old hosting until post-launch checks pass.

The zero-downtime sequence:

  • 1. Migrate files and database to the new host (plugin like Duplicator/All-in-One WP Migration, or manual via SFTP + phpMyAdmin for large sites).
  • 2. Verify on temporary URL. Full click-through: homepage, key pages, forms, login, checkout. Compare against the live site side by side.
  • 3. Freeze changes on the old site during final sync — or plan a second delta-sync for orders/comments made during propagation.
  • 4. Switch DNS (nameservers or A record) to the new host. With TTL pre-lowered, most visitors move within minutes; full propagation takes up to 48h.
  • 5. Monitor both. Watch the new site's error logs and the old site's traffic — stragglers on old DNS still hit the old server.
  • 6. After 72h clean: cancel old hosting. Not before — keep the fallback until you're certain.

Method choice: migration plugins (Duplicator, All-in-One WP Migration, Migrate Guru) handle 95% of sites up to a few GB beautifully — use them. Manual migration (SFTP + database export/import + wp-config edit + search-replace URLs) suits huge sites, multisite, or when plugins time out. Host-assisted migration is free with many quality hosts — let them do it, then verify yourself.

The database URL problem: WordPress stores absolute URLs in the database, so moving domains (or http→https) needs a proper search-replace (Better Search Replace plugin or WP-CLI) — never a text-editor find/replace on the SQL dump, which corrupts serialized data.

Check DNS propagation yourself with the DNS lookup tool from multiple angles rather than assuming it's done — 'it works for me' often means your local DNS updated while visitors elsewhere still hit the old server.

What breaks most often during WordPress migrations?

The usual casualties: mixed-content warnings after http→https moves, broken images from hardcoded URLs, white screens from PHP version mismatches, email stopping (MX records forgotten), contact forms failing (SMTP config tied to old host), and permalinks 404ing (htaccess not migrated). Every one is preventable with the pre-flight and post-launch checks in this guide.

White screen of death: almost always PHP incompatibility (new host runs PHP 8.x, old theme/plugin expects 7.x) or a failed plugin. Fix: match PHP versions first, then update the offending code. This is why staging tests exist.

Mixed content (https site loading http resources): browsers block these, breaking styles and scripts. Run a proper database search-replace for the URL change and check with an SSL test — the SSL checker confirms the certificate side.

404s on all pages: permalinks need the .htaccess (Apache) or nginx rules migrated. Re-save permalinks in Settings → Permalinks on the new host — this regenerates rewrite rules and fixes most 404 waves instantly.

Email dies silently: MX records live in DNS — if you changed nameservers, you must recreate email DNS records at the new DNS host *before* switching, or migrate email to Google Workspace/Microsoft 365 first. Test send/receive immediately after the switch.

Forms and SMTP break: contact form plugins configured for the old host's mail setup fail on the new one. Reconfigure SMTP credentials for the new environment and send test submissions from every form.

Cron jobs stop: server cron tasks (backups, scheduled posts, WooCommerce webhooks) don't migrate themselves. Recreate them on the new host and verify scheduled posts publish on time.

How do you verify a migration succeeded?

Verify systematically: every key page loads over HTTPS without errors, forms and checkout complete end-to-end, logins work, emails send and arrive, scheduled posts publish, Search Console shows no crawl errors, and site speed is at least as good as before. Run these checks over 72 hours before canceling the old host.

The post-launch checklist (do not cancel old hosting until all pass):

  • Pages: homepage, top 10 trafficked pages, blog posts with images — all loading, HTTPS, no mixed content.
  • Functionality: contact forms submit, newsletter signup works, user login/logout, password reset email arrives.
  • Commerce: full test purchase on WooCommerce — cart, checkout, payment gateway (sandbox), order email, stock deduction.
  • Email: send and receive from domain addresses; check spam folders.
  • Scheduled tasks: a scheduled post publishes on time; backup plugin runs its first backup on the new host.
  • SEO: Search Console → no new crawl errors; check site:domain.com over the following weeks; confirm the SSL certificate is valid.
  • Performance: speed test the new host — it should match or beat the old. Slower = investigate before committing.
  • DNS: confirm propagation complete worldwide; old host shows near-zero traffic.

Keep the old hosting active 7–14 days minimum (a month is safer for business sites) — it's cheap insurance. Some professionals keep a final backup of the old site indefinitely; storage is cheap, regret is expensive.

Tell Google nothing — no Search Console 'change of address' needed for host-only moves (that's for domain changes). But watch Crawl Stats for a week: a healthy migration shows Google crawling normally, not error spikes.

Should you migrate WordPress yourself or hire someone?

DIY with a migration plugin works for standard sites under ~2 GB with no custom infrastructure — follow this checklist and you'll be fine. Hire a professional for WooCommerce stores (order data can't be lost), multisite networks, very large sites, or when email/DNS complexity is high. The cost of professional migration is trivial next to a day of downtime.

DIY is fine when: single site, under ~2 GB, standard plugins, you control DNS and hosting panels, and you can afford a few hours of careful work. Migration plugins have made this genuinely accessible — thousands of owners do it successfully every week.

Hire when: it's a WooCommerce store (orders placed during DNS propagation need delta-syncing or brief maintenance mode — lost orders are lost revenue), multisite, 10 GB+ media libraries, custom server configurations, or the site earns significant daily revenue. Also hire when the *current* site is already broken — migrating problems just relocates them; fix first, then move.

What professional migration includes: pre-flight audit, staging verification, the DNS switch at low-traffic hours, delta-sync of orders/comments, email continuity, post-launch verification with a written report, and old-hosting decommissioning. Ask for this scope explicitly — 'we'll move your site' without the checklist is just DIY with extra steps.

Related moves professionals bundle: hosting migration for complex server-to-server transfers, staging to live workflows, and email migration so addresses survive the transition. If your situation involves any of these plus revenue on the line, the professional route pays for itself in avoided downtime alone.

How do you choose the right new host?

Choose based on your site's actual needs: quality shared hosting for brochure sites, managed WordPress or VPS for WooCommerce and high traffic. Judge by PHP currency, server location near your audience, backup policy, support responsiveness (test it before buying), and staging environments — not by the introductory price, which always rises on renewal.

Hosting is the foundation everything else stands on — a migration is the perfect moment to escape a bad one. Evaluate:

  • Performance: current PHP versions (8.x), SSD/NVMe storage, server-level caching (LiteSpeed/Redis), and a datacenter near your visitors. Ask for TTFB numbers, not marketing adjectives.
  • Backups: automated daily off-site backups with one-click restore, included — not a paid add-on.
  • Support that answers: open a pre-sales ticket with a technical question. Slow or copy-paste answers now mean slow help during your 2 AM outage later.
  • Staging environments: one-click staging is the professional way to test changes — its absence signals a host not built for serious sites.
  • Honest pricing: check the *renewal* price, not the intro offer. A host that's cheap for year one and triple after is planning on your inertia.
  • Migration help: many quality hosts migrate you free — take the offer, then verify with this guide's checklists.

Red flags: 'unlimited everything' (it's never unlimited — read the fair-use policy), no PHP version choice, backups as a paid extra, and support that only exists via tickets with 24h+ response times. Your host is your site's landlord; choose like you'll live there for years, because migrations are work you don't want to repeat.

Track your migration free

The interactive WordPress migration checklist — 40+ items organized so nothing gets forgotten, right in your browser.

Open the migration checklist ↗

Frequently asked questions

How long does a WordPress migration take?

The technical move: 30 minutes to a few hours depending on site size. The full process with pre-flight, staging verification and DNS propagation: plan 2–5 days elapsed, mostly waiting on DNS and verification, not active work.

Will my site go down during migration?

Not if done properly — the new copy is built and verified while the old site serves visitors, then DNS switches traffic over. Brief issues can occur with WooCommerce (orders during propagation) which is why stores need delta-sync or short maintenance mode.

Do I need to notify Google about a host change?

No — host-only moves need no Search Console change-of-address (that's for domain changes). Just monitor Crawl Stats for error spikes in the week after. Keep URLs, structure and content identical and rankings continue normally.

What happens to my emails during migration?

Email breaks if MX records aren't recreated at the new DNS host. Either migrate email to Google Workspace/Microsoft 365 before the move, or copy all DNS records (MX, SPF, DKIM) to the new DNS provider before switching nameservers. Test send/receive immediately after.

Can I migrate from HTTP to HTTPS at the same time?

You can, but do it as a separate verified step: migrate hosts first, verify, then switch to HTTPS with proper search-replace and redirect rules. Combining both multiplies the things that can break simultaneously.

Should I keep the old hosting after migrating?

Yes — keep it 2–4 weeks minimum as a fallback, and keep a final backup indefinitely. Cancel only after post-launch checks pass over several days and old-host traffic drops to zero. It's the cheapest insurance in the whole project.

Portrait of Sharjeel Tahir
About the author

By Sharjeel Tahir

Sharjeel Tahir is a WordPress specialist based in Lahore, Pakistan, offering professional WordPress migration services. This checklist comes from real migrations — the boring, successful kind.

Published: 2026-10-09