How to Migrate a Website Without Downtime

Illustration of a website moving safely between two servers across a bridge with no downtime.

To migrate a website without downtime, copy all your files and database to the new host, rebuild and fully test the site there using a temporary URL, then lower your DNS TTL and switch your domain. Keep the old host active until the new one is confirmed working, so visitors never see an outage.

Key takeaways

  • Migration means moving two things: your website files and your database from one host to another.
  • The golden rule: never cancel the old host first. Keep it live until the new site is fully tested and the domain has switched over.
  • Test before you switch. Preview the site on the new server with a temporary URL or a local hosts-file trick before you touch DNS.
  • Lower your DNS TTL a day ahead so the domain switch propagates quickly and cleanly.
  • Ask the new host about free migration — many will move the entire site for you at no cost.
Disclosure: Some links on this page are affiliate links. If you sign up through them, we may earn a commission at no extra cost to you. We only recommend what genuinely helps with this page's topic, and our guidance stays the same either way.

What website migration actually means

Website migration is the process of moving a website from one hosting provider (the company whose servers store and serve your site) to another. Despite how it sounds, it is not one single action. A working website is really two separate things bundled together, and both have to travel.

The first part is your files. These are the actual documents that make up your site: HTML pages, images, PHP scripts, stylesheets, JavaScript, PDFs, and everything inside your site's folders. On most hosting accounts these live in a directory called public_html or www. If you run a simple static or brochure site, files may be nearly all you have.

The second part is your database. A database is an organized store of your site's content and settings — things like blog posts, pages, user accounts, comments, product listings, and configuration. Platforms such as WordPress, Joomla, and most online stores keep almost everything you type in a MySQL or MariaDB database. Your files display the site; your database holds the words and data that fill it in. Move one without the other and you get a broken, half-empty website.

So when we talk about migrating a website, we mean copying both the files and the database to a new server, rebuilding the site there exactly as it was, and finally pointing your domain name at the new home. Do it in the right order and your visitors never notice a thing. If you are new to how the pieces of hosting fit together, the Hosting Help Center is a good place to get your bearings first.

Why people move their website to a new host

Nobody migrates a website for fun. It is almost always driven by a real, ongoing frustration with the current host. If any of the reasons below sound familiar, you are in good company — these are the three most common triggers.

1. Slow or unreliable hosting. This is the number-one reason. If your pages load slowly, your site goes down at random, or your dashboard crawls, the culprit is often an oversold shared server — one where the host has packed too many websites onto the same machine, so everyone competes for the same limited resources. Slow, flaky hosting costs you visitors and search rankings. Sometimes it is the host; sometimes it is your own site's configuration. Before you migrate, it is worth confirming the problem really is host-bound.

2. High renewal prices. Many hosts advertise a low introductory rate for the first term, then renew at a much higher price. When that renewal invoice lands, a lot of owners decide to move rather than pay two or three times what they signed up for. Migrating to a new provider on a fresh introductory plan is a common, legitimate way to control costs.

3. Outgrowing your plan. Success brings its own problems. As your traffic climbs, a basic shared hosting plan (where many sites share one server) may no longer keep up. You start hitting resource limits, seeing "resource limit reached" errors, or watching performance sag at busy times. That is the signal to move up to a bigger plan or a VPS — a virtual private server that gives you a guaranteed, dedicated slice of a machine. Our guide on shared hosting to VPS migration covers that specific jump in detail.

Quick gut-check before you move: Is the problem really your host, or your site? Test your site's speed at a few different times of day, and check whether a lightweight page loads slowly too. If even a near-empty page is slow, or the site drops offline regularly with no change on your end, the host is the likely cause and migrating will help. If only one bloated page is slow, fix the page first.

The golden rule: don't cancel the old host yet

If you remember one thing from this entire guide, make it this: keep your old hosting account active and paid until the new site is fully working, fully tested, and your domain has finished switching over. Never cancel the old host first.

Here is why this matters so much. During a migration there is a window — usually a few hours, sometimes up to a day or two — when the internet is still learning that your domain has a new address. This is called DNS propagation, and we will cover it in detail below. During that window, some visitors are routed to the old server and some to the new one. If the old server has been deleted, those visitors hit a dead end: a blank page or an error. Your site effectively goes down for part of your audience.

Keeping the old host live closes that gap completely. Because both servers hold a working copy of your site during the switch, every visitor sees a working page no matter which server they land on. The result is a genuinely seamless move — zero downtime. The old host is your safety net, and it costs you only a few extra days of a hosting bill you were already paying. That is the cheapest insurance in all of web hosting. Only after everything checks out on the new host do you cancel the old one.

Do not cancel, delete, or let the old plan lapse until you have confirmed the new site works on your real domain. A cancelled old host during propagation is the single most common cause of migration downtime — and it is completely avoidable.

The safe step-by-step migration process

