--- title: "How to migrate a WordPress site without downtime" date: "2026-07-21" updated: "2026-07-21" excerpt: "A migration plan that avoids the two things that actually break sites: DNS propagation gaps and content written after you took the backup. With a rollback path." tags: ["WordPress", "Hosting", "Migration"] draft: false category: "guide" tldr: "Lower your DNS TTL days ahead, build and fully test the new site before touching the domain, move the database with a serialization-aware search-replace, sync again right before the switch, then keep the old server running for 48 hours as a rollback path." howToSteps: - name: "Lower your DNS TTL, days ahead" text: "Drop the TTL to 300 seconds at least 24–48 hours before the migration so the old long TTL has expired everywhere by the time you move." - name: "Build the new site before touching the domain" text: "Copy files and database to the new host, edit your local hosts file to preview the real domain, and test the front page, a post, search, the admin, and any checkout." - name: "Move the database with a serialization-aware tool" text: "Use wp search-replace with --dry-run first, then run it for real, after taking a fresh database export." - name: "Sync again immediately before the switch" text: "Do a final database and uploads sync right before changing DNS, using maintenance mode for a busy site so nothing is written mid-copy." - name: "Switch DNS and keep the old server running" text: "Point the A record or CNAME at the new server, then leave the old server running for at least 48 hours as a safety net." faqs: - question: "Why lower the DNS TTL before migrating, not during?" answer: "DNS changes take as long to propagate as your old TTL allows. Dropping it to 300 seconds 24–48 hours ahead means the short TTL is already live everywhere by the time you actually switch, so the risky window is minutes, not a day." - question: "What's the safest way to move the database if the domain changes too?" answer: "Use a tool that understands PHP serialization, such as wp search-replace with --all-tables --dry-run first. A plain SQL find-and-replace corrupts serialized data and breaks widget and plugin settings." - question: "What if I need to roll back?" answer: "Keep the old server running for at least 48 hours, and write down the old IP address and where the pre-migration database export is before you change DNS, so reversing the move takes minutes, not a scramble." --- Most WordPress migrations go wrong in one of two ways. Either the site is switched before the new server is genuinely ready, or content changes between taking the copy and pointing the domain, so orders, comments and posts made during the move quietly disappear. Both are avoidable with sequencing. Nothing here requires a paid plugin. ## Lower your DNS TTL first, days ahead This is the step people skip, and it is the one that decides how long the risky window lasts. Your domain's DNS records have a time-to-live telling resolvers how long to cache them. If it's set to 24 hours, some visitors will keep hitting your old server for a day after you switch. Drop it to 300 seconds **at least 24–48 hours before the migration**, so the old long TTL has expired everywhere by the time you move. After the migration settles, put it back up. ## Build the new site before touching the domain Copy files and database to the new host and get the site fully working there while the live site carries on untouched. To reach it before DNS changes, edit your local hosts file: ``` 203.0.113.10 example.com www.example.com ``` Now your machine resolves the domain to the new server while everyone else still sees the old one. This is the single most useful trick in a migration: you can test the real domain, with real URLs, in place. Work through the site properly at this stage: front page, a post, an archive, search, the admin, and any form or checkout. Finding a broken PHP extension now is a minor annoyance. Finding it after the switch is an outage. ## Move the database without a search-and-replace disaster If the domain isn't changing, the database moves as-is. If it is, URLs inside the database have to change too, and a plain SQL find-and-replace will corrupt serialised data, which is how sites lose widget and plugin settings. Use a tool that understands serialisation: ``` wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables --dry-run ``` Run the dry run first, read what it reports, then run it for real. Take a database export immediately beforehand. ## Sync again, immediately before the switch This is what protects the content written while you were working. Do a second, final sync right before you change DNS: the database, plus anything added to `wp-content/uploads`. For a busy site, put it in maintenance mode for the few minutes this takes, so nothing is written mid-copy. For the uploads directory, `rsync` only moves what changed, so the second pass is fast: ``` rsync -avz --delete wp-content/uploads/ user@newhost:/path/wp-content/uploads/ ``` ## Then switch DNS Point the A record (or CNAME) at the new server. With a 300-second TTL, most visitors follow within minutes. **Leave the old server running for at least 48 hours.** It costs one more month at worst, and it means anyone still resolving to the old address sees a working site rather than an error. Do not cancel the old hosting the same day, however tempting. ## After the move - Install the SSL certificate on the new host and confirm HTTPS works on both `example.com` and `www.example.com`. - Check the redirect between www and non-www still behaves. - Confirm email still sends. Site email often breaks in a migration because it silently depended on the old server's mail configuration. - Put your DNS TTL back to something sensible. - Watch the error log for a day. ## What if you need to roll back? Before you change DNS, write down exactly how to undo it: the old IP address, where the pre-migration database export is, and who needs telling. A migration you can reverse in five minutes is a different kind of risk from one you cannot. If the new site throws a database error on first load, that is usually credentials rather than anything you broke in the move. See [error establishing a database connection](/blog/error-establishing-a-database-connection).