How to Migrate Your Website to a New Host Without Downtime

A lot of guides telling you how to migrate your website are published by hosting companies that would rather sell you a migration service than explain the process. The result is a lot of articles that stop at "upload your files and change your nameservers" and skip the steps that cause most of the downtime and data loss people end up blaming on their new host.

This is the full sequence, in the order it actually has to happen. It applies whether you are moving a WordPress site, a static site or a set of PHP applications, and whether you are moving because your current host is slow or because you no longer want them holding your data.

What to do before you migrate your website

Migrations fail on things people forgot they had, not on the parts they planned. Spend twenty minutes building an inventory first.

Then take a full backup and download it to your own machine. Not a backup that lives in the old hosting account, because that is the thing you are about to stop paying for. Files and database, both, held somewhere that has nothing to do with either host.

How to migrate your website without downtime

Step 1: lower your DNS TTL, and do it first

This is the step that almost every guide puts in the wrong place or leaves out entirely. TTL is how long resolvers around the world are allowed to cache a record. If yours is set to 86400, which is a common default, then after you change that record some visitors will keep hitting the old server for up to a full day.

Lowering the TTL after you switch does nothing, because the old value is already cached everywhere. You have to lower it first, wait out at least one full old TTL, and only then make the change. Set it to 300 seconds, wait, and put it back to something sensible a few days after the move.

One important caveat, because this is where the advice usually goes wrong. Lowering the TTL on your A record only speeds up changes to that record. If you are also changing nameservers at your registrar, the delegation itself is cached according to a TTL set in the parent zone, not in yours, and for many extensions that is measured in days rather than minutes. Nothing you do inside your own zone shortens it.

So the rule is: if you are keeping the same DNS provider and only changing the A or AAAA record, a lowered TTL gives you a genuinely fast switch. If you are changing nameservers too, recreate the complete zone on the new nameservers first and keep the old DNS service running throughout the transition, because both sets will be answering queries for a while and they need to agree.

Step 2: set the site up on the new server

Create the hosting account, add the domain, and upload your files. For a small site this is an FTP or SFTP transfer. For anything large, compress it first and move a single archive, because thousands of small files over FTP is painfully slow and prone to silent failures partway through.

Export the database from the old host and import it on the new one. Then update your application's config file with the new database name, user, and host, since almost nobody's new credentials match their old ones. In WordPress that is wp-config.php. If you are setting the site up fresh rather than copying it across, our WordPress setup guide covers the clean-install route.

Step 3: test on the new server before you switch anything

This is the other step people skip, and it is the difference between a calm migration and a public one. You do not have to point your domain at the new server to see whether the new server works. You can tell your own computer to resolve the domain to the new IP while the rest of the world still gets the old one.

Edit your hosts file and add a line with the new server's IP and your domain:

On Linux and macOS the file is at /etc/hosts. On Windows it is at C:\Windows\System32\drivers\etc\hosts and you need to open your editor as administrator. Save it, flush your DNS cache, and load your site. You are now looking at the new server while every real visitor is still on the old one.

Click through properly. Log into the admin area. Submit a form. Load a page that queries the database. Check a page with images. If something is broken, you have found it with zero public consequence, and you can fix it without a clock running. Remove the hosts entry when you are done.

Step 4: sync the database one last time

Everything up to here assumes your site is a snapshot. For a brochure site it effectively is, and you can skip to the switch. But if your site takes orders, registrations, comments, bookings, forum posts or any other user-generated writes, then the database you copied in step 2 started going stale the moment you copied it. Every order placed since then exists only on the old server, and switching DNS now abandons it.

Two ways to handle it, both done immediately before the cutover:

Whichever you use, sync the database only. Do not overwrite the config file you edited in step 2, or you will put the old database credentials back and break the site you just finished testing. If files have also changed since step 2, such as new uploads, copy those across too, but leave the config alone.

Step 5: make the switch

If your domain uses your old host's nameservers, change the nameservers at your registrar to your new host's. At Packetra those are saana.ns.packetra.com and dufour.ns.packetra.com. Before you do, make sure every record from your inventory has been recreated on the new nameservers, because as delegation caches refresh, more resolvers will begin querying the new zone. This is where people lose their mail: they move nameservers with the MX records only existing on the old side. Keep the old DNS service running for several days afterwards rather than deleting the zone the same day.

If you manage DNS somewhere independent of both hosts, just change the A record to the new IP. This is the cleaner option, it is the one where your lowered TTL actually pays off, and it is a good argument for keeping DNS separate from hosting permanently, since it turns every future move into a one-record change.