This is the heart of the guide: a repeatable, downtime-free process for moving any website. Follow the steps in order. Each one is a single, clear action, and the sequence is deliberately built so that nothing your visitors can see changes until the new site is proven to work.

  1. Choose your new host and plan. Pick a provider and a plan that matches your site's needs — enough storage, the right features (such as SSL and email), and room to grow. If you are unsure how to compare providers, work through how to choose web hosting first so you land somewhere you will not have to leave again in six months.
  2. Back up everything — all files and the database. Before you touch anything, make a complete backup of your current site: every file and a full export of the database. This is your undo button. Download the backup to your own computer so a copy exists outside both hosts. Our website backups guide walks through exactly how to capture both parts safely.
  3. Check if the new host offers free migration. Before doing any manual work, log in to the new host or ask their support whether they include free migration. Many providers will move your entire site — files, database, and settings — for you at no charge. If they do, hand it over and skip the manual copying below. Their team does this every day and will often finish faster and cleaner than a first-timer.
  4. Copy the files and move the database. If you are moving the site yourself, upload all your files to the new server using FTP (a file-transfer tool such as FileZilla) or the host's File Manager, placing them in the new public_html folder. Then export the database from the old host — usually as a .sql file from a tool called phpMyAdmin — and import that file into a new, empty database on the new host.
  5. Rebuild the site on the new server and test it with a temporary URL — before changing DNS. Once the files and database are in place, connect your app's config to the new database (for many sites this means editing a configuration file with the new database name, user, and password). Now preview the site without changing your domain yet. Use the new host's temporary URL (a preview address they provide) or edit your computer's hosts file to make only your machine see the new server. This lets you view the new site on your real domain privately, so you can confirm it works before the public switch.
  6. Lower your DNS TTL a day ahead. In your domain's DNS settings, find the TTL (time to live — how long the internet caches your DNS records) and set it to a low value such as 300 seconds. Do this about a day before the switch. A low TTL means the world picks up your new address in minutes instead of hours, making the final cut-over fast.
  7. Point the domain to the new host. When testing passes, make the switch: either update your domain's nameservers to the new host's, or change the A record (the DNS entry that maps your domain to the server's IP address) to the new server's IP. Our guide on how to point a domain shows both methods step by step.
  8. Let propagation happen — both hosts serve the site. After you switch, DNS propagation begins. Because you kept the old host live and copied the site to the new one, both servers now serve a working site. Visitors routed to either one see a normal page, so there is no downtime. You can watch the switch roll out worldwide using the tips in flush DNS and check propagation.
  9. Verify everything on the new host. Once propagation is well underway, go through the live site carefully: click through pages, test internal and outbound links, submit a form, send and receive email on your domain, and confirm your SSL certificate is active so the address shows https:// with no warnings. If SSL is new to you, see what is an SSL certificate. Fix anything that looks off while the old host is still your backup.
  10. Only after it's confirmed working, cancel the old host. When the new site has served your live domain cleanly for a few days and every check passes, you can finally cancel the old hosting account. Wait until you are certain — the small cost of a few overlapping days is nothing next to the risk of pulling the plug too early.

How to avoid downtime during the switch

"Downtime" is any period when visitors cannot reach a working version of your site. During a migration the danger zone is the DNS switch, but with three simple habits you can keep that zone at effectively zero. Everything else in this guide supports these three ideas.

1. Lower the TTL first. A day before you switch, drop your DNS TTL to a low number like 300. This shrinks how long any stale address stays cached around the world, so when you flip the switch the new address spreads in minutes. The switch becomes a quick, clean cut-over instead of a slow, messy one.

2. Test before switching. Never point your domain at the new host and then find out the site is broken. Use the temporary URL or the local hosts-file preview from Step 5 to prove the new site works on your real domain first. If something is wrong, you fix it privately while the public still sees the old, working site. Only switch once you are confident.

3. Keep the old host live through propagation. This is the golden rule again, and it is what turns "almost no downtime" into "genuinely no downtime." While DNS propagates, both servers answer for your domain. Whichever one a visitor reaches, they get a working page. Keep the old host running until propagation is finished and every check has passed, then retire it.

The zero-downtime formula in one line: lower TTL a day ahead → copy and fully test the new site → switch DNS → keep the old host live until propagation completes and checks pass → then cancel.

A note for WordPress sites

If your site runs on WordPress, the same principles apply — files plus database, test before you switch, keep the old host live — but the tooling is a little different and, honestly, a lot easier. WordPress stores its content in a MySQL database and its themes, plugins, and uploads in files, so both still have to move. The good news is that trusted migration plugins can package the whole site into a single portable file and rebuild it on the new host in a few clicks, doing most of the heavy lifting for you.

Because WordPress is so common, we wrote a dedicated walkthrough that covers the plugin method, the manual method, updating the site URL, and the WordPress-specific gotchas. If you are on WordPress, follow that guide instead of hand-copying files: how to migrate a WordPress site.

Common mistakes to avoid

Most migration horror stories come down to a handful of avoidable errors. Here are the ones that catch people out most often — steer around all four and your move will be uneventful, which is exactly what you want.

Canceling the old host too soon is the big one. If you delete or let the old plan lapse before the domain has finished switching and testing is done, part of your audience hits a dead site during propagation. Always keep the old host as your safety net until the very end.

Forgetting the database or email. Copying only files leaves you with a shell of a site — the layout loads but the content is missing, because the words live in the database. Move both, every time. And do not overlook email: if your domain handles email through the old host, plan how those mailboxes and mail routing (the MX records) move too, so messages do not vanish after the switch.

Switching DNS before testing. Pointing your domain at a half-finished or misconfigured new site puts a broken page in front of real visitors. Always prove the new site works with a temporary URL or hosts-file preview first, then switch.

Not lowering the TTL. If you leave a high TTL — say, several hours or a day — the old address stays cached long after you switch, stretching propagation out and making problems slower to resolve. Drop the TTL a day ahead so the cut-over is quick.

Frequently asked questions

How do I move my website to a new host?

Choose your new host and plan, back up all your files and your database, then either accept the host's free migration or copy the files (via FTP or File Manager) and import the database yourself. Rebuild the site on the new server, test it with a temporary URL, lower your DNS TTL, switch your domain, and keep the old host live until everything is verified. Only then cancel the old account.

Will I lose data or have downtime?

Not if you follow the safe process. You avoid data loss by taking a full backup of both your files and database before you start, and by keeping the old host untouched until the move is complete. You avoid downtime by testing before you switch, lowering your TTL in advance, and keeping the old host serving the site during propagation so every visitor always reaches a working page.

How long does migration take?

The hands-on work for a small site is often an hour or two, and a host's free migration service may finish it the same day. The part you cannot rush is DNS propagation after you switch the domain, which usually completes within a few hours but can take up to 24 to 48 hours worldwide. Lowering your TTL a day ahead makes this final step noticeably faster.

Do I need to move my domain too?

Not necessarily. Your domain name and your hosting are separate services. To migrate hosting you only need to point the domain at the new server — by updating nameservers or the A record — which you can do while the domain stays registered where it is. Transferring the domain registration to a new registrar is a separate, optional step. If you do want to move the registration as well, see our guide on transferring web hosting.

Can my new host migrate the site for me?

Very often, yes. Many hosting providers offer free managed migration, where their team moves your files, database, and settings for you at no extra cost. It is worth asking before you do any manual work — their staff handle migrations daily and can usually complete the move quickly and correctly. You still keep the old host live and run your own final checks afterward.

What is DNS propagation, and why does it cause downtime risk?

DNS propagation is the delay while networks around the world update to your domain's new server address. During this window some visitors reach the new host and some still reach the old one. That only becomes downtime if the old host has been shut off — which is exactly why you keep it running until propagation finishes. You can track propagation using the steps in flush DNS and check propagation.

Summary

Migrating a website is really just moving two things — your files and your database — to a new host, then pointing your domain at it. The whole move stays downtime-free when you follow the order: choose a host, back everything up, test the new site on a temporary URL before you switch, lower your DNS TTL a day ahead, switch the domain, keep the old host live through propagation, verify every detail, and only then cancel the old account. Get the sequence right and your visitors never notice the move happened at all.

Your next step: if your site runs on WordPress, follow the platform-specific walkthrough in how to migrate a WordPress site. If you are moving up from a shared plan to more power, read shared hosting to VPS migration next.

If you are migrating because your current host is slow or unreliable, the easiest path is to choose a new provider that includes free managed migration — that way their team handles the file and database move for you, and you skip the manual work entirely. As one example, Hostinger offers managed migration on its plans, so the switch is done for you rather than by you. If valid at checkout, new users may be able to apply a code such as SPECIAL15 or SPECIAL10, subject to Hostinger's terms. Whichever host you pick, the safe process on this page still applies: test before you switch, and keep the old host live until you are sure.

Compare Hostinger plans →

Affiliate disclosure: if you sign up through this link we may earn a commission, at no extra cost to you. How this works.

When migrating is the wrong answer. Migration helps only when hosting is genuinely the constraint — repeated downtime, hard resource limits, slow server response you cannot otherwise fix, or support that cannot help you. If your site is slow because of oversized images, a bloated theme or too many plugins, the same site will be just as slow on any host. Diagnose first. Migration also carries its own risk: DNS propagation, email cutover, and a window in which something breaks. If you do move, compare managed specialists such as WP Engine, Kinsta, SiteGround or Cloudways alongside Hostinger.

References

  • ICANN — Domain names and the DNS: how name resolution and TTL caching work (icann.org).
  • MySQL Documentation — mysqldump and database export/import (dev.mysql.com).
  • phpMyAdmin Documentation — Exporting and importing databases (docs.phpmyadmin.net).
  • Mozilla Developer Network — What is a domain name / how DNS works (developer.mozilla.org).
Bitrich777 Hosting Team
About the author

The editorial team behind the Bitrich777 Hosting Help Center — practical, tested guides on web hosting, WordPress, servers, DNS, SSL, email, security and migration. Every walkthrough is reproduced on a live host before it is published.

Spotted an error? Tell us