How to Migrate Your Website to a Dedicated Server Without Downtime

The good news is that with the right approach, you can migrate your entire website—files, databases, emails, and all—to a new dedicated server without your visitors experiencing a single second of downtime. This tutorial walks you through every step of that process.

Note: This guide assumes you are moving from a shared hosting or VPS environment to a dedicated server with a fresh Linux OS (Ubuntu 22.04 / CentOS 8). The same principles apply to server-to-server migrations.

What You'll Learn

Why Migrate to a Dedicated Server?

Before diving into the technical steps, it helps to understand the full value of what you're gaining:

• Dedicated CPU & RAM – No noisy neighbors eating your resources

• Full root access – Install any software, configure any setting

• Improved page speed – Critical for SEO and conversion rates

• Enhanced security – Your own isolated environment, firewalled as you choose

• Scalability – Add storage, RAM, or bandwidth without switching providers

• Compliance readiness – Easier to meet GDPR, PCI-DSS, or HIPAA requirements

Migration Overview: The Zero-Downtime Strategy

Standard migrations cause downtime because admins switch the DNS before the new server is fully configured and tested. The strategy in this guide avoids this by following a proven sequence:

• Set up the new dedicated server (software, configs)

• Copy all website files to the new server

• Export and import the database

• Configure and test the site on the new server using a hosts file trick

• Reduce DNS TTL to 300 seconds (preparation for switch)

• Point DNS to the new server

• Verify everything is live, then decommission the old server

The key insight is simple: the new server runs in parallel with the old one. Visitors continue hitting the old server while you configure, migrate, and test the new one. Only after you've confirmed everything is working do you redirect DNS traffic. Because DNS propagation with a low TTL takes just minutes, your downtime window is effectively zero.

Step 1 – Set Up Your New Dedicated Server

1.1 Connect via SSH

Once your server is provisioned, you'll receive your IP address, root username, and SSH credentials. Connect using your terminal:

ssh root@YOUR_SERVER_IP

# If using an SSH key:
ssh -i /path/to/your/key.pem root@YOUR_SERVER_IP
                            

1.2 Update the System

Always start with a clean, updated system. Run these commands immediately after first login:

# For Ubuntu/Debian:
apt update && apt upgrade -y

# For CentOS/AlmaLinux:
dnf update -y
                            

1.3 Install a Web Server

Install the same web server software your old server uses. Most websites use either Apache or Nginx:

# Install Apache:
apt install apache2 -y

# OR install Nginx:
apt install nginx -y

# Start and enable on boot:
systemctl enable --now apache2    # or nginx
                            

1.4 Install PHP and MySQL

If your site uses PHP and a MySQL/MariaDB database, install them now. Match the version to what your old server runs:

# Install PHP (adjust version number to match your old server):
apt install php8.1 php8.1-mysql php8.1-curl php8.1-gd php8.1-mbstring -y

# Install MySQL:
apt install mysql-server -y

# Secure your MySQL installation:
mysql_secure_installation
                            

Pro Tip: Check your current PHP version on the old server with php -v and MySQL version with mysql --version. Match these versions on the new server to avoid compatibility issues.

Step 2 – Copy Website Files to the New Server

2.1 Locate Your Website Files

On your old server, your website files are typically stored in one of these directories:

/var/www/html/yourdomain.com       # Apache default
/home/username/public_html/        # cPanel/shared hosting
/usr/share/nginx/html/             # Nginx default
                            

2.2 Transfer Files Using rsync (Recommended)

rsync is the gold standard for file migration. It is fast, resumable, and preserves file permissions. Run this from the new server:

# Syntax: rsync [options] source destination
rsync -avz -e ssh root@OLD_SERVER_IP:/var/www/html/ /var/www/html/

# Explanation of flags:
#  -a  : Archive mode (preserves permissions, timestamps, symlinks)
#  -v  : Verbose output
#  -z  : Compress data during transfer
                            

2.3 Alternative: Transfer Using SCP

If rsync is not available, use SCP (Secure Copy Protocol):

scp -r root@OLD_SERVER_IP:/var/www/html/ /var/www/html/
                            

Warning: Do NOT use FTP for large migrations. FTP is unencrypted and slow. rsync over SSH is always the recommended method for server-to-server transfers.

Step 3 – Migrate Your Database

This is the most critical step. An incorrect database migration can break your entire site. Follow these steps carefully.

3.1 Export Database from Old Server

SSH into your old server and create a complete database dump using mysqldump:

# Export a single database:
mysqldump -u root -p your_database_name > backup.sql

# Export all databases:
mysqldump -u root -p --all-databases > all_databases.sql

# Compress the dump for faster transfer:
mysqldump -u root -p your_database_name | gzip > backup.sql.gz
                            

3.2 Transfer the Database Dump

Copy the database dump from the old server to the new server:

# Run this from the NEW server:
scp root@OLD_SERVER_IP:~/backup.sql /root/backup.sql

# Or if compressed:
scp root@OLD_SERVER_IP:~/backup.sql.gz /root/backup.sql.gz
                            

3.3 Create a New Database on the New Server

# Log into MySQL on the new server:
mysql -u root -p

