Website Migration Without Downtime: Step-by-Step Guide with Backup, DNS & Testing

Website migration: why everyone's afraid and why they shouldn't be

A client was moving an online store from shared hosting to a VPS. Copied everything, switched DNS — and for the next 6 hours, half the visitors saw the old server while the other half saw the new one. Orders placed during this period simply vanished — they ended up in the old database that nobody was maintaining anymore.

The reason was trivial: the TTL on DNS records was set to default — 86400 seconds (24 hours). If they had lowered the TTL to 300 seconds (5 minutes) two days before the migration, the switch would have taken minutes, not half a day.

Website migration is not a complex operation. It's a sequence of simple steps where each depends on the previous one. Problems arise when steps are skipped, rushed, or when you start with DNS instead of a backup.

There are many reasons to move: the old hosting is slow, can't handle traffic, doesn't provide root access, or simply costs too much for what it offers. Whatever the reason — the migration process itself is the same for everyone. In this guide — the exact sequence of actions that allows you to transfer a site with zero downtime. No magic, no expensive tools — just the right order and attention to detail.

Step 1: Preparing for migration

90% of migration problems are the result of poor preparation. Transferring files takes minutes, but recovering from lost data takes hours or days. We've seen cases where clients lost weeks of work simply because they didn't make a backup before starting — they assumed "nothing will go wrong." Something always goes wrong. The only question is whether you have a plan B.

Full backup

First things first — make a complete backup of your current site. This is your insurance policy. If something goes wrong at any stage — you roll back in minutes. Without a backup, every mistake becomes irreversible: wrong config, overwritten table, replaced file — and there's nowhere to restore from.

What to include in the backup:

• Website files — the entire public_html or www directory, including .htaccess and configuration files
• Databases — full dump via mysqldump or phpMyAdmin
• Email accounts — if email is on the same hosting
• SSL certificates — if you have a paid certificate, save the key and certificate
• Cron jobs — copy the task schedule, it's easy to forget

# File backup via tar
tar -czf backup_site_$(date +%Y%m%d).tar.gz /var/www/html/
# Database backup
mysqldump -u root -p --single-transaction --routines mydb > backup_db_$(date +%Y%m%d).sql

Lowering DNS TTL

This is the most important preparation step, and it needs to be done 24–48 hours BEFORE the migration. Go to the DNS panel of your domain registrar and change the TTL for the A record from its current value (usually 3600 or 86400) to 300 seconds (5 minutes).

Why? TTL determines how long DNS resolvers around the world cache your IP address. If TTL = 86400 (24 hours), after changing the IP address, some users will still see the old server for up to a day — because their DNS provider cached the old address and won't check for a new one until the TTL expires. If TTL = 300 (5 minutes) — DNS providers check records every 5 minutes, and the switch happens almost instantly.

Example: your current TTL = 14400 (4 hours). You change it to 300. But you need to wait those 4 hours for the old TTL value to "flush" from all caches. Only after that does the new TTL = 300 become active. That's why this step needs to be done 24–48 hours before migration — to be 100% certain.

Inventory

Before the transfer, compile a list of everything that needs to work after migration. This sounds obvious, but it's the "obvious" things that get forgotten. Do this in a text file or spreadsheet — don't rely on memory:

• PHP version and extensions (check via php -v and php -m on the old server)
• MySQL/MariaDB version
• External services: payment gateways, API integrations, CDN
• Redirects (.htaccess or Nginx config)
• Mail records (MX, SPF, DKIM) — if email goes through the hosting

Step 2: Transferring files and database

Backup done, TTL lowered, inventory ready — time to transfer data. The old hosting continues running as usual, serving live visitors. On the new server, we set up a copy, test it, and only when everything works perfectly — switch DNS. The golden rule: don't touch DNS until you've verified everything on the new server.

Files

For small sites (up to a few gigabytes), SCP or SFTP via a graphical client like FileZilla will do. For large projects — rsync, which shows progress, copies only changed files, and resumes after connection drops (instead of starting from scratch). Rsync is the most reliable tool for transferring files between servers, used even in enterprise migrations:

# Direct transfer between servers (if you have SSH access to both)
rsync -avz --progress /var/www/html/ user@new-server:/var/www/html/
# Or via local machine (two steps)
scp -r user@old-server:/var/www/html/ ./site-backup/
scp -r ./site-backup/ user@new-server:/var/www/html/

Pay attention to file permissions after copying — they may not be preserved. After the transfer, run on the new server:

chown -R www-data:www-data /var/www/html/
find /var/www/html/ -type d -exec chmod 755 {} \;
find /var/www/html/ -type f -exec chmod 644 {} \;

This sets standard permissions: directories 755, files 644, owner www-data (for Nginx and Apache).

Database

Database transfer is the most critical stage. A mistake here means either data loss or a broken site. The standard approach — dump on the old server, transfer the file, import on the new one:

# On the old server — create a dump
mysqldump -u root -p --single-transaction mydb > mydb.sql
# Transfer the file to the new server
scp mydb.sql user@new-server:/tmp/
# On the new server — import
mysql -u root -p mydb < /tmp/mydb.sql

