How to move your website to a new host without downtime

Moving a website to a new host sounds risky, but with a clear plan it is a calm, predictable job. The trick is to build and test the new copy while the old one keeps serving visitors, and only then point your domain across. This guide walks through the whole process for a typical small site, using WordPress as the main example and covering static and custom PHP sites in general terms.

Decide when to move and take stock of what you have

Good reasons to move include repeated slow loading or outages, a plan that no longer fits your traffic, missing features such as a current PHP version or staging tools, poor support, or a renewal price that has climbed beyond what the service is worth. Bad reasons include a single bad afternoon or a flashy offer you have not compared properly. If you are still weighing options, our guide on how to choose web hosting covers what to look for, and the one on hosting renewal prices explains why the cost after the first term often changes.

Pick a quiet period for the move. For most sites that means a weekday evening or a weekend with low traffic, and never the week of a big sale, launch or campaign. Give yourself a few days of margin, even if the actual work takes only a couple of hours.

Before you touch anything, write down everything your current host does for you. Sites often depend on things nobody remembers setting up. Here is a simple inventory to fill in.

Export your current DNS zone as text or take screenshots of every record. This one step prevents more post-move panic than any other. Also check whether your domain registration and your hosting are with the same company. If you are unsure how those two pieces fit together, domain names and hosting explains the relationship.

Back up, build the new site and test it privately

Take a full backup of files and databases, and store it somewhere other than the old host, such as your own computer plus a second location. Do not rely only on the host's automatic backups, because you may lose access to them if the account closes. Check that the backup actually opens. A backup you have never restored is only a hope.

Set up the new host

Create the account or plan, add your domain as a site or addon domain, and choose the same major PHP version your site runs today, or a newer one you have already confirmed your code supports. Create an empty database and a database user with a strong password. Do not change the DNS yet. At this stage the new host is just a blank room waiting for your furniture.

Copy files and database

Upload your files using SFTP or the file manager in the control panel. SFTP is preferred over plain FTP because it encrypts your login. For a large site, compress the folder into one archive, upload it, and extract it on the server, which is far faster than sending thousands of small files.

Then export your database from the old host and import it into the new one. For WordPress, there are two common routes. You can use a migration plugin that packages files and database together, or you can do it by hand: copy the files, import the database, then edit the wp-config.php file with the new database name, user and password. A static site needs only the files. A custom PHP site needs the files, the database, and a careful look at any configuration file that stores paths, credentials or API keys.

Test before you switch

Now check the new copy while the public still sees the old one. There are two reliable ways to do this.

• Edit your hosts file. On your own computer, add a line that maps your domain name to the new server's IP address. Your browser then loads the new copy while everyone else still sees the old one. Remove the line when you are done.
• Use a temporary URL. Many hosts provide a preview address for new accounts. This is easier, though some applications, including WordPress, may redirect you back to the real domain, which is why the hosts file method is usually cleaner.

While testing, click through the home page, a few inner pages, search, forms, logins, checkout if you have one, and image galleries. Submit a test contact form and confirm the email arrives. Look for broken images, mixed content warnings and error pages. Compare the new copy against the old one side by side.

Lower the TTL, freeze changes and switch DNS

DNS is the system that turns your domain name into a server address. Every DNS record has a TTL, short for time to live, which tells other networks how long they may remember the answer before asking again. If your TTL is a day long, some visitors may keep going to the old server for up to a day after you switch.

At least two days before the move, lower the TTL on your key records to something short, such as five minutes. This must happen early, because the old long TTL has to expire everywhere first. Lowering it an hour before the switch does little.

Freeze content changes

Once your final copy is made, stop changes on the old site. A blog can simply pause publishing. A shop is trickier, because orders placed on the old server after your final database copy will not exist on the new one. For stores, membership sites and forums, schedule a short maintenance window, take the final database copy at the start of it, and avoid orders during the gap. Then do a final sync of files and database to the new host and run a last quick test.

Switch the records

You have two ways to point your domain at the new host.

• Change the A record (and AAAA if used) at your current DNS provider so it points to the new server's IP address. This leaves the rest of your DNS, including email, exactly as it is. It is the safer option for most people.
• Change the nameservers at your registrar so the new host controls all DNS. This is tidy, but only do it after you have recreated every record from your inventory on the new host, especially MX and TXT records. Missing records are the usual cause of lost email after a move.

How long propagation really takes

People often say DNS takes up to 48 hours, but this is a worst-case habit rather than a rule. Nothing actually spreads out from your DNS provider. Instead, thousands of resolvers around the world each keep their own cached answer, and each one refreshes it only when its timer runs out. With a short TTL set in advance, most visitors reach the new server within minutes to a few hours. Nameserver changes can take longer because the registry level has its own caching, and some internet providers hold on to answers longer than they should. This is why the old host must stay live during the transition. Some people will see the old site, some the new one, and both must work.

You can check progress with public DNS lookup tools that query many locations, or with a command line lookup on your own machine. Remember that your own computer and router also cache answers, so testing from a phone on mobile data can give a useful second opinion.

Handle email, SSL and URLs

Email and MX records

Email is the part most often forgotten. First find out where your mail lives. If it is hosted with your old web host, you must move the mailboxes too, including the stored messages. Create the same mailboxes on the new host, then copy old mail across using an IMAP transfer tool or by adding both accounts to a mail program and dragging folders over. Keep sending and receiving on the old server until the copy is complete.

The MX records tell the world where to deliver your mail. If you only change the A record, MX stays untouched and mail keeps flowing to wherever it goes today. If you change nameservers, copy the MX records exactly, plus SPF, DKIM and DMARC TXT records, which help your messages avoid spam folders. If your email is with a separate email provider, leave its records alone entirely. When in doubt, send test messages in both directions the same day.