# Inside the MySQL shell:
CREATE DATABASE your_database_name;
CREATE USER 'dbuser'@'localhost' IDENTIFIED BY 'StrongPassword123!';
GRANT ALL PRIVILEGES ON your_database_name.* TO 'dbuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;
                            

3.4 Import the Database

# Import uncompressed dump:
mysql -u root -p your_database_name < /root/backup.sql

# Import compressed dump:
gunzip < /root/backup.sql.gz | mysql -u root -p your_database_name
                            

Pro Tip: For very large databases (10GB+), consider using Percona XtraBackup or mydumper for faster, parallel exports and imports without locking tables.

Step 4 – Configure the Site and Test Without Changing DNS

This is the zero-downtime magic step. You will access your site on the new server by temporarily overriding DNS on your local machine — without touching your live DNS records. Visitors will still hit the old server while you test.

4.1 Configure Your Web Server Virtual Host

Create a virtual host configuration for your domain on the new server:

# Create a new Apache virtual host config:
nano /etc/apache2/sites-available/yourdomain.com.conf

# Add this content:

    ServerName yourdomain.com
    ServerAlias www.yourdomain.com
    DocumentRoot /var/www/html/yourdomain.com
    ErrorLog ${APACHE_LOG_DIR}/yourdomain-error.log
    CustomLog ${APACHE_LOG_DIR}/yourdomain-access.log combined


# Enable the site:
a2ensite yourdomain.com.conf && systemctl reload apache2
                            

4.2 Update wp-config.php (WordPress Only)

If you are migrating a WordPress site, update the database connection details in wp-config.php:

define( 'DB_NAME',     'your_database_name' );
define( 'DB_USER',     'dbuser' );
define( 'DB_PASSWORD', 'StrongPassword123!' );
define( 'DB_HOST',     'localhost' );
                            

4.3 Test Using Your Local Hosts File

Edit the hosts file on your own computer (not the server) to temporarily route your domain to the new server's IP:

# On Mac / Linux — edit this file:
sudo nano /etc/hosts

# On Windows — edit this file (run Notepad as Administrator):
C:\Windows\System32\drivers\etc\hosts

# Add this line (replace with your new server's IP and domain):
123.45.67.89    yourdomain.com www.yourdomain.com
                            

Now open your browser and visit yourdomain.com. You will see the site loading from the new server — even though DNS still points to the old one. Test everything thoroughly:

• All pages load correctly

• Forms, logins, and checkout flows work

• Images, CSS, and JavaScript load without errors

• Database queries return correct data

• SSL certificate is configured (see Step 4.4)

4.4 Install SSL Certificate

Install a free Let's Encrypt certificate using Certbot before going live:

apt install certbot python3-certbot-apache -y

# Issue certificate using standalone mode (before DNS switch):
certbot certonly --standalone -d yourdomain.com -d www.yourdomain.com

# After DNS is pointed to new server:
certbot --apache -d yourdomain.com -d www.yourdomain.com
                            

Pro Tip: Remember to remove the hosts file entry after testing. If you forget, your browser will always resolve to the new server IP even after DNS changes.

Step 5 – Reduce DNS TTL (Prepare for the Switch)

DNS records have a Time To Live (TTL) value that tells resolvers how long to cache the record. If your TTL is 24 hours (86400 seconds) and you change the DNS, it can take up to 24 hours for the whole internet to see the new IP.

To minimize this window, reduce your DNS TTL to 300 seconds (5 minutes) at least 24 hours before you plan to switch. This ensures that when you change DNS, propagation happens in under 5 minutes globally.

How to reduce TTL:

• Log into your domain registrar or DNS provider

• Navigate to your DNS records for the domain

• Find your A record (the one pointing to your old server IP)

• Change the TTL value from 86400 (or 3600) to 300

• Save the changes and wait 24 hours before proceeding

Warning: Do not skip this step. If you forget to lower the TTL, some visitors may continue hitting the old server for hours after you switch DNS.

Step 6 – Switch DNS and Go Live

By now your new server is fully configured, tested, and running in parallel. All you need to do is update your DNS A record to point to the new server's IP address.

6.1 Final Data Sync Before Cutover

Run a final rsync right before you change DNS to capture any content changes made since your initial file transfer:

# Run this from the NEW server one more time:
rsync -avz -e ssh root@OLD_SERVER_IP:/var/www/html/ /var/www/html/

# Export and re-import the database to capture recent changes:
# (On old server)
mysqldump -u root -p your_database_name > final_backup.sql

# Transfer and import to new server:
scp root@OLD_SERVER_IP:~/final_backup.sql /root/final_backup.sql
mysql -u root -p your_database_name < /root/final_backup.sql
                            

6.2 Update the DNS A Record

• Log into your DNS provider or domain registrar

• Find the A record for yourdomain.com and www.yourdomain.com

• Change the IP address from your old server IP to your new server IP

• Set TTL to 300 (if not already done)

• Save the changes

6.3 Monitor DNS Propagation

Use these free tools to track how quickly the new DNS is propagating globally:

• dnschecker.org – Real-time global DNS propagation checker

• whatsmydns.net – Check A record from multiple locations

