Tous les articles

migration

How to Move Your Website to a New VPS With Zero Downtime

A plain-English migration plan for moving a live website to a new server without visitors seeing a broken page.

  • migration
  • domains
  • hosting
An old VPS and a new VPS stay online while a DNS switch and green migration arrow indicate a zero-downtime website move.

Moving a live website is stressful because one wrong step can turn a normal upgrade into a blank page, lost orders, or angry messages from visitors.

Short version: to migrate website no downtime, you prepare the new server while the old one is still serving visitors, copy the site and data, test the new copy privately, then switch DNS only when both sides are ready. The safest move is not one big jump; it is more like opening a second shop, stocking it fully, checking the lights, and only then changing the sign that tells people where to enter.

What does “zero downtime” really mean?

Zero downtime does not mean nothing changes behind the scenes. It means visitors keep reaching a working website while you move the machinery underneath.

Think of your website like a restaurant. The old kitchen is still serving meals. You build a new kitchen next door, copy the recipes, test the ovens, and make sure the card machine works. Only then do you redirect the front door.

In web terms, the “front door” is DNS, the system that points your domain name to a server. If DNS points to the old server, visitors go there. If it points to the new server, visitors go there. The trick is to avoid changing that pointer before the new place is ready.

What should you prepare before moving the site?

Start with a full backup you know how to restore. A backup that only exists as a mysterious file is like a spare key you have never tried in the lock. Before a migration, you want a way back if the new setup behaves badly. If this part feels fuzzy, read how to back up your server and actually restore it.

Then prepare the new server to match what the site needs: web software, database, file storage, background jobs, email sending, HTTPS certificates, and any scheduled tasks. For a WordPress site, that means both files and the database. For a custom app, it may also mean environment variables, worker processes, uploads, and cache settings.

Here is the practical difference between a rushed move and a calm one:

Part of the moveRisky approachSafer zero-downtime approach
Files and databaseCopy once and hope nothing changedCopy, test, then do a final sync near the switch
Domain changePoint DNS first, fix laterTest the new server before changing DNS
HTTPSNotice certificate problems after launchConfirm the certificate is valid before visitors arrive
RollbackNo clear way backKeep the old server ready until the new one is proven

The goal is not perfection. The goal is to remove surprises before real visitors become your testers.

How do you switch traffic without breaking visitors?

The safest pattern is: build, copy, test, sync, switch, watch.

First, build the new server while the old server keeps running. Then copy the website files and database. Test the new copy without sending public traffic to it. You can often do this with a temporary domain, a preview address, or a local hosts-file override, depending on your setup.

Next comes the final sync. This matters most for sites that change often: shops, booking systems, forums, membership sites, and blogs with comments. If orders or user uploads keep arriving on the old server after your first copy, you need a final pass close to the DNS switch.

After that, you change DNS so the domain points to the new server. If you want the domain side explained in plain English, see how to point a domain at your server.

Keep the old server alive for a while after the switch. Some visitors, networks, and internet providers may still use the old DNS answer for a short time. During that overlap, both places should lead to a working site, or at least the old one should not be destroyed too early.

Is DNS the risky part?

DNS is often where people feel the most nervous, but DNS is usually not the whole problem. DNS is only the signpost. The bigger risk is changing the signpost before the new building is ready.

One important DNS setting is TTL, short for “time to live.” It tells other systems how long they may remember the old address. Lowering TTL before the move can make the later switch spread faster, but it is not magic. Some networks still take time to update.

HTTPS is another common trap. Your site may load on the new server but fail once the real domain arrives because the certificate is missing, expired, or issued for the wrong name. A browser warning about privacy or a failed secure connection feels like downtime to visitors, even if the server is technically online. If that is part of your move, read how to get free HTTPS on your own server.

Also check hard-coded addresses. A site may secretly point images, API calls, redirects, or admin links back to the old server. That is like moving house but leaving half your mailboxes at the old address.

The shortcut

Server Manager helps by keeping the migration visible as a set of understandable pieces: domains, websites, certificates, and the servers they belong to. That matters when the failure modes are easy to mix up, such as DNS pointing to the wrong place, a wrong or expired certificate, or one website change affecting another project on the same server.

The real benefit is that the setup stays legible after the move. Months later, you can still see what points where, which site belongs to which server, and whether the public address matches the place you intended to serve visitors from.

That reduces the “what did I do last time?” problem. Instead of depending on memory during a stressful switch, you keep the shape of the migration understandable while the old server and new server overlap.

FAQ

Can I really move a website with no downtime? Yes, if the new server is fully prepared and tested before DNS changes, and the old server stays online during the transition.

What is the biggest cause of downtime during migration? Changing DNS too early. Visitors get sent to a server that is not ready, missing data, or has broken HTTPS.

Do I need to stop editing my site during the move? For simple static sites, usually not. For shops, forums, and membership sites, you may need a short content freeze or a final data sync.

How long should I keep the old server? Keep it until DNS has settled and you have checked traffic, forms, logins, payments, uploads, and admin access on the new server.

What does a calm migration look like?

A calm migration feels slightly boring. That is the point.

Your old server keeps serving people. Your new server is prepared in private. You test the copy, fix certificate and domain issues before launch, make one careful switch, and watch the site after traffic moves.

When you migrate website no downtime, the win is simple: visitors keep seeing the site they came for, while you get a cleaner new home underneath it.