The --single-transaction flag is critically important for InnoDB tables — it allows a consistent dump without locking the database. Without it, new data could be written during the dump, resulting in an inconsistent export.

For large databases (10+ GB), use compression during transfer — it reduces time by 3–5x and saves bandwidth:

mysqldump -u root -p --single-transaction mydb | gzip | ssh user@new-server "gunzip | mysql -u root -p mydb"

Configuration on the new server

After copying files, check and update configurations. This is one of the most common sources of errors — files are on the new server, but the application is still trying to connect to the database on the old one:

• wp-config.php (WordPress) — new database connection details: host, database name, user, password
• .env (Laravel, Node.js, etc.) — database and external service connection strings
• File permissions — verify the web server has access to files: chown -R www-data:www-data /var/www/html/
• PHP version — the new server may have a different version, check compatibility

WordPress specifics

WordPress is the most popular CMS, and there are several specific nuances during migration. The database stores absolute site URLs (in wp_options, wp_posts, wp_postmeta tables). If the domain isn't changing — no issues. But if you transferred to a temporary domain for testing — you need to do a search and replace via WP-CLI:

wp search-replace 'temp-domain.com' 'your-domain.com' --all-tables

Also verify that all PHP extensions required by your plugins are installed on the new server. Most commonly: php-mysql, php-curl, php-gd, php-mbstring, php-xml. A missing extension can break a specific plugin without visible errors — the site works, but some function silently stops.

After migration, go to the WordPress admin panel → Settings → Permalinks → click "Save Changes" (without making changes). This regenerates URL rewrite rules and often fixes 404 errors on internal pages.

Migration from cPanel or DirectAdmin

If your current hosting uses cPanel — you can simplify the transfer process through the built-in backup. Go to cPanel → Backup → Generate Full Backup. This creates an archive with all files, databases, email accounts, cron jobs, and configs in a single file.

If the new server also has cPanel — this archive can be imported as a whole. If the new server has no panel (a clean VPS with Nginx) — you'll need to unpack the archive manually and transfer files and database separately, as described above.

DirectAdmin has a similar feature: Panel → Admin Backup / Transfer. Same process: full backup on old → transfer → import on new. The key thing — make sure panel versions are compatible, otherwise the import may fail.

For servers without control panels (bare Linux with Nginx or Apache) — use rsync + mysqldump as described above. This is the most universal method that works between any servers regardless of panels and configurations.

If there's no SSH access to the old hosting

On some shared hosts, SSH is disabled. In that case, alternative methods for transferring files and database are available:

Files — download via the file manager in the hosting panel (cPanel File Manager) or via an FTP/SFTP client (FileZilla, WinSCP). For large sites this may take significantly longer than rsync, but it always works.

Database — export via phpMyAdmin (usually available in the hosting panel). Select your database → "Export" tab → SQL format → click "Go." The file will download to your computer. Then import it on the new server via phpMyAdmin or the command line.

This method is slower than rsync + mysqldump, but allows you to migrate a site even from the most restricted shared hosting.

Step 3: Testing on the new server

Files and database transferred, configs updated — but DNS still points to the old server. This is the ideal moment for testing: real users continue working with the old server as usual, and you have all the time you need to verify everything on the new one. Don't rush — better to spend an extra hour testing than fixing problems later under the pressure of live traffic.

Testing via hosts file

To see the site on the new server before changing DNS — add an entry to the hosts file on your computer:

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS/Linux: /etc/hosts
198.51.100.25  example.com
198.51.100.25  www.example.com

Replace 198.51.100.25 with the IP address of the new server, and example.com with your domain. Now your browser will open the site from the new server, while all other visitors see the old one. This allows you to fully test the site under real conditions — with the correct domain, SSL, and all configs — without risk to live users.

What to check

Go through the complete checklist — every skipped item is a potential problem after switching DNS. Check not just "does the page open," but also functionality that depends on the database, file system, and external services:

