Move Your Site Between Servers With Zero Downtime: A Five-Stage Plan

The short answer: zero downtime starts two days before the move, not during it

Migrating your website between two servers with zero downtime is possible, but it does not happen by clicking one button on moving day. It starts 48 hours earlier with a single small step: lowering your DNS TTL. The practical rule is that most downtime during a migration comes from waiting on DNS propagation, which can take up to 48 hours on a default TTL of 86400 seconds. Drop that value to 300 seconds ahead of time and the final switch completes in about five minutes instead of two days.

The full plan has five ordered stages. First, lower the TTL 48 hours before the move. Second, sync your files twice, one large initial copy followed by a fast differential copy. Third, move the database at the very last moment to avoid losing a single row. Fourth, test the entire site on the new server through your hosts file before any visitor sees it. Fifth, switch DNS and then freeze writes on the old server for a short window. Follow this order and your users will notice nothing, and the worst that can happen is a few seconds of stale content before everything settles. This guide walks through every stage with real commands, numbers to measure success against, and a rollback plan ready if things go wrong.

Why do sites go down during a migration? Only three causes

Before fixing the problem, understand it. Downtime during a move is not inevitable. It comes from three recurring mistakes, and closing these three doors gets you to genuine zero downtime.

• Waiting on DNS: you move the files then change the IP in the A record, so half your visitors hit the old server and half the new one for up to 48 hours depending on the TTL value. This is the single biggest cause of visible downtime.
• Last-minute data loss: you copy the database at 10 PM, but the old site keeps accepting orders and signups until midnight, so two hours of requests vanish because they were written to the old server after the copy.
• Environment mismatch: a different PHP version, a missing extension, or a wrong path in a config file, and the site opens on the new server with a 500 error the moment you switch. Pre-testing kills this possibility entirely.

The key insight is that the first and third causes are solved by preparation before moving day, while the second is solved by the order of steps during the move itself. That means 80% of the work happens before the critical moment, and that is exactly why a well-planned switch feels calm.

Stage one: lower DNS TTL 48 hours before the move

TTL, or Time To Live, is the number of seconds every DNS server worldwide keeps a cached copy of your record before asking again. The default at most registrars is 3600 or even 86400 seconds, which means your change may not reach some visitors for a full day.

The practical step

• Open your domain DNS panel at least 48 hours before the move.
• Edit your main A and CNAME records and lower the TTL from 86400 to 300 seconds, which is five minutes.
• Do not change the IP yet, only the TTL value. The goal is for the lower TTL itself to propagate first.
• Wait a full 48 hours so every old copy cached at the high TTL expires.

After that window, any later IP change propagates globally within five minutes instead of a day. This step alone shrinks the danger window from 1440 minutes to 5 minutes, a reduction above 99%. When you move to a server inside Saudi Arabia you gain an extra benefit: response time from Riyadh drops to around 8ms versus 100 to 120ms for foreign servers, so the migration becomes a performance upgrade, not just a change of address.

Stage two: sync files in two passes

The common mistake is copying files once on moving day, which forces you to freeze the site for hours if it is large. The professional solution is a two-pass sync using rsync, which transfers only the differences.

First pass: the large early copy

A day or two before the move, copy every file while the site is still running normally:

• Use a command like rsync -avz with compression to reduce transfer time over the network.
• This pass takes the longest because it moves everything and may run for hours on a site of tens of gigabytes, but it happens while the site is live with zero impact on visitors.

Second pass: the fast differential copy

At the moment of the move, run the same rsync again on the same folder. This time it transfers only the files changed since the first pass, so it finishes in a few minutes instead of hours. In practice the second sync may move less than 2% of the total data volume, because most files have not changed. This is how the real migration window collapses from hours to minutes, and it is the foundation of zero downtime on large sites.

Stage three: move the database without losing a single row

The database is riskier than the files because it changes every second with every request or new signup. If you copy it early like the files, you lose everything written afterward. The order of steps here is critical and leaves no room for improvisation.

• Enable a write-only maintenance mode: at the last moment, block any new writes on the old server while keeping reads working. This freezes the database at a fixed point that can be copied safely.
• Take a clean dump: use mysqldump with the single-transaction option for InnoDB so you get a consistent snapshot without locking tables for long.
• Import and verify: import the dump on the new server, then compare row counts in sensitive tables like orders and users between both servers to confirm an exact match.

This whole stage should finish in under ten minutes for a medium site, and every extra minute here is a minute the site stays write-frozen. That is why we make it the very last step before the switch, with everything else prepared in advance. If your site takes hundreds of requests per minute, every minute of delay can mean dozens of stalled transactions, so speed here is not a luxury.

Stage four: test the new site before anyone sees it

Before routing any visitor to the new server, you must confirm it works 100%. The trick is to fool only your own machine into seeing the new server while the rest of the world stays on the old one, by editing the hosts file on your computer.

Testing steps

• Add a line to your hosts file mapping your domain to the new IP, so only your machine opens the new copy.
• Browse every sensitive page: home, login, cart, checkout, dashboard.
• Check the PHP version, extensions, SSL certificate, upload paths, and permissions.
• Run a real write action like registering a test account to confirm the database receives and writes correctly.

More than half of post-migration problems surface at this stage if you do it seriously: a missing mysqli extension, a PHP version older than the framework requires, or an SSL certificate not yet issued. Fixing it now costs you minutes, fixing it after the switch costs you downtime in front of visitors. Never switch DNS until every test page passes cleanly through the hosts file.

Stage five: the switch and the double freeze

Now the decisive moment. Files are synced, the database is moved and verified, and the new site passed every test. Now you switch and watch.

• Change the A record to point to the new IP. Thanks to the early TTL drop, the change propagates within five minutes.
• Keep the old server running the whole time, do not shut it down. Some visitors will keep reaching it for minutes until their cached copies expire.
• Keep writes frozen on the old server throughout the transition so no new row is written there and lost, since all new writes now go to the new one.

The golden rule is to keep the old server running for a full 24 to 72 hours after the switch. During this window, watch the access logs on the new server until the share of requests reaching it approaches 100%, and only then are you sure every DNS server worldwide has moved. Shutting the old server down too early is the last mistake that ruins a successful migration, because some internet providers ignore TTL and hold the old copy longer than expected.

The rollback plan: how to return safely if things go wrong

Professionalism is not avoiding every error, it is being ready for one. Because you kept the old server running, rollback is simple: point the A record back to the old IP, and thanks to the low TTL everything returns within five minutes. But watch one critical point: any writes made on the new server after the switch will not exist on the old one if you go back. That is why a rollback decision is best taken quickly within the first hour, before much data accumulates on the new server.

For that reason we advise Cloud customers to set a clear timeline: if a fundamental fault appears within the first 60 minutes, roll back immediately and analyze the problem calmly. After the first hour and once data has built up, it is usually better to fix the issue on the new server than to roll back. When you move to Saudi infrastructure inside the Kingdom you get an added advantage for support and recovery: geographic proximity and 8ms response time make diagnosing any issue faster, and automatic provisioning brings up your new environment in seconds so you test and compare without waiting. A successful migration is not a gamble, it is a written five-stage plan with a ready rollback, and if you run it exactly as laid out, your site moves while your visitors notice nothing.