How to Move a Website to a New Host Without Downtime

To move a website to a new host without downtime, run both hosts side by side: lower your DNS TTL a day or two ahead, take a full backup, copy the files and database to the new server, test the copy privately through your computer's hosts file, then switch DNS while the old site keeps serving visitors. Keep the old hosting running for a while after the switch, and copy your email records across, so nothing breaks while the change spreads.

Downtime during a move almost never comes from the copying itself. It comes from the order of steps: DNS changed before the new site was tested, email records forgotten, a PHP version mismatch, or the old plan cancelled too early. This guide covers the order that avoids those problems, written for WordPress and other PHP and MySQL sites, though the same plan works for most websites.

#Why sites go down during a move

DNS is the internet's directory: it tells browsers which server answers for your domain. When you change it, the change does not reach everyone at once. Resolvers around the world keep the old answer for as long as the record's TTL (time to live, in seconds) allows. For a while some visitors reach the old server and some reach the new one.

That is not a problem if both servers serve a working copy of the site. It is a problem if the old server is already switched off, the new one is half set up, or orders keep arriving on the old copy and are lost. The whole plan below is about making that overlap safe.

#Before the move: plan, lower TTL and back up

#1. Write down what you have

Before touching anything, list where the domain is registered, which company hosts your DNS (it may be the registrar, the old host or Cloudflare), where email is hosted, and what software the site runs on. Export or screenshot every DNS record. That record list is your safety net if something goes wrong.

#2. Lower the TTL a day or two ahead

Find the A record (and the www record) for your site and lower its TTL to a short value, such as 300 seconds (five minutes), which is also Cloudflare's automatic TTL. Do this at least as long before the move as the current TTL, because resolvers keep the old value until it runs out. If the current TTL is a day, lower it more than a day ahead.

#3. Take a full backup and store it off both servers

Back up all files and the database, and keep the copy on your computer or cloud storage, not only on the old host. The WordPress guide on moving sites starts with the same step: back up the WordPress folder, uploads, plugins and the database before anything else.

#Copy the site to the new host

#4. Prepare the new server to match the old one

Check the PHP version on the old server and set the same one on the new host, along with the PHP extensions and memory limit the site needs. Moving and upgrading PHP in one step makes problems hard to trace. Upgrade separately, after the move; my article on PHP 8.2 end of life explains how to plan that.

#5. Copy the files and database

Copy the site files with SFTP, the host's migration tool or a migration plugin, then export the database and import it into a new database on the new host. For WordPress, update wp-config.php with the new database name, user, password and host, which may not be localhost on every host.

If the domain stays the same, the copy should need no URL changes. If you do change URLs (for example, testing on a temporary address), never run a plain find and replace on the database file. WordPress warns that this breaks serialized data, where some plugins store the length of each text value. Use a tool that understands it, such as WP-CLI's search-replace command, which handles serialized data and has a --dry-run option to preview changes.

#Test before anyone else sees it

#6. Preview the new server with your hosts file

Your computer's hosts file lets you point a domain to an IP address for your machine only. Everyone else keeps seeing the old site while you test the new one under the real domain, which is the most accurate test there is.

Add one line with the new server's IP and your domain, for example 203.0.113.10 example.com www.example.com, save, and open the site in a private browser window. Many hosts also give a temporary URL or preview link, which is fine for a quick look, but it can trip up WordPress and caching because the address is different.

Remove the line when you finish testing, or you will keep seeing the new server after DNS changes and miss problems other visitors see.

#7. What to test on the copy

• Home page, key pages and a few old blog posts
• Logging in to the admin area, and saving a test change
• Contact forms, and whether their emails arrive
• For a shop: product pages, cart, checkout in test mode, and order emails
• Images and downloads loading from the new server
• Error logs on the new host after you click around

#Switch DNS and keep email working

#8. Freeze changes and do a final sync

If the site takes orders, bookings or comments, pick a quiet time, pause changes on the old site (a maintenance notice for checkout, or simply no edits), and copy the database again so the new server has the latest data. For a brochure site that rarely changes, the first copy is usually enough.

#9. Change the website records, not everything

You have two ways to switch:

Updating only the A record is the safer choice when DNS is not hosted at the old web host. If you must move nameservers, recreate every record on the new DNS host first and compare the two lists line by line. Email records are the ones people forget, and the result is mail that bounces or lands in spam for days; my guide to SPF, DKIM and DMARC setup shows what those records should contain. My guide to DNS records and connecting a domain explains what each record does.

If your email is hosted by the old web host (common with cPanel plans), decide before the move whether email moves too. Moving mailboxes is its own job with its own steps, and it is best not to mix it into the same evening as the website switch.

#After the move

#10. Post-move checks

• Visit the site from mobile data or a different network, and confirm it is served from the new IP.
• Check that HTTPS works on the domain with and without www.
• Submit a contact form and place a test order again, now on the live address.
• Send an email to and from your business address.
• Check that scheduled jobs (backups, WordPress cron, feeds) run on the new server.
• Watch error logs and uptime for a few days.
• Put the TTL back to a normal value once all is stable.

Keep the old hosting active for at least a week. Some resolvers hold old answers longer than they should, and if something was missed, the old server is the quickest place to recover it from. Cancel only when the new server has its own working backups; a simple backup and disaster recovery plan helps you set those up.

#When to get help

Doing it yourself is reasonable for a small brochure site where a short glitch costs little, as long as you follow the order above. Get help when the site takes payments or bookings every hour, when email is hosted with the old provider, when you are moving nameservers with many records, when the site runs on a VPS you have to set up first, or when the old host only offers a partial backup.

My website hosting migration service handles the whole move, including the test copy and post-move checks, and domain, DNS and Cloudflare setup covers the DNS side on its own. If you are still choosing where to move, how to choose WordPress hosting in India is a good place to start.