If you sit behind a proxy or CDN, the switch happens there rather than at your registrar, and the origin IP is what changes. Worth knowing what that layer can see while you are in there, which we covered in what the edge actually sees.

Email is a separate migration

The single most common migration disaster is treating mail as part of the website move. It is not. Your files can be copied at leisure and verified before anyone notices. Your mail is live, and messages arriving during the switch have to land somewhere.

SSL, redirects and the things that break quietly

Do not assume your SSL certificate moves with the site. It can be transferred if you hold both the certificate and its private key, but on most shared hosting you do not have convenient access to either, and the simpler route is to issue a fresh one on the new server. Most hosts do this automatically through Let's Encrypt once DNS points at them, which means there can be a short window after the switch where the site is reachable but the certificate is not yet valid. Doing the cutover at a low-traffic hour reduces the impact of that window.

Then check the things that fail silently rather than loudly:

• File permissions, which frequently arrive wrong after an archive transfer and break uploads rather than page loads
• Hardcoded absolute paths in config files, which point at the old server's directory structure
• Hardcoded URLs in the database, especially in WordPress, where a search and replace across the database is usually needed
• Your .htaccess or server config, which holds your redirects and is easy to leave behind because it is a hidden file
• Cron jobs, which have to be recreated by hand
• Any API or webhook that has your old server's IP allowlisted

Before you cancel the old account

Do not cancel on the day you switch. Keep the old account running for at least two weeks. It costs one more billing cycle and it buys you a working rollback, an intact copy of everything, and somewhere to check for stray mail.

Before you close it, run through this:

Leaving a host you no longer trust

Everything above assumes you are moving for performance or price. If you are moving because of who your host is, where they are, or what they hold about you, a few things change.

Cancellation is not deletion. Closing an account ends the service. It does not erase what the provider holds, and most retain billing records, support tickets, access logs and any identity documents you supplied at signup for years, often because their own law requires it. Read the retention section of their privacy policy rather than assuming. If you are in a jurisdiction with a right to erasure, request it explicitly and in writing, and understand that data they are legally required to keep is exempt from that request.

The domain is the part that follows you. A domain registered through the host you are leaving is still under their control after the site has moved, and it is the single most valuable thing in the setup. Transfer it out as a distinct task, and take the opportunity to check what the extension itself exposes you to, which we covered in who can actually take your domain away and which registries redact your data.

Rotate every credential. Database passwords, application admin logins, API keys, SSH keys, mail passwords. Your old host had access to all of it. Migrating the same credentials to a new server carries the exposure across with them.

Check what the new jurisdiction actually gives you. Moving servers between countries changes which authorities can compel what, and the honest answer is more nuanced than most marketing pages suggest. Our guide to what offshore hosting really means sets out where the real protections are, with the specifics for each of our locations in the Finnish and Swiss law guides.

Migrating to Packetra

Signup takes an email address. There is no identity check, no document upload and no phone verification, so you can have the destination account open and the site copied across before you commit to anything. Shared and WordPress hosting carry a 30 day money-back guarantee, which means you can run both accounts in parallel through the whole migration and still get your money back if the new server does not suit you.

We run our own authoritative nameservers, and DNS management is included, so your zone lives somewhere you can edit directly rather than through a ticket. If you would rather not do the transfer yourself, open a ticket before you start and our team will tell you what they need. Support is handled in-house by the same people who run the infrastructure, so the person answering can actually look at the server.

View hosting plans

Frequently asked questions

How long does it take to migrate a website?
The copying is usually an hour or two for a typical site. The calendar time is longer because of the TTL wait beforehand and the propagation window afterwards, so plan for two days end to end even though the hands-on work is short. Allow longer if you are changing nameservers rather than a single record.

Will my site go down during the migration?
It should not. If the site is fully working on the new server before you change DNS, visitors move from one working server to another working server. Downtime comes from switching DNS first and fixing problems afterwards.

What happens to orders placed during the switch?
Nothing, unless you plan for them. Anything written to the old database after your initial export lives only on the old server. Either freeze writes briefly or run a final database sync immediately before the cutover.

Do I have to move my domain as well?
No. The domain and the hosting are separate. You can point an existing domain at a new host without transferring the registration. Moving both is worth doing if you are leaving the old provider entirely, but they are two separate processes.

Will migrating hurt my SEO?
A host move with the same URLs and content should not materially affect your rankings. Search engines may briefly adjust their crawl activity while the new server settles in. SEO damage comes from changing URL structure at the same time, so do not combine a host move with a redesign.

Can I test the new server before pointing my domain at it?
Yes, and you should. A hosts file entry on your own machine lets you browse the new server under the real domain name while everyone else still sees the old one. It is the single most useful trick in the whole process.