How to Move a Large Site Without Taking It Offline for Long

You can migrate a large website without downtime by running the old and new copies side by side, keeping the database in sync with replication, and switching traffic at the DNS or proxy layer once the new copy is verified. The only visible interruption is the brief window between freezing writes on the old host and pointing clients at the new one, and with the right setup that window is measured in seconds.

This is not a copy-paste job for a site with a large database. It is a sequence of stages, each of which you can test and roll back. The core idea is that you never move a live site. You build a second live site, then move the traffic.

Stage one: get the database replicating before you touch the files

Files are easy. Databases are where large sites break, because a file copy can be resumed and a database copy cannot. Start by setting up the new host as a replica of the old one. On MySQL or MariaDB that is a binary log replica; on PostgreSQL it is streaming replication. Either way, the new host applies the same writes as the old one and stays close to current.

On the source, confirm binary logging is on and note the current position:

SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000042 | 81543921 |              |                  |
+------------------+----------+--------------+------------------+

On the target, point the replica at the source using that file and position. The exact syntax differs between MySQL versions and between MySQL and MariaDB, so check the documentation for your version rather than copying a snippet from a blog. What matters is the shape: you give the replica a host, a replication user, a log file name and a log position, and it starts applying events.

Watch the lag. A replica that is seconds behind is fine for this purpose. A replica that is minutes behind means the network between the two hosts is too slow, or the source is writing faster than a single replica can apply, and you should fix that before going further.

Stage two: copy the file tree while it is still being served

The file tree can be copied while the site is live because most of it does not change. Uploads and user generated content do change, so you copy in two passes: a bulk pass for everything, then a delta pass for whatever moved since. rsync does both, and the second pass is cheap because it only transfers differences.

rsync -aHAX --delete --info=progress2 \
  --exclude 'cache/' --exclude 'tmp/' \
  /var/www/site/ deploy@newhost:/var/www/site/

The -aHAX flags preserve permissions, hard links, ACLs and extended attributes, which matter if the site relies on either. Run the bulk pass first, then run the same command again shortly before cutover. The second run takes a fraction of the time because only changed blocks move.

Exclude anything the application can regenerate. Cache directories, compiled templates and log files are all noise. Copying them wastes time and can carry stale state to the new host, which is a confusing way to spend an afternoon.

Stage three: make the application read the same data on both hosts

A replica is read only by default, and that is what you want during the copy. But the new host also needs to serve the site, and the site writes. The usual answer is to let the new host write to its local database and have that database replicate back to the old one, which is a ring and is fragile. The cleaner answer is to accept that until cutover, only the old host takes writes, and the new host runs in read only mode behind a maintenance flag or a proxy rule that you control.

That means you test the new host with real traffic before you commit. Point a staging hostname at it, or use a header to route selected requests:

curl -H 'X-Migrate-Test: 1' https://example.com/ -I
HTTP/2 200
x-served-by: newhost
x-db-lag-seconds: 0

If your front end is behind a reverse proxy, you can route on that header without touching DNS at all. Requests carrying the header go to the new host; everything else goes to the old one. This lets you exercise the new host with real users, real data and real load while the old host keeps serving everyone else.

Stage four: cut over with a short write freeze

When you are satisfied, pick a quiet moment and do the switch. The sequence is short and every step is reversible until the last one.

Stop writes on the old host. This is a maintenance mode, not a shutdown. The site returns a 503 with a Retry-After header, which tells clients and crawlers to come back shortly rather than treating the site as gone. Then wait for the replica to catch up to the final position, confirm the lag is zero, and promote the new host to primary.

Now change the routing. If you are using a proxy, this is a config reload and takes effect immediately. If you are using DNS, lower the TTL on the relevant records well in advance, then change the A or AAAA record to the new address. DNS propagation is not instant for every resolver, so the old host should keep serving read only responses for a while after the switch, and the new host should be the authority for writes from that point.

Then lift maintenance mode on the new host. Total visible interruption is the time between stopping writes and the new host accepting them, which is the replica catch up plus the routing change. On a well prepared migration that is seconds.

What to do next

Before you schedule anything, build the replica and let it run for a full day under normal traffic. Watch the lag, watch the disk, and watch whether the new host can actually handle the read load. Then rehearse the cutover on a staging pair with a small copy of the database, so the first time you run the freeze is not the first time you have run it at all. The migration is not the risky part. Running it untested is.