How to migrate to a new web host without downtime

Migrating to a new web host feels risky because a botched move can take your site offline and cost you traffic, sales, and trust. The good news is that with the right sequence, you can move without any downtime at all. This guide walks through a proven method that keeps your current site live while you build and verify a complete copy on the new host, then switches over cleanly.

Understand why zero downtime is achievable

The key insight is that your domain name and your hosting are separate things. Your domain points to a server through DNS, and you control which server it points to. That means you can run two copies of your site at once, the old one still serving visitors and the new one waiting quietly, and flip the pointer only when you are confident the new copy works. Nothing forces you to break the old site before the new one is ready.

Downtime during migration almost always comes from doing steps in the wrong order, such as changing DNS before the new site is tested, or deleting the old account too soon. Follow the sequence below and the transition becomes invisible to your visitors.

Choose the right new host before you start

A migration is a good moment to make sure you are moving to the right place, not just a different place. Match the new plan to your actual resource usage rather than guessing. Look at your current CPU, memory, and storage consumption, then find a plan that comfortably exceeds it. Our guide on how much RAM your website needs helps you size memory correctly so you do not overpay or under provision.

Compare candidates on the providers listing and check specific configurations on the plans page. If cost is a deciding factor, the VPS cost tool lets you compare monthly pricing across providers for equivalent specs. Decide before you begin, because switching targets mid migration wastes effort.

Take a complete, verified backup first

Before touching anything, make a full backup of everything: all website files, the complete database, and any configuration such as web server rules, cron jobs, and environment variables. Download this backup to your own machine, do not rely solely on a copy that lives on the host you are leaving. A backup you have not tested is only a hope, so open the archive and confirm the files and database dump are intact and complete.

This backup serves two purposes. It is the source material for the migration, and it is your safety net if anything goes wrong. Keep it until the migration is fully confirmed and stable.

Lower your DNS TTL a day or two ahead

DNS records carry a Time To Live value that tells resolvers around the world how long to cache them. If your TTL is set to the common default of 3600 seconds or higher, a change can take an hour or more to reach everyone. Log into your DNS provider and lower the TTL on the relevant records, typically the A and AAAA records, to 300 seconds.

Do this at least one full day before the planned cutover so the old, longer TTL has time to expire everywhere. When you later make the real switch, the short TTL means resolvers recheck quickly and your visitors move to the new server within minutes. You can raise the TTL again after the migration settles.

Build and copy your site to the new host

With backups in hand, recreate your site on the new host. Upload all files, import the database, and replicate your configuration. For platforms like WordPress, a reputable migration plugin can automate much of this, but always verify the result manually. Match the software versions where possible: the same PHP version, the same database engine, and the same key extensions, so behavior is consistent.

At this stage the new site is not yet receiving public traffic. Your domain still points to the old host, so you are working on a hidden copy. Take your time and get it right, because nothing you do here affects live visitors.

Test the new site before touching DNS

This is the step that separates a smooth migration from a stressful one. You need to test the new site thoroughly while your domain still points to the old server. Do this by overriding DNS locally on your own computer using your hosts file, which lets your browser resolve the domain to the new server IP while everyone else still sees the old site.

With the override in place, click through the entire site as if you were a real user:

• Load the homepage and several internal pages, checking images, styles, and scripts all load.
• Submit forms, including contact and search, to confirm backend functionality works.
• If you run a store, complete a test checkout end to end.
• Log into any admin area and confirm you can manage content.
• Check that database driven features such as comments, accounts, and dynamic content behave correctly.

Only when every important path works on the new host should you proceed. Fixing problems now is free, fixing them after cutover happens under pressure.

Sync any last minute data changes

If your site accepts new data such as orders, comments, or user signups, some of that may have arrived on the old host after you took your backup. Just before cutover, do a final sync of the database and any new uploaded files so the new host is fully current. For very active sites, plan the cutover during your quietest hours to minimize the window in which new data lands only on the old server.

For static sites or sites where content rarely changes, this step is trivial. For busy dynamic sites, a short maintenance notice during the low traffic sync window is a reasonable tradeoff, though many sites can skip it entirely by syncing incrementally.