• intodns.com – Full DNS health check

Pro Tip: Most users will see the new server within 2–10 minutes when TTL is set to 300. Full global propagation typically completes within 30–60 minutes.

Step 7 – Post-Migration Verification Checklist

Once DNS has propagated, run through this checklist to confirm everything is fully operational:

• [ ] Website loads correctly at yourdomain.com

• [ ] HTTPS is working and SSL certificate is valid (no browser warnings)

• [ ] All pages, images, and media files are loading

• [ ] User login and registration works

• [ ] Contact forms and emails are sending correctly

• [ ] E-commerce checkout (if applicable) is fully functional

• [ ] Google Analytics / tracking scripts are firing

• [ ] Check server logs for errors: tail -f /var/log/apache2/error.log

• [ ] Run a speed test at GTmetrix or PageSpeed Insights — confirm improvement

• [ ] Set up automated backups on the new server

• [ ] Configure a firewall (UFW or iptables)

• [ ] Keep old server active for at least 48 hours as a fallback

Troubleshooting Common Migration Issues

500 Internal Server Error

This usually means incorrect file permissions. Fix with:

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

Database Connection Failed

Verify your database credentials in your app's config file, then test the connection manually:

mysql -u dbuser -p -h localhost your_database_name

# If it fails, verify the user and database exist:
mysql -u root -p -e "SHOW DATABASES; SELECT User, Host FROM mysql.user;"
                            

Site Loads the Old Server After DNS Change

Your browser may have cached the old DNS entry. Try these fixes:

• Clear your browser cache and DNS cache

• Test in an incognito/private window

• On Windows, run: ipconfig /flushdns

• On Mac, run: sudo dscacheutil -flushcache

• On Linux, run: sudo systemctl restart nscd

• Check your local hosts file — remove any test entries you added in Step 4

Emails Not Working After Migration

If you hosted email on your old server, update your MX records in DNS to point to your new server or mail provider. Do NOT change MX records at the same time as A records — stagger them by at least 1 hour to avoid email loss.

Essential Post-Migration Security Hardening

Now that your site is live on the dedicated server, apply these critical security configurations:

Configure UFW Firewall

ufw allow OpenSSH
ufw allow 'Apache Full'    # or 'Nginx Full'
ufw enable
ufw status verbose
                            

Disable Root SSH Login

nano /etc/ssh/sshd_config

# Change these settings:
PermitRootLogin no
PasswordAuthentication no   # only if using SSH keys

# Restart SSH:
systemctl restart sshd
                            

Enable Automatic Security Updates & Fail2Ban

# Enable Automatic Security Updates
apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

# Install Fail2Ban (Brute Force Protection)
apt install fail2ban -y
systemctl enable --now fail2ban
                            

Conclusion

You've successfully migrated your website to a dedicated server without any downtime. By following the parallel-server approach — setting up, syncing, testing with the hosts file trick, lowering TTL, and then performing the final DNS switch — your visitors never experienced an interruption.

Your website is now running on dedicated hardware with more power, better security, and full control. This foundation supports everything from high-traffic spikes to advanced server-level optimizations like Redis caching, custom PHP configurations, and CDN integration.

Why Choose Leo Servers for Your Dedicated Server?

Now that your migration is complete, it's worth understanding what makes Leo Servers stand apart from other major hosting providers.

• 1. 250+ Global Locations — The Widest Coverage in the Industry: Most dedicated server providers offer 10–30 data center locations. Leo Servers operates in over 250 locations across every continent — including cities in Africa, South America, Central Asia, and Southeast Asia that major providers simply don't cover. This means you can place your server physically close to your actual audience, reducing latency and improving load times for users in any region of the world. Whether you need a server in Nairobi, Karachi, Ho Chi Minh City, or Buenos Aires, Leo Servers has you covered — no workarounds.

• 2. Every Server is Single-Tenant Bare Metal: Unlike cloud providers that sell "dedicated-like" virtual instances, every Leo Servers machine is true bare metal — no hypervisor layer, no shared hardware, no noisy neighbors. You get 100% of the CPU, RAM, and storage you pay for, with direct hardware access and predictable performance every single time.

• 3. Intel, AMD, and GPU Options Under One Roof: Leo Servers offers a full range of hardware configurations — Intel Xeon, AMD EPYC, and NVIDIA GPU servers — all available across their global network. Whether you need raw compute power for a high-traffic web application, GPU acceleration for AI/ML workloads, or high-density storage for backups and media, you configure exactly what you need without switching providers.

• 4. Unmetered and 10/20/40/100 Gbps Bandwidth Options: Bandwidth pricing is where many providers quietly charge extra. Leo Servers offers transparent bandwidth tiers including unmetered connections and speeds up to 100 Gbps, making it practical for video streaming platforms, game servers, large SaaS applications, and content delivery without surprise overage bills at the end of the month.

• 5. Built-In DDoS Protection: DDoS attacks are increasingly common and can take an unprotected server offline within seconds. Leo Servers includes DDoS protection across its server lineup as a standard offering — not an expensive add-on. This is particularly valuable for gaming servers, financial applications, and e-commerce platforms that are frequent targets.