How to Migrate from Shared Hosting to a Dedicated Server (Zero Downtime)

Step 1: Audit Your Current Environment

Document everything about your current setup:

• Server software — Web server (Apache/Nginx/Caddy), language runtimes (PHP version, Node.js version, Python version), database (MySQL/MariaDB/PostgreSQL version)
• Installed packages — All system packages, PECL extensions, npm/Composer/Pip global packages
• Application configuration — Environment variables, config files, .htaccess rules, cron jobs, systemd services
• SSL certificates — List domains with certificates, expiry dates, and renewal methods
• Storage usage — Total disk usage by directory, database sizes
• Traffic patterns — Peak hours, average concurrent users, bandwidth usage

Run dpkg --get-selections > packages.txt (Debian/Ubuntu) or rpm -qa > packages.txt (RHEL/CentOS) to capture all installed packages.

Step 2: Order & Configure Your Dedicated Server

When ordering your dedicated server at Hostingowy, specify:

• Same or newer OS version as your current environment
• Matching or higher PHP/MySQL/other runtime versions
• Additional IP addresses if you serve multiple SSL sites
• NVMe storage configuration (we use ZFS with compression)

Our provisioning system deploys dedicated servers in under 15 minutes. Once it's ready, run our getting started guide to install your required software stack.

Step 3: Set Up a Staging Copy

Before cutting over production traffic, build a staging replica of your environment on the new server. This lets you:

• Test that all applications work correctly
• Benchmark performance on the new hardware
• Validate configuration differences
• Train your team on the new environment

Step 4: Transfer Application Files

Use rsync for efficient, resumable file transfers:

# Initial sync (run during low-traffic hours)
rsync -avz --progress --delete \
  root@old-server:/var/www/ \
  /var/www/

# Final sync (just before cutover, will be fast due to incremental)
rsync -avz --progress --delete \
  root@old-server:/var/www/ \
  /var/www/

The first sync transfers everything. The second sync (run immediately before cutover) only transfers changed files, typically taking seconds.

Step 5: Transfer Databases

For MySQL/MariaDB, use mysqldump with compression:

# On old server: dump all databases
mysqldump --all-databases --single-transaction \
  --routines --triggers --events | gzip > db_dump.sql.gz

# Transfer to new server
scp root@old-server:~/db_dump.sql.gz /tmp/

# On new server: restore
gunzip < /tmp/db_dump.sql.gz | mysql -u root -p

For PostgreSQL, use pg_dumpall. For both, take a final incremental transfer just before cutover (using binary logs or WAL archiving).

Step 6: Transfer SSL Certificates & Configuration

Copy SSL certificates and site configuration files:

# Copy SSL certificates
rsync -avz root@old-server:/etc/letsencrypt/ /etc/letsencrypt/

# Copy web server configs
rsync -avz root@old-server:/etc/nginx/ /etc/nginx/
# Or for Apache:
rsync -avz root@old-server:/etc/apache2/ /etc/apache2/

# Copy systemd service files
rsync -avz root@old-server:/etc/systemd/system/*.service \
  /etc/systemd/system/

Step 7: Final Data Sync

Put your application in maintenance mode (or scheduled downtime for write-heavy apps). Run the final rsync and database dump to capture any last changes. This window should be under 5 minutes if you've done the preparatory syncs.

Step 8: Start Services on New Server

systemctl restart nginx php8.2-fpm mysql
systemctl status nginx php8.2-fpm mysql

Verify all services are running and application health checks pass.

Step 9: Update DNS

Lower your DNS TTLs a few days before migration (e.g., from 3600 to 60 seconds). On cutover day:

• Point your domain's A record (or CNAME) to the new server's IP
• Update any other DNS records (MX, TXT, etc.) as needed
• Monitor DNS propagation using dig or whatsmydns.net

Most DNS changes propagate within 5-15 minutes with low TTLs. Keep both servers running for at least 48 hours post-migration to catch late-propagating requests.

Step 10: Post-Migration Verification

Check these critical items after cutover:

• SSL certificates are valid and auto-renewal is working
• All redirect rules and URL rewrites work correctly
• Cron jobs are running on schedule
• Email delivery (if self-hosted) is working
• Backup scripts are configured and running
• Monitoring alerts are configured for the new server

Step 11: Rollback Plan (Just in Case)

If something goes wrong, your rollback is straightforward:

1. Update DNS records back to the old server IP
2. Restart services on the old server
3. Import any data written on the new server back to the old one

Keep both servers running for at least 7 days after migration. The cost of a few extra days of server time is far less than the cost of an unsuccessful migration.