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.
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.
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.
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.
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.
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.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.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.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."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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
View all guides by the Hosting Team Spotted an error? Tell us