SSL certificates

A secure padlock requires a valid certificate on the new server. Most hosts can issue a free automatic certificate, but they usually need the domain to be pointing at them first, so issuance may only succeed after the DNS switch. Plan for a short window and trigger the request as soon as the records change. Some hosts let you install a certificate early, which avoids a gap. After it is active, check that every page loads over HTTPS without mixed content warnings, and that HTTP addresses redirect to HTTPS.

Redirects and URLs

Keep your URLs identical wherever possible. If the web address of a page changes, add a permanent redirect from the old address to the new one so visitors and search engines follow it. Carry across your redirect rules, which often live in a hidden file called .htaccess or in server configuration. Check also that your preferred version of the domain, with or without www, behaves the same as before. If you also change the domain name itself, that is a separate project and deserves its own plan.

Monitor after the switch and keep a rollback plan

For the first few days, watch the site closely. Load key pages regularly, test forms and checkout, and look at server error logs. Set up a free uptime monitor if you do not already have one. Confirm that scheduled tasks run, since cron jobs are easy to forget. For WordPress, make sure scheduled posts publish and backup plugins work. Re-create backups on the new host and check that your analytics and search console tools still report data.

Your rollback plan is simple because you prepared for it. The old site is still running and your original DNS records are saved. If something serious breaks and cannot be fixed quickly, change the records back to the old values. Thanks to the short TTL, the reversal also spreads fast. Decide in advance what counts as serious, for example checkout failing or email not arriving, so you are not debating it under stress.

Keep the old plan for a short overlap, commonly one to two weeks, and longer if you are unsure about mail or have a monthly billing cycle. Do not cancel it the same day. Before you do cancel, take one last backup, confirm there is no mail left on it, and check that nothing, such as a subdomain or a small side project, still depends on it. Also check whether your domain registration was bundled with the old plan so you do not accidentally lose it.

Common mistakes and when to get help

• Forgetting email. Mail stops because MX or TXT records were not copied.
• Leaving the TTL high. The switch then drags on for hours or days.
• Skipping the test. Problems show up in front of customers instead of in private.
• Cancelling the old plan too early. This removes your safety net while DNS is still settling.
• Editing both copies. Content added on the old site during the move is lost.
• Not saving the DNS records. You cannot rebuild what you did not write down.
• Ignoring PHP and software versions. An old plugin may fail on a newer server version.

Many hosts offer a free migration service, usually for new customers moving a standard site. It is worth using for simple WordPress sites, because it saves time and the experts have done it many times. Ask a few questions first. Does it cover files, databases and email? How many sites or mailboxes are included? Will they test the site before the switch, and will you get a preview? Is the old site left untouched? Who handles DNS, and what happens if something goes wrong? Are there limits on size, custom code or particular applications? Get the answers in writing where you can.

Consider paid professional help if you run a shop with live orders, a membership or booking system, a large database, custom code nobody on your team wrote, or complicated email setups. A freelancer or agency can also be sensible when downtime would cost you more than their fee. Even if you hire someone, keep your own inventory and backups, and keep control of your domain account.

A sample migration timeline

1. One week before: Decide to move, choose the new host, and complete your inventory of files, databases, email, cron jobs, DNS and SSL.
2. Three to five days before: Export the DNS zone, take full backups, and confirm they restore.
3. Three days before: Lower the TTL on your key DNS records to a few minutes.
4. Two days before: Set up the new host, copy files and database, and update configuration.
5. One day before: Test through the hosts file or a temporary URL, and fix problems.
6. Switch day, start: Freeze content changes, make a final sync of files and database, and run a quick test.
7. Switch day, middle: Update the A record or nameservers, then request the SSL certificate.
8. Same day: Check that email still flows in both directions, and confirm HTTPS and redirects work.
9. Days one to three: Monitor uptime, logs, forms, cron jobs and analytics. Unfreeze content when you are confident.
10. Days seven to fourteen: Take a last backup from the old plan, confirm nothing depends on it, and cancel it. Raise the TTL back to a normal value.

Pre-flight and post-flight checklist

Pre-flight

• Inventory written down: files, databases, email, cron jobs, DNS records, SSL.
• DNS zone exported and saved outside the old host.
• Full backups taken, stored in two places, and test-restored.
• TTL lowered at least two days before the switch.
• New host set up with a matching or compatible PHP version.
• Files and database copied, configuration updated.
• Site tested through the hosts file or a temporary URL, including forms and logins.
• Email plan decided, mailboxes created, old messages copied.
• Content freeze scheduled and announced to anyone who edits the site.
• Rollback plan written, with the original DNS values to hand.

Post-flight

• Domain loads from the new server on several networks and devices.
• HTTPS works on every page, and HTTP redirects to HTTPS.
• Email sends and receives, and SPF, DKIM and DMARC records are in place.
• Forms, checkout, search and logins work.
• Redirects and the www or non-www preference behave as before.
• Cron jobs and scheduled tasks run.
• Uptime monitoring and backups are active on the new host.
• TTL raised again after things are stable.
• Old plan kept for one to two weeks, then cancelled after a final backup.

One note on transparency: DealPortal may earn a commission if you buy through some links on our site, and that does not change the price you pay or the advice we give.

Key takeaways

• Build and test the new copy privately first, using the hosts file or a temporary URL, while the old site keeps running.
• Lower your DNS TTL at least two days ahead, and save a copy of every DNS record before you change anything.
• Treat email as its own task: move the mailboxes, copy MX, SPF, DKIM and DMARC records, and test in both directions.
• Propagation is usually quick with a short TTL, but some visitors will see the old site for a while, so never shut the old one down early.
• Keep the old plan for one to two weeks and have a written rollback plan ready.
• Use a free migration service for simple sites, and hire a professional for shops, custom code or anything where downtime is costly.