How to move a website to a new host without downtime

Step 1: Take an inventory of the old host

Most migration problems are things nobody knew the old host was doing. Before you copy anything, write down everything the site depends on:

• Files: the web root, uploads, and anything outside it the site reads (config files, private downloads).
• Database: name, size, engine and version (MySQL or MariaDB, and which release).
• Scheduled jobs: cron entries in the control panel. WordPress's own WP-Cron runs on page visits, but some sites replace it with a real cron job that must be recreated.
• Email: is email hosted on the old host (mailboxes in cPanel, for example) or elsewhere, like Google Workspace or Zoho? Mailboxes on the old host need their own move.
• DNS records: every record, not just the website. Note MX records and TXT records for SPF, DKIM and DMARC, plus any verification records for Google, Microsoft or other services.
• SSL: which hostnames have certificates (example.com, www.example.com, subdomains).
• Server settings: PHP or Node.js version, redirects and rewrite rules (for example in .htaccess), upload size limits.

Find out where your DNS is managed, too. It might be at the registrar, at the old host, or at Cloudflare. That decides where you will make the switch later.

Step 2: Lower your DNS TTL 24–48 hours before

TTL (time to live) tells resolvers how long they may cache a DNS answer. If your A record has a TTL of a day, some visitors could keep reaching the old server for a day after you switch. Lower the TTL on the records you will change (usually the A, AAAA or CNAME records for the root domain and www) to 300 seconds.

Do this at least one full old-TTL period before the move, which is why 24–48 hours ahead is the usual advice: resolvers that cached the old, long TTL need to expire it first. Check what is currently being served:

dig +noall +answer example.com A
dig +noall +answer www.example.com

The number after the hostname is the remaining TTL in seconds. If the site is proxied through Cloudflare (orange cloud), visitors see Cloudflare's addresses and the origin change takes effect at Cloudflare's edge, so TTL matters much less. Our guide on using Cloudflare with your server explains proxied records.

Step 3: Copy the files and database

If both hosts give you SSH access, rsync is the best tool, because running it a second time only copies what changed. Without SSH, download and upload over SFTP, or use the host's backup and restore tools.

rsync -avz [email protected]:/home/user/public_html/ /var/www/example.com/

Note the trailing slash on the source: it copies the contents of public_html, not the folder itself. Then export the database on the old host:

# any MySQL/MariaDB site
mysqldump --single-transaction --default-character-set=utf8mb4 -u dbuser -p dbname > site.sql

# or, for WordPress with WP-CLI
wp db export site.sql

Import it on the new host with mysql -u newuser -p newdb < site.sql or wp db import site.sql, then update the database name, user and password in the site's config (wp-config.php for WordPress, environment variables for most other apps). If you are moving between MySQL 8 and MariaDB, an import can fail on a collation the other side doesn't support; read the error and compare versions before forcing anything.

Change URLs only if the domain changes

If the site keeps the same domain, skip this. If the domain is changing, don't run a text find-and-replace on the SQL file: WordPress stores some settings as serialized PHP data, and changing string lengths by hand breaks them. WP-CLI handles this correctly. Always do a dry run first:

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

# if the counts look right, run it for real
wp search-replace 'https://old.example.com' 'https://www.example.com' --skip-columns=guid

Step 4: Test the new server before you touch DNS

You can make your own computer visit the new server under the real domain while everyone else still sees the old one. Add a line to your hosts file with the new server's IP address:

# macOS / Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts (edit as Administrator)
203.0.113.10  example.com  www.example.com

Clear your browser cache (or use a private window) and browse the site. On Windows, ipconfig /flushdns clears the system's DNS cache. If the browser still seems to reach the old server, its secure DNS setting may be bypassing the hosts file; turn it off while testing. To check a single URL from a terminal without editing anything:

curl -I --resolve example.com:443:203.0.113.10 https://example.com/

Test the things that break quietly: logging in, contact forms and the emails they send, search, checkout, image uploads, pretty permalinks, and any scheduled jobs. The new server may not have a valid certificate for the domain yet, because a standard Let's Encrypt HTTP check can only pass once DNS points there. A certificate warning during this test is expected; a broken page is not. Remove the hosts entry when you are done.

Step 5: Freeze, final sync, switch DNS

A static site can skip the freeze: copy, test, switch. A dynamic site keeps changing while you work, with new orders, comments, form entries and posts. To avoid losing them:

1. Announce a short content freeze: no publishing, and for shops, a quiet time or a brief pause on orders.
2. Export the database again and import it on the new host.
3. Re-run the same rsync command to pick up new uploads. It only copies the differences.
4. Change the A/AAAA (or CNAME) records for the website to the new server. Change nothing else.

Step 6: Verify, wait, then cancel the old host

• Run dig again, and load the site from a phone on mobile data, which uses a different resolver from your office network.
• Issue or confirm the SSL certificate on the new server, and test HTTPS on every hostname.
• Send a test email to and from your domain.
• Watch the old host's access logs. When real visits stop arriving there, traffic has moved. Check it for any orders or form entries that landed during the switch.
• Keep the old host running for a few days. Before cancelling, download a final full backup of files, database and any mailboxes.
• Raise the DNS TTL back to a normal value once everything is stable.

The migration checklist

1. List files, database, cron jobs, email setup, every DNS record and SSL hostnames.
2. Lower TTL on the website's DNS records to 300 seconds, 24–48 hours ahead.
3. Copy files with rsync or SFTP; export and import the database.
4. Update database credentials in the site config.
5. Run wp search-replace with --dry-run only if the domain changes.
6. Test the new server with a hosts-file override or curl --resolve.
7. Freeze content, do a final database export and file sync.
8. Change only the website's A/AAAA or CNAME records.
9. Confirm MX, SPF, DKIM and DMARC records are untouched, and email still flows.
10. Issue SSL, test HTTPS, check forms and checkout.
11. Watch the old host's logs; keep it for a few days; take a final backup; then cancel.

If speed was the reason you moved, measure before and after. Our WordPress speed guide covers what to check once the site is on the new server.

Where NevaraCloud fits

On our Business and Pro plans, migration from your old host is free. Otherwise it is a one-time LKR 2,000 add-on, listed on the pricing page: a zero-downtime move from hosts such as GoDaddy, Hostinger or Namecheap. If your email lives on the old host, our business email setup (free on Pro, or a LKR 3,000 add-on) sets you up on Zoho or Google Workspace.

Moving a WordPress site? Our managed WordPress hosting includes daily backups from the Business plan up, so you have a restore point from the first day.