Articles · Infrastructure

2026-10-29 12 min EN / FR

Switching hosting providers without downtime

Moving a website or application to another host should be invisible to visitors. When it is not, the cause is almost always the same: the order of the steps was wrong, or email was forgotten. Here is the order that works.

The idea in one sentence

Build the new environment completely, test it while the old one still serves visitors, and only then redirect traffic.

Step 1: Inventory what runs on the old host

Do not assume it is "just a website". List:

  • Website files and the database
  • Scheduled tasks (cron jobs)
  • Email accounts (mailboxes hosted there, or only forwarding)
  • Subdomains
  • SSL certificates
  • Server configuration (PHP version, extensions, redirects, rewrite rules)
  • Anything that connects from outside (APIs, webhooks, IP-restricted services)
  • Files outside the web folder (logs, uploads, generated reports)

Check your DNS records too. They show which services depend on the old host, including ones nobody remembers. A short account ownership audit helps when domain, host and mail sit under different logins.

Step 2: Lower the TTL, early

The TTL (time to live) of a DNS record tells the internet how long to remember the old address. If it is set to 24 hours, some visitors will keep reaching the old server for a day after the switch.

At least two days before the move, lower the TTL of the relevant records to something short, such as 5 minutes. After the move is stable, you can raise it again.

This one step avoids most of the "half the people see the new site, half see the old one" problem.

Step 3: Build the new environment

  • Set up the server or hosting account with versions matching the old one as closely as possible (same major PHP, database and runtime versions). Upgrade later, not during the move
  • Copy the files and the database
  • Recreate cron jobs, redirects and configuration
  • Install SSL certificates, or prepare automatic issuance (note that automatic certificates often need DNS to point to the new server first, so plan for it)
  • Set up backups and monitoring on the new host right away

Step 4: Test on the new host before switching

You can test the new server using the real domain name without changing public DNS, by editing the hosts file on your own computer so that the domain points to the new server's IP address. Only your machine sees the new site.

Test the real flows:

  • Pages, forms, logins
  • Payments and checkout (including a real small transaction if it is a shop)
  • Emails sent by the site (confirmation, password reset)
  • Uploads, downloads, search
  • Background jobs

Remember to remove the hosts entry afterwards, or you will be confused later about what you are seeing.

Planning a hosting move?

We can run the parallel build, DNS cutover and email checks so visitors never notice the switch.

Ask about a move Migration service

Step 5: Handle data that changes

If the site writes data (orders, comments, registrations), data keeps arriving at the old server while you are building the new one. Two approaches:

  • Short freeze: put the old site in maintenance mode or read-only for a few minutes, copy the latest database, then switch DNS. Simple, with a small interruption to writes.
  • Continuous sync: replicate the database during the move, which is more complex but allows a true zero-interruption switch. Worth it for busy shops and applications.

For most small businesses, a short freeze at a quiet hour is fine and much less risky.

Step 6: Do not forget email

This is where moves most often go wrong. If you are also moving DNS (nameservers), follow migrating DNS without breaking email so MX, SPF, DKIM and DMARC survive the cutover.

  • If your mailboxes are hosted at the old provider, you need to migrate them (including stored messages) or move email to a dedicated service before touching DNS
  • Check the MX records, and the SPF, DKIM and DMARC records. If they point to the old server and you do not carry them over, outgoing emails may land in spam or be rejected
  • If the website sends email (order confirmations, notifications), make sure the new server is authorised to send them

A good rule: separate web hosting and email, so a future hosting move does not touch your mailboxes at all.

Step 7: Switch

  1. Do a final copy of the data (or finish the freeze).
  2. Update the DNS records to the new server.
  3. Verify from several networks (office, mobile data, an online DNS checker).
  4. Watch logs on both servers. Traffic should move from old to new within minutes if the TTL was low.
  5. Leave the old server running in the meantime.

Step 8: After the switch

  • Run a smoke test of every critical path
  • Check error logs on the new server
  • Check that scheduled tasks are running
  • Confirm that backups are being made, and test a restore (see backups that actually restore). Document what is backed up, where, and who can restore in your exit plan
  • Raise the TTL back to a normal value
  • Keep the old host for one to two weeks, then cancel once nothing is arriving there
  • Take a final backup of the old server before deleting it

Common pitfalls

  • Forgetting email, covered above, and the number one cause of problems
  • Hard-coded IP addresses in settings or in other systems' allowlists
  • A database with the old domain stored inside it (common in WordPress, see also taking back a WordPress site)
  • Missing PHP extensions or different server limits on the new host
  • Wrong file permissions after the copy
  • SSL certificate errors on launch day
  • Cancelling the old host the same day

A realistic timeline

For a small site: a day of preparation, a couple of hours for the switch. For an application with a database, cron jobs and email: plan a week, including testing and a rollback option.

Always have a way back. If something goes wrong, you should be able to point DNS back to the old server within minutes. That is another reason to keep it running.

Related

Need a cutover plan?

Tell us what is on the old host (web, mail, cron). We will propose an order of operations and a rollback.

Start a conversation Infrastructure