How to Migrate Your Server: Zero Downtime Migration Guide

Migrating to a new server can be stressful, but with proper planning, you can achieve a seamless transition with minimal or zero downtime. This guide walks you through the entire process, from preparation to post-migration verification.

Planning Your Migration

1. Inventory Your Current Setup

Before migrating, document everything on your current server:

• Applications and services: Web servers, databases, mail servers, cron jobs
• Configuration files: Apache/Nginx configs, PHP settings, database configs
• Data volumes: Website files, database sizes, email storage
• Dependencies: PHP version, MySQL version, required extensions
• SSL certificates: Certificate files, private keys, renewal dates
• DNS records: Current DNS configuration for all domains

2. Choose Your Migration Strategy

Select the approach that matches your downtime tolerance:

• Cold migration: Stop services, transfer data, start on new server. Simple but requires downtime.
• Warm migration: Set up new server, sync data, brief cutover. Minimal downtime.
• Hot migration: Parallel operation with real-time sync, instant failover. Zero downtime but complex.

3. Set Up the New Server

Prepare your new server to match the old environment:

• Install the same OS version (or newer if compatible)
• Install and configure web server (Apache, Nginx)
• Install database server with matching version
• Install required PHP versions and extensions
• Configure firewall rules to match current setup
• Set up monitoring and backup systems

Data Transfer Methods

For Files: rsync

rsync is the gold standard for file transfers. It's efficient (only transfers changes) and can resume interrupted transfers:

• Initial sync while old server is still active
• Final sync during cutover window for minimal data loss
• Use compression (-z) for faster transfers over slow connections
• Preserve permissions and ownership with -a flag

For Databases: mysqldump or pg_dump

For MySQL/MariaDB and PostgreSQL, native dump tools provide reliable transfers:

• Small databases: Simple dump and restore works well
• Large databases: Use replication for zero-downtime migration
• Very large databases: Consider physical backups (Percona XtraBackup)

For Email: imapsync or rsync

Email migration requires careful handling:

• Use imapsync for IMAP mailboxes (preserves folder structure)
• rsync Maildir directories for direct file transfer
• Don't forget to migrate aliases, forwarders, and filters

Zero Downtime Migration Steps

Phase 1: Preparation (Days Before)

• Set up the new server completely
• Test all applications on new server using hosts file override
• Do initial data sync (may take hours for large sites)
• Lower DNS TTL to 300-600 seconds (at least 48 hours before migration)

Phase 2: Database Replication (Optional)

For zero downtime, set up database replication:

• Configure old server as master, new server as slave
• Let replication catch up completely
• During cutover, promote slave to master

Phase 3: Final Sync and Cutover

• Put old site in maintenance mode (or read-only if possible)
• Run final rsync to capture last changes
• Export and import final database changes (or promote replica)
• Verify data integrity on new server
• Update DNS to point to new server IP
• Monitor DNS propagation

Phase 4: Verification

• Test all critical functionality on new server
• Check SSL certificates are working
• Verify email delivery (send test emails)
• Monitor error logs for issues
• Check all cron jobs are running

DNS Cutover Strategies

Standard DNS Update

The simplest approach: update A/AAAA records to new IP. Propagation takes minutes to hours depending on TTL. Some users may see old server during propagation.

Using a Load Balancer

Point DNS to a load balancer, then switch backend servers. Instant cutover with no DNS propagation wait, but requires load balancer infrastructure.

Cloudflare or CDN Proxy

If using Cloudflare, you can change origin IP instantly through their dashboard. Traffic switches immediately since Cloudflare handles DNS and proxying.

Common Migration Pitfalls

1. Forgetting Cron Jobs

Scheduled tasks are easily overlooked. Export crontabs and systemd timers from the old server and recreate them on the new one.

2. Hardcoded IP Addresses

Search configuration files for the old server's IP address. Update any hardcoded references to use hostnames or the new IP.

3. File Permissions

Different user IDs between servers can break permissions. Verify web server user can read files and application directories are writable where needed.

4. Missing PHP Extensions

Applications may fail silently with missing extensions. Compare phpinfo() output between servers to ensure all required extensions are installed.

5. Database Character Set Issues

Mismatched character sets cause encoding problems. Ensure database, tables, and connection use consistent UTF-8 encoding.

Post-Migration Checklist

• All websites loading correctly
• SSL certificates valid and renewing
• Email sending and receiving
• Database connections working
• Cron jobs executing on schedule
• Backups running on new server
• Monitoring alerting correctly
• Old server decommissioned (after observation period)

Rollback Plan

Always have a rollback plan:

• Keep old server running for at least 48-72 hours after migration
• Don't delete any data from old server until fully verified
• Document how to quickly switch DNS back if needed
• Test rollback procedure before migration if possible

Conclusion

Server migration doesn't have to be stressful. With proper planning, thorough testing, and a clear cutover strategy, you can migrate with minimal or zero downtime. The key is preparation: set up and test everything on the new server before touching DNS, and always have a rollback plan ready.

At Packet25, we offer free migration assistance for new customers. Our team can help plan and execute your migration to ensure a smooth transition to your new Swiss-hosted infrastructure.