Switch DNS to the new server

Now make the actual change. Update the A record, and the AAAA record if you use IPv6, to point at the new server IP address. Because you lowered the TTL earlier, resolvers will pick up the change within minutes. Both servers are running at this point, so as visitors migrate from one to the other, nobody sees an error. Some will hit the old server, some the new, and both work.

If you use a CDN such as Cloudflare, you may be able to change the origin server in the CDN dashboard instead, which propagates almost instantly because the public facing IP does not change. This is one of the cleanest ways to cut over.

Do not forget email and other records

If your email is hosted on the same account as your website, changing web hosting can silently break mail. Email is controlled by separate MX records. Confirm whether your email lives with your web host or with a dedicated provider. If it moves with the site, replicate the mail accounts on the new host and update MX records carefully, testing that you can send and receive before cutover.

Also review other records that point to your host, such as SPF, DKIM, and DMARC for email authentication, and any subdomains for staging, mail, or apps. A migration that fixes the website but breaks email is not a success.

Migration checklist table

Monitor closely after cutover

Once DNS is switched, watch your new host carefully for the first several hours and days. Check server logs for errors, watch your analytics to confirm real traffic is arriving, and set up uptime monitoring that alerts you if the site becomes unreachable. Keep an eye on resource usage too, because a new environment can behave differently under real load than it did during quiet testing.

Because DNS caches can linger past the TTL in some networks, expect a small tail of traffic to keep hitting the old server for a day or two. This is normal and harmless as long as both servers still work, which is exactly why you keep the old one running.

Decommission the old host safely

Resist the urge to cancel the old account immediately. Keep it active and unchanged for at least one to two weeks after cutover. During this window, confirm through analytics and server logs that essentially all traffic now reaches the new host, that email flows correctly, and that no scheduled jobs or integrations still depend on the old server. Only when you are fully confident should you take a final archival backup and cancel.

This patience costs a little extra hosting fee but buys a guaranteed fallback. If a subtle problem surfaces days later, you can point DNS back to the old host in minutes rather than scrambling to rebuild from a backup.

Conclusion

Migrating without downtime is not about luck, it is about order. Back up completely, lower your TTL, build and test the new site while the old one keeps serving, then switch DNS only after everything is verified, and keep the old host as a safety net. Follow that sequence and your visitors will never know the move happened. The extra care during testing and the short overlap period are cheap insurance against the far larger cost of a broken site.

Planning a move and want to compare where you are going? Browse current options on the providers listing and estimate the cost of your new setup with the VPS cost tool before you commit.

Frequently asked questions

How long does a website migration take?

A simple static or small WordPress site can migrate in a few hours of active work, though DNS propagation adds time afterward. Larger sites with big databases, custom code, or email accounts can take a day or more to move and verify carefully. The active copying is usually fast, and most of the elapsed time goes to testing and waiting for DNS changes to settle.

Will my site go down during migration?

It does not have to. The zero downtime method keeps your old host live and serving traffic while you build and test a complete copy on the new host. Only after the copy is verified do you switch DNS, and because the old site stays online until propagation finishes, visitors never hit a broken page. Downtime happens only when people cut over before testing.

What is DNS TTL and why does it matter for migration?

TTL, or Time To Live, tells resolvers how long to cache a DNS record before checking again. A high TTL means changes take longer to reach everyone. Lowering the TTL to 300 seconds a day or two before migration means that when you switch to the new server, visitors pick up the change within minutes instead of hours, which shrinks the risky transition window.

Should I keep my old hosting after migrating?

Yes, keep the old account active for at least one to two weeks after cutover. DNS caches can linger, some visitors and monitoring tools may still reach the old server, and you want a proven fallback if something goes wrong. Once analytics and logs confirm all traffic hits the new host and everything works, you can safely cancel the old plan.

Do I need to move my email when I change web hosts?

Only if your email is hosted on the same account as your website, which is common with bundled shared hosting. Email uses separate DNS records called MX records, and moving web hosting without updating them can silently break mail. Many people take the migration as a chance to move email to a dedicated provider so the two services are no longer tied together.