Migrating WordPress to a new host without downtime
TL;DR: A WordPress migration causes downtime for one reason: people switch DNS before the site works on the new server, or they switch without lowering TTL first. Both are avoidable.
The sequence that works is build, test, sync, switch, overlap. Copy everything to the new host, test it thoroughly using a temporary URL while the domain still points at the old server, take a final data sync during a short maintenance window, then switch DNS with a low TTL already in place, then keep the old host running for a week while propagation completes. Done this way, most visitors experience nothing at all.
Why migrations go wrong
Four failure patterns account for nearly all of them.
Switching DNS before testing. The site is copied, DNS is pointed at the new server, and only then does anyone discover the PHP version is incompatible or a file permission is wrong. Now the live site is broken and you are debugging under pressure.
Not lowering TTL in advance. DNS records carry a time-to-live telling resolvers how long to cache them. If yours is set to 3600 or higher and you change it without preparation, some visitors continue reaching the old server for hours. If the old server has been shut down, those visitors see errors.
Losing data written during the migration. You copy the database on Monday, spend two days configuring, switch DNS on Wednesday. Every order, comment and form submission from Monday to Wednesday existed only on the old server, and is now gone.
A broken search and replace. WordPress stores absolute URLs throughout the database, including inside serialised PHP arrays. A plain SQL find-and-replace corrupts those arrays, and the symptom is widget settings and theme options silently reverting to defaults.
Every one of these is preventable by sequence rather than skill.
Before you start: the inventory
Fifteen minutes here prevents most surprises.
Record the current environment. PHP version, MySQL or MariaDB version, WordPress version, total disk usage, database size. If the new host runs a much newer PHP version, plan to test for compatibility rather than discovering it at switchover.
Export the complete DNS zone. Every record: A, AAAA, CNAME, MX, TXT, SRV, CAA. Screenshot it and save it as text. You will need this if you are also changing nameservers, and MX records are the ones people forget.
List what lives outside WordPress. Email accounts on the hosting plan, which do not migrate with a WordPress copy. Server-level cron jobs. Custom .htaccess rules. Subdomains. Any static files or applications outside the WordPress directory.
Note your integrations. Payment gateway with IP restrictions, SMTP service, any API whitelisting your server IP. A new server means a new IP, and whitelists need updating or things fail silently after the switch.
Take a full backup. Files and database, downloaded to a location that is neither host. This is your rollback.
Check the new host's PHP version and limits. Memory limit, max execution time, upload size. A large site migration can hit execution timeouts during import.
Two days out: lower TTL
The single most effective downtime-prevention step, and it only works if done in advance.
Set the TTL on your A record, and any other record you will change, to 300 seconds. Resolvers gradually replace the cached long value with the short one, so by the time you make the actual change, the world is checking every five minutes rather than every hour.
Lowering TTL at the moment of the switch achieves nothing, because resolvers are still holding the previous long-cached value. Two days of lead time is comfortable; 24 hours is usually sufficient.
Raise it back to 3600 or higher once everything is confirmed stable, since very short TTLs increase query volume slightly.
If you are also transferring the registrar, do that separately and earlier. Registrar transfer and hosting migration are different operations and combining them makes troubleshooting harder, as covered in the domain transfer guide.
Copying the site
Three routes, depending on your situation.
Host-provided migration. Most reputable Indian hosts offer free migration and will do the whole thing for you. They do this constantly, they know the failure modes, and the sequencing is exactly what they are good at. If it is available, use it. This is not a task where doing it yourself demonstrates anything.
Migration plugin. Several handle files and database together, producing an archive you import at the destination. Convenient and generally reliable for small to medium sites. Watch for execution timeouts on large sites, since the export or import can exceed PHP limits.
Manual copy. Full control, and necessary for very large sites where plugin-based transfer times out.
The manual sequence: archive the WordPress directory and transfer it, export the database with mysqldump, create a database and user on the new host, import the dump, update wp-config.php with the new database credentials, and set file permissions correctly, typically 755 on directories and 644 on files with wp-config.php at 600 or 640.
For large sites, compressing before transfer and moving a single archive is dramatically faster than transferring thousands of individual files over FTP.
The search and replace that breaks sites
Worth its own section because it is the most common way a technically correct migration produces a subtly broken site.
WordPress stores absolute URLs throughout the database. Post content, widget configuration, theme options, plugin settings, media references. If the domain is changing, or if you test on a temporary URL, those need updating.
The trap is serialisation. WordPress stores complex settings as serialised PHP arrays, and serialised strings include their own character length prefix. A plain SQL REPLACE changes the string but not the length prefix, and the array becomes unreadable.
The symptom is distinctive and confusing: the site works, but widget settings are empty, theme customiser options have reverted, and some plugin configuration has vanished. Nothing errors. Things are just silently gone.
Use a serialisation-aware tool. WP-CLI's search-replace command handles it correctly, as do the dedicated search-replace scripts and most migration plugins. Never run a raw SQL find-and-replace across wp_options or wp_postmeta.
If the domain is not changing, and you migrate to the same domain, you may not need a search and replace at all beyond the temporary testing URL. Plan the URL sequence so you replace once, not repeatedly.
Testing before DNS changes
This is the step that converts a risky migration into a safe one, and it requires reaching the new server while the domain still resolves to the old one.
Use the host's temporary URL if provided. Many hosts offer a preview address. Note that this changes the URL, so links and assets may not all behave identically.
Or edit your local hosts file, mapping your domain to the new server's IP on your own machine only. This is the better method, because you test the real domain against the new server with nothing else changed. Your visitors are unaffected; only your computer resolves differently.
Then test properly:
Homepage, several interior pages, a category archive, search results, a 404 page. Media loading from the uploads directory. Admin login and the post editor. A contact form submission, confirming both the database entry and the email. For a store: add to cart, view cart, reach checkout, and complete a test transaction in gateway sandbox mode.
Also check the PHP error log on the new server. A site can appear to work while logging warnings that indicate a plugin incompatibility with the newer PHP version.
Check performance too, since a migration is a reasonable moment to confirm the new host is actually faster.
Fix everything found here. A problem found now is an inconvenience; the same problem found after the DNS switch is an outage.
The final sync and the switch
The gap between your initial copy and the switch is where data goes missing.
For low-traffic sites with little changing, the gap may not matter. Confirm nothing important was written since the copy and proceed.
For active sites and any store, close the gap deliberately:
Put the old site into maintenance mode so nothing new is written. Export the database again from the old server. Import it to the new server, running the search-replace again if needed. Sync any new uploads added since the initial copy. Verify briefly on the new server via your hosts file. Then switch DNS.
The maintenance window is typically ten to thirty minutes, and it is far better than losing two days of orders.
Switching DNS means updating the A record to the new server IP, or changing nameservers if you are moving DNS management too. With TTL at 300, propagation is largely complete within minutes, though a small tail can persist longer.
Keep the old host running for at least a week. During propagation some visitors still reach the old server, and if it is live and functional they see the old site rather than an error. Cancelling on switch day turns a smooth migration into an outage for anyone with stale DNS.
That week of overlapping hosting is the cheapest insurance in this entire process.
| Stage | Timing | Visitor impact | Risk if skipped |
|---|---|---|---|
| Inventory and backup | Day -3 | None | No rollback available |
| Lower TTL to 300 | Day -2 | None | Hours of split traffic at switch |
| Copy files and database | Day -1 | None | — |
| Search-replace, serialisation-aware | Day -1 | None | Silently corrupted settings |
| Test via hosts file | Day -1 | None | Breakage discovered live |
| Maintenance mode on old site | Day 0 | Brief outage, 10-30 min | Lost orders and submissions |
| Final database and uploads sync | Day 0 | Within window | Data gap |
| Switch DNS | Day 0 | None if tested | — |
| Verify on new server | Day 0 | None | Undetected failures |
| Keep old host live | Day 0 to +7 | None | Errors for stale DNS |
| Raise TTL, update whitelists | Day +1 | None | Integration failures |
| Cancel old hosting | Day +7 | None | — |
After the switch
Within the first hour:
Confirm the site loads on both www and the bare domain. Check SSL, since the new host may need to issue a fresh certificate and a brief certificate gap is a common transient failure. Test admin login, a form submission, and checkout if you have one. Confirm email sends from the site, since SMTP settings or server IP reputation may differ.
Within the first day:
Update any IP whitelists: payment gateway, SMTP provider, external APIs, firewall rules on third-party services. This is the most commonly missed post-migration step and it produces silent failures rather than obvious errors.
Raise TTL back to a normal value. Verify backups are configured and running on the new host, since backup configuration does not migrate. Confirm cron is working, particularly scheduled posts and WooCommerce jobs. Check Search Console for crawl errors and confirm analytics is still recording.
Within the first week:
Compare performance against your pre-migration baseline. Check the error log for anything recurring. Confirm mail deliverability has not degraded by checking headers on a sent message. Verify that at least one backup on the new host restores successfully.
Then cancel the old hosting, and only then.
FAQs
How long does a WordPress migration take?
The copy itself is typically an hour or two for a small to medium site. The full process including preparation, testing and verification spans two to three days, most of it waiting rather than working. Actual visitor-facing downtime should be a maintenance window of ten to thirty minutes for the final sync, or none at all for a low-traffic site.
Will migrating hosts hurt my SEO?
Not if done correctly. Search engines care that the site remains available and the URLs remain the same. Problems arise from downtime during the switch, broken URLs after a careless search-replace, or missing redirects if the URL structure changes. Keeping the old host running during propagation prevents the most common issue.
What is TTL and why lower it before migrating?
TTL tells DNS resolvers how long to cache a record before checking again. Lowering it to 300 seconds two days before the switch means propagation completes in minutes rather than hours. It must be done in advance, because resolvers are otherwise still holding the previous long-cached value at the moment you make the change.
Can I migrate WordPress without any downtime at all?
For a site where nothing is written by visitors, effectively yes: test on the new server via your hosts file, switch DNS with a low TTL, and keep both servers live. For a store or any site accepting orders and submissions, a short maintenance window for the final data sync is safer than risking a data gap.
Why did my widgets and theme settings disappear after migrating?
Almost certainly a non-serialisation-aware search and replace. WordPress stores complex settings as serialised PHP arrays that include character length prefixes, and a plain SQL replace changes the string without updating the prefix, corrupting the array. Use WP-CLI's search-replace or a dedicated tool rather than raw SQL.
Should I use a migration plugin or manual migration?
Use your new host's free migration service if offered, since they do this constantly and know the failure modes. Migration plugins are convenient for small to medium sites but can hit PHP execution timeouts on large ones. Manual migration gives full control and is necessary for very large sites, at the cost of more steps to get right.
How do I test the new server before changing DNS?
Edit your local hosts file to map your domain to the new server's IP. Only your machine resolves differently, so you test the real domain against the new server while visitors continue reaching the old one unaffected. This is better than a host-provided temporary URL, since the URL itself does not change.
What happens to my email when I migrate hosting?
Email hosted on the old hosting plan does not migrate with a WordPress copy and needs separate handling. If you use an external provider such as Google Workspace, your mail is unaffected by a hosting change but is affected by any nameserver change, so MX and authentication TXT records must be replicated exactly.
How long should I keep the old hosting after migrating?
At least a week. During DNS propagation some visitors still reach the old server, and if it remains live they see the old site rather than an error. Cancelling on switch day is a common mistake that creates an outage for anyone whose resolver still holds the old record.
Do I need to update anything after the DNS switch?
Yes, and this step is commonly missed. Your server IP has changed, so update IP whitelists at your payment gateway, SMTP provider, any external APIs and third-party firewalls. Also reconfigure backups, verify cron is running, and raise TTL back to a normal value. Whitelist failures are silent rather than obvious.
Will my SSL certificate transfer to the new host?
Usually not directly. Most hosts issue a fresh certificate for your domain, which can take a short time after DNS points at the new server. A brief certificate warning immediately after the switch is a common transient issue. Confirm HTTPS works properly within the first hour and force HTTPS redirects at the new host.
Should I migrate and redesign at the same time?
No. Migrate first, confirm the site is stable on the new host, then redesign. Combining them means that when something breaks you cannot tell whether the cause is the new server or the new code, and troubleshooting takes several times longer.
Conclusion
Migration downtime is a sequencing problem, not a technical one.
Build on the new server. Test against it with your hosts file while the world still reaches the old one. Take a short maintenance window for the final sync so nothing written in between is lost. Switch DNS with a low TTL already in place. Keep the old host running for a week.
Two details cause disproportionate damage. Lower TTL two days in advance rather than at the moment of the switch, because doing it late achieves nothing. And use a serialisation-aware search and replace, because raw SQL silently corrupts settings in a way that is hard to notice and harder to reverse.
After the switch, update your IP whitelists. Your server IP changed, and payment gateways, SMTP providers and API whitelists fail silently rather than loudly, which means you find out from a customer rather than from a log.
And if your new host offers free migration, take it. There is no prize for doing this manually, and the people who migrate sites daily are better at the sequencing than someone doing it once every three years.
HostCloud includes free migration on all plans, handled by our team with the DNS sequencing managed so you keep both servers live through propagation. Indian infrastructure, LiteSpeed, NVMe, from ₹99 a month at https://hostcloud.in.