Server management

Migrating a website to a new server without downtime

Most downtime during a migration comes from doing things in the wrong order. Follow the right sequence and visitors never notice the change.

23 March 202610 min read

Website migrating between two servers across a data bridge

Migrating a site is not technically difficult; keeping the service running while you do it is. Almost all migration downtime comes from performing the steps in the wrong order.

The sequence below lets you migrate without any visitor-facing interruption.

1. Take an inventory

Write down what needs to move before you start. A component you forget surfaces days after the cutover:

Web files and upload directories
Databases and database users
Email accounts and existing mailboxes
Cron jobs
SSL certificates
Every DNS record — not just the A record, but MX, TXT (SPF, DKIM, DMARC) and CNAME records too
PHP version and enabled extensions

2. Lower the DNS TTL

This step belongs at least 24 hours before the migration, and it is the one most often skipped.

TTL (Time To Live) controls how long DNS records stay cached. The default is often 14400 seconds (4 hours), which means some visitors keep reaching the old server for four hours after the cutover.

Drop the TTL to 300 seconds the day before. You can restore the original value once the migration is complete.

3. Prepare the new server

Install the web server, PHP version and database server at the same major versions as the old server. Do not combine a version upgrade with a migration; when something breaks you will not be able to tell whether the cause was the move or the version change.

Migrate first, confirm it works, and plan the upgrade as separate work.

4. Transfer the files

For server-to-server transfers rsync is the most reliable tool; it resumes an interrupted transfer where it left off:

bashrsync -avz --progress -e ssh /var/www/yoursite/ root@NEW-SERVER-IP:/var/www/yoursite/

What the flags do: -a preserves permissions and timestamps, -v prints detail, -z compresses during transfer.

After the transfer, hand ownership to the web user on the new server:

bashchown -R www-data:www-data /var/www/yoursite    # Ubuntu / Debian
# chown -R apache:apache /var/www/yoursite      # AlmaLinux / Rocky

5. Move the database

Dump it on the old server:

bashmysqldump -u USER -p --single-transaction --routines --triggers DATABASE > database.sql
gzip database.sql

The --single-transaction flag avoids locking tables during the dump, so the site keeps serving.

Move the file across and import it:

bashscp database.sql.gz root@NEW-SERVER-IP:/root/
gunzip database.sql.gz
mysql -u USER -p DATABASE < database.sql

Remember to update the database host, username and password in your application's configuration file.

6. Test before touching DNS

This is the most important part of the migration. You can test the site on the new server without changing DNS: add the new server's IP to your own machine's hosts file.

Add this line to C:\Windows\System32\drivers\etc\hosts on Windows, or /etc/hosts on macOS and Linux:

textNEW-SERVER-IP    yourdomain.com www.yourdomain.com

Now only your computer reaches the new server. Check each of these:

Do the home page and inner pages load?
Do forms work and send email?
Can you log in to the admin panel?
Do images and file uploads appear?
Is the HTTPS certificate valid?

Remove the hosts line when you are done.

7. Cut over DNS

Once everything checks out, point the A record at the new server's IP. Because you lowered the TTL, the change propagates within minutes.

If your email is hosted on the same server, update the MX record too. If it sits with a different provider, do not touch the MX record — this is the number one cause of email outages during migrations.

8. Do not decommission the old server immediately

Leave the old server running for at least a week. The reasons:

Visitors with stale DNS caches keep reaching it for a while.
A file or setting you missed may surface.
You keep a working copy to fall back to if something unexpected breaks.

Watch the traffic reaching the old server during that period. When it drops to zero, the migration is complete.

Post-migration checklist

Watch for crawl errors in Google Search Console
Confirm the SSL certificate renews
Check that cron jobs run on the new server
Rebuild your backup configuration on the new server — backup jobs do not migrate with the data
Measure site speed and compare it with the pre-migration baseline

If you would rather not run the migration yourself, we handle setup and migration remotely; get in touch with our team.