• Homepage and all main sections load without errors
• Forms work — registration, contact form, search
• Admin panel is accessible and functional
• Images display (common issue — hardcoded absolute paths)
• HTTPS works (if you've already configured SSL on the new server)
• For eCommerce: cart, checkout, payment gateway
• Email sends from the new server (test via contact form)

Step 4: DNS switch and final synchronization

Testing passed successfully — time to switch traffic. But first, go through the final checklist. Every skipped item is a risk of problems after the switch:

There's a nuance that often gets overlooked: between the moment you made the database dump and the moment you switch DNS, time has passed. If the site is active — new orders, comments, and registrations may have appeared on the old server during that time. These need to be synchronized.

Final synchronization

Immediately before switching DNS, do a final rsync and a fresh database dump. Rsync with the --delete flag will remove files on the new server that no longer exist on the old one — guaranteeing complete identity:

# Upload only changed files
rsync -avz --delete --progress user@old-server:/var/www/html/ /var/www/html/
# Fresh database dump
mysqldump -u root -p --single-transaction mydb > final_dump.sql
mysql -u root -p mydb < final_dump.sql

For sites with high activity (eCommerce, forums, SaaS), this step is critically important. Between the first database transfer and the DNS switch, hours or even days may have passed — during that time, new orders, comments, and registrations appeared on the old server. If you simply switch DNS without final synchronization — this data will be lost.

For high-traffic projects, we recommend this approach: put the site on the old server into maintenance mode for 10–15 minutes, make the final dump, import to the new server, verify — and then switch DNS. 15 minutes of planned downtime is significantly better than lost orders or duplicate data.

Changing DNS

Update the A record of your domain to the new server's IP address in your domain registrar's panel. If you lowered the TTL to 300 seconds in advance — most users will see the new server within 5–10 minutes. The best time for the switch is nighttime or early morning on a workday, when traffic is minimal.

Monitoring propagation

DNS propagation is not an instant process. Different DNS resolvers around the world update at different speeds. Even with a 300-second TTL, some providers may cache records longer. You can check propagation status across regions and providers on free services like dnschecker.org or whatsmydns.net — they show which IP address DNS servers in different countries are seeing.

During propagation, some traffic may go to the old server, some to the new one. That's why it's important to keep both servers active and synchronized until the process is fully complete. Don't make content changes to the site until propagation finishes — otherwise changes will only be visible to some visitors.

Step 5: Post-migration verification

DNS is switched, traffic is going to the new server — but the work isn't done yet. The first 24–48 hours are a critical period. Monitor error logs, check loading speed (the new server should be at least as fast as the old one), and respond to any user complaints.

SEO verification

Migration can break SEO if URLs changed or pages disappeared. Search engines are very sensitive to such changes — even temporary page unavailability can lead to loss of rankings that took months to build. Make sure to:

• Check Google Search Console for indexing errors during the week following migration
• Confirm that robots.txt and sitemap.xml are accessible and correct on the new server
• If URLs changed — set up 301 redirects from old addresses to new ones. In Nginx:

  # In Nginx configuration
  rewrite ^/old-page$ /new-page permanent;

• Verify that canonical tags point to the correct URLs
• Submit an updated sitemap through Google Search Console — this speeds up re-indexing

Loading speed is another SEO factor worth checking. If the new server is slower than the old one (for example, due to a different data center location or weaker configuration), it can negatively impact rankings. Check via Google PageSpeed Insights or GTmetrix and compare results with what you had on the old hosting.

Functionality check

During the first week after migration, regularly check error logs on the new server. Issues that didn't surface during testing can appear under real load — more traffic, more simultaneous database connections, more filesystem requests. Monitor:

# Nginx — errors
tail -f /var/log/nginx/error.log
# Apache — errors
tail -f /var/log/apache2/error.log
# PHP — errors (if logging is configured)
tail -f /var/log/php-fpm/error.log

If you see 502 Bad Gateway or 504 Gateway Timeout errors — this usually means PHP-FPM or the backend can't keep up with requests. You may need to increase the number of PHP-FPM workers or raise memory limits.

SSL certificate

If you use Let's Encrypt (the most common option for most sites) — you need to generate a new certificate on the new server. The old certificate is tied to the old server and won't transfer automatically:

sudo certbot --nginx -d example.com -d www.example.com

Certbot will automatically configure Nginx and renew the certificate every 90 days. If you have a paid certificate (e.g., EV or Wildcard) — transfer the private key and certificate file to the new server and specify the paths in your Nginx or Apache configuration.

Email

If email was on the old hosting (a very common configuration for small sites) — make sure MX records point to the correct mail server. This is the most common cause of "missing" emails after migration: DNS already points to the new server, but email isn't configured there — messages simply bounce.

If email is on an external service (Google Workspace, Zoho Mail, Microsoft 365) — MX records don't change and everything will continue working as before. But check SPF and DKIM records — they may contain the old server's IP address, and emails from the new server will end up in spam.

When can you delete the old hosting

No earlier than 72 hours after switching DNS — this is the maximum propagation time for most DNS providers. Even better — wait a week, make sure everything is running stably, and only then cancel. The $10–20 saved per month on old hosting isn't worth the risk of losing data. Some providers delete all files immediately upon cancellation — without warning and without the possibility of recovery.

Migration types: comparing approaches

Migration complexity depends on the site type, database size, and number of integrations. A simple landing page transfers in 15 minutes, while a high-load eCommerce with custom integrations can take an entire workday.

General rule: the more dynamic content and external integrations — the more attention testing requires. A static site or landing page — files copied and everything works. An online store with payment gateways, email campaigns, CRM integrations — each of these systems needs to be verified separately after the transfer.

7 mistakes that make migration painful

We've collected these mistakes from real experience — most of them look obvious on paper, but are regularly repeated even by experienced administrators. Usually due to rushing or the confidence that "I remember everything anyway."

If you're not confident in your abilities or the site is business-critical (eCommerce, SaaS) — trust the migration to professionals. The cost of a mistake when migrating an online store with even $1,000/day in revenue can exceed any migration service fee. Hostiserver performs free migration for all new clients — and that's one of the strongest arguments for not doing everything yourself.

Frequently Asked Questions