How to Move a Website to a New Host Without Downtime

Most migrations go wrong at one of two points: the site is copied while it is still changing, or DNS is switched before anyone has checked the copy. This sequence avoids both. It works for any PHP site — WordPress, Laravel, a plain HTML site — and takes an hour for a typical site, most of it waiting.

1. Lower the DNS TTL a day ahead

The TTL tells resolvers how long to remember your old IP. If it is 24 hours, some visitors keep hitting the old server for a day after you switch. Find the current value:

dig example.com A +noall +answer
# example.com.  86400  IN  A  203.0.113.10

That 86400 is the TTL in seconds. Set it to 300 at your DNS provider now, and wait at least the old TTL before doing the switch. This step is why the migration starts a day before it happens.

2. Copy the files

From the new server, pull the files over SSH. rsync only transfers what changed, so you can run it again later to catch anything modified in between:

rsync -avz --progress \
  --exclude='wp-content/cache/' \
  --exclude='*.log' \
  user@old-server:/var/www/example.com/ \
  /var/www/vhosts/example.com/httpdocs/

No SSH on the old host? Download a backup from its control panel and unpack it:

cd /var/www/vhosts/example.com/httpdocs/
tar -xzf ~/backup-example.com.tar.gz --strip-components=1

Fix ownership afterwards so PHP can write to uploads:

chown -R example_user:psacln /var/www/vhosts/example.com/httpdocs/

3. Copy the database

Dump on the old server, import on the new one. --single-transaction takes a consistent snapshot without locking tables, so the live site keeps working during the dump:

# on the old server
mysqldump --single-transaction --quick --routines \
  -u dbuser -p example_db | gzip > example_db.sql.gz

# on the new server
gunzip < example_db.sql.gz | mysql -u newuser -p new_example_db

Then update the site's config with the new credentials — for WordPress that is wp-config.php:

define('DB_NAME', 'new_example_db');
define('DB_USER', 'newuser');
define('DB_PASSWORD', 'the-new-password');
define('DB_HOST', 'localhost');

4. Test the copy before touching DNS

This is the step people skip. Tell your own computer that example.com lives at the new IP, without changing DNS for anyone else. Edit the hosts file:

# macOS / Linux
sudo nano /etc/hosts

# Windows (as Administrator)
notepad C:\Windows\System32\drivers\etc\hosts

Add a line with the new server's IP:

203.0.113.55  example.com www.example.com

Now open the site in a browser. You are looking at the new server; everyone else still sees the old one. Click through the pages, log in to the admin, upload a file, place a test order. If SSL complains, that is expected — the certificate is issued in step 5.

Remove the hosts line when you are done testing.

5. Issue the certificate on the new server

Let's Encrypt needs DNS to point at the new server to validate over HTTP — which it does not yet. Two ways round it:

• DNS validation (wildcard flow in Plesk) works before the switch.
• Or issue it immediately after the switch; with a 300-second TTL, that is a two-minute window of browser warnings.

We use the first. See Install a free SSL certificate in Plesk.

6. Freeze, re-sync, switch

Right before the switch, put the old site into maintenance mode or just avoid publishing for ten minutes. Run the file and database copy again so nothing written in the meantime is lost:

rsync -avz user@old-server:/var/www/example.com/ /var/www/vhosts/example.com/httpdocs/

Then change the A record (and www) to the new IP. With the TTL at 300, the world follows within five minutes. Watch it happen:

watch -n 10 'dig +short example.com A @1.1.1.1'

7. Move email and the small things

Email is what people forget. If mailboxes live on the old host, create them on the new server first, then move the messages with imapsync:

imapsync --host1 old.example.com --user1 you@example.com --password1 'old-pass' \
         --host2 mail.example.com --user2 you@example.com --password2 'new-pass'

Also check: cron jobs, .htaccess redirects, any API keys tied to the old IP, and the SPF record — it must list the new mail server or your mail lands in spam.

Keep the old server for a week

Do not cancel the old hosting the same day. Leave it running for a week so a forgotten cron or a missed mailbox can still be recovered.

Or skip all of this: every VPSPioneer plan includes free migration. Send us the old login and we run exactly this sequence for you.

#migration#dns#rsync#mysql