# How to move a website to a new host without downtime

> A step-by-step plan to move a website, databases and email to a new server with no downtime: lower the TTL, copy and test, sync, switch DNS, keep the old host.

Difficulty: Intermediate\
Tested on: Ubuntu 24.04 LTS, Ubuntu 26.04 LTS, Debian 12, Debian 13, Windows 11, macOS Tahoe 26

A website move goes smoothly when the new server is ready and tested before visitors are sent to it. This guide gives you the order of work, from the inventory and DNS preparation to the switch and the clean-up, plus the details that usually cause trouble: databases, SSL and email.

## Before you start

You need:

- SSH or control-panel access to the **old** host and the **new** server, with the software your site needs installed on the new one (web server, PHP or another runtime, database server).
- Access to the place where your **DNS** is managed, which may be your registrar, your old host or a DNS provider.
- A maintenance window for the final sync, ideally at a quiet hour.

Make an **inventory** of everything the old host does for you:

- Website files, including uploads and anything outside the web root that the site reads.
- Databases, with the user names and passwords the site uses.
- Email: mailboxes, forwarders and the MX records that route mail to them.
- DNS records: A and AAAA, CNAME, MX and TXT records such as SPF, DKIM, DMARC and site verifications.
- Scheduled tasks (cron jobs), background workers and the software versions the site needs, such as the PHP version and its extensions.
- SSL certificates, redirects and rewrite rules.

If the domain uses the old host's nameservers, every record must be recreated at the new DNS host before you switch.

## The timeline

| When | What |
|---|---|
| Two days before | Lower the TTL of the records you will change |
| One day before | Prepare the new server: software, files, databases, mailboxes, cron jobs, DNS records |
| Testing | Test the new server through your hosts file |
| Moving day | Freeze changes, run the final sync, switch DNS |
| After the switch | Check SSL, logs and mail |
| About a week later | Retire the old host and raise the TTL again |

## Step 1: Lower the TTL

Resolvers cache each record for as long as its TTL allows. Check the current TTL; it is the number after the name:

```bash
dig +noall +answer example.com A
```

At your DNS host, lower the TTL of the A, AAAA (and, if email moves, MX) records to 300 seconds. Do this at least one old TTL before the move, so resolvers forget the long value in time.

**Verify:** after the old TTL has passed, the `dig` command shows `300` or less.

## Step 2: Copy the files

From the new server, pull the files over SSH with `rsync`. Replace the address and paths with yours:

```bash
rsync -avz -e ssh olduser@198.51.100.20:/var/www/example.com/ /var/www/example.com/
```

The trailing slashes copy the contents of the folder. `rsync` only transfers what changed, so the final sync later is quick. Make sure the files belong to the user your web server or PHP runs as on the new server.

## Step 3: Copy the databases

On the old server, export each database. `--single-transaction` takes a consistent copy of InnoDB tables without locking the site:

**MySQL**

```bash
mysqldump --single-transaction --routines --triggers -u dbuser -p dbname > dbname.sql
```
**MariaDB**

```bash
mariadb-dump --single-transaction --routines --triggers -u dbuser -p dbname > dbname.sql
```

Copy the file to the new server (for example with `scp` or `rsync`), create the database and its user there, then import:

**MySQL**

```bash
mysql -u dbuser -p dbname < dbname.sql
```
**MariaDB**

```bash
mariadb -u dbuser -p dbname < dbname.sql
```

Update the database host, name, user and password in the site's configuration file if any of them changed.

## Step 4: Test without touching DNS

Point only your own computer at the new server by adding a line to your hosts file:

```text
203.0.113.10 example.com www.example.com
```

The file is `/etc/hosts` on Linux and macOS and `C:\Windows\System32\drivers\etc\hosts` on Windows (edit it as administrator). Clear your computer's DNS cache so the change takes effect:

**Windows**

```powershell
ipconfig /flushdns
```
**macOS**

```bash
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
```
**Linux**

```bash
sudo resolvectl flush-caches
```

Now check pages, forms, logins, the checkout and outgoing email. **Verify:** the web server's access log on the new server shows your requests. Remove the hosts line when you are done.

## Step 5: Prepare SSL

Visitors should never see a certificate warning. Free Let's Encrypt certificates are usually validated over HTTP, which needs the domain to point to the new server, so they are issued right after the switch. If you need the certificate before switching, use DNS validation, which works wherever the domain points, or copy the existing certificate and its private key to the new server for the first days. See [install an SSL certificate](/guides/install-ssl-certificate).

## Step 6: Freeze, sync and switch

1. Pause content changes, orders and sign-ups, for example with a maintenance mode.
2. Run the `rsync` command from Step 2 again, then export and import the databases once more.
3. Change the A record (and the AAAA record if you use IPv6) to the new server's address, or change the nameservers if the whole DNS zone moves. See [point a domain to your server](/guides/point-domain-to-server).
4. Lift the freeze on the new server.

**Verify:** `dig +short example.com A` returns the new address, and the old server's access log goes quiet as cached answers expire.

## Step 7: Move email (if it moves)

Create the mailboxes on the new server before you change the MX records, then copy the existing messages with an IMAP migration tool. Keep the old mailboxes for a few days after the switch, because some senders still deliver to the old server until their DNS caches expire. Recreate the SPF, DKIM and DMARC records for the new mail server, or outgoing mail may be rejected. See [email deliverability](/guides/email-deliverability).

## Moving a WordPress site

WordPress stores its address in the database, including inside serialized settings. When the domain stays the same, a straight copy of files and database is enough. If the address changes, replace it with WP-CLI, which understands serialized data. Try a dry run first:

```bash
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid --dry-run
wp search-replace 'https://old.example.com' 'https://example.com' --skip-columns=guid
```

Update the database details in `wp-config.php` and clear every cache layer after the move: plugin caches, the web server cache and any CDN.

## Step 8: Retire the old host

When the old server receives no more traffic or mail, usually after about a week, take a final backup and cancel it. Raise the TTL of your records again, for example to 3600 seconds.

## Troubleshooting

**Some visitors still reach the old server.** Their resolver cached the old record. Wait for the old TTL to pass; keep the old server running until then.

**The site shows a database connection error.** The database name, user, password or host in the configuration file does not match the new server. Test the login with `mysql -u dbuser -p dbname`.

**Pages work, but images or styles are missing.** File permissions or ownership on the new server, or absolute URLs that still point to the old address.

**Mail goes missing after the switch.** Check that the MX records point to the new mail server and that the old mailboxes are still being checked for a few days.

## Next steps

- Understand the records you are changing: [DNS basics for a new domain](/guides/dns-basics-for-a-new-domain).
- Secure the new server: [secure a new Linux server](/guides/secure-a-new-linux-server).
- Moving to HyperDC? [Contact us](/contact-us) and tell us what you run.

## Frequently asked questions

### How long does DNS propagation take?

It depends on the TTL of the record. With a TTL of 300 seconds, most resolvers use the new address within minutes; with a TTL of one day, some keep the old address for up to a day. Nameserver changes can take a day or two because of the TTLs at the registry.

### Do I need to transfer my domain to move my website?

No. The domain can stay with its registrar; you only change its DNS records or nameservers to point to the new server. You can transfer the domain later if you want everything in one place.

### Will moving hosts affect my search rankings?

Not when the URLs, content and redirects stay the same and the site stays online. Check that the new server returns the same pages, keeps HTTPS working and does not block search engines in robots.txt.

### Does HyperDC move websites for customers?

Many VPS and VDS plans list free migration from your current provider among their features, and for web hosting our team helps you move files, databases and email. Tell us what you run and where, and we will reply with the steps.

### Should I move email at the same time as the website?

You do not have to. Email follows the MX records, so you can move the website first and leave mail where it is. If the mailboxes move, create them on the new server first, copy the messages over IMAP and keep the old mailboxes for a few days after changing the MX records.

---

Source: <https://hyperdc.com/guides/getting-started/move-website-without-downtime>\
Updated: 2026-10-09
