The Ultimate Server Migration Checklist: A Step-by-Step Planning Guide

A server migration is only as good as the planning behind it. Whether you are moving a simple brochure website or a complex e-commerce platform, having a detailed checklist ensures nothing falls through the cracks. This guide provides a comprehensive, step-by-step migration checklist that covers everything from initial planning to post-migration monitoring.

Phase 1: Planning and Preparation

Inventory your current setup

Before making any changes, document your existing environment completely:

• Web server software and version (Apache 2.4, Nginx 1.24, LiteSpeed, etc.)
• PHP version and loaded extensions
• Database server and version (MySQL 8.0, MariaDB 10.6, PostgreSQL 15, etc.)
• Operating system and version
• All domain names and subdomains hosted on the server
• SSL certificates — who issued them, when they expire, and how they are managed
• Email configuration — where email is hosted and what MX records are in place
• Cron jobs and scheduled tasks
• Custom server configurations (.htaccess rules, php.ini overrides, Nginx rewrites)
• Third-party integrations — payment gateways, APIs, CDN configuration

Choose your migration window

Pick a time when your website traffic is lowest. For most businesses, this is late evening or early morning on a weekday. Avoid migrating on Fridays (in case issues arise over the weekend) or during peak business periods. Communicate the migration window to stakeholders so they know what to expect.

Set up the new server

Provision the new server and install all required software. Match the PHP version, database version, and web server software as closely as possible to the old server. Configure virtual hosts, PHP settings, and any custom server parameters. Do not proceed until the new server environment matches your requirements.

Phase 2: Pre-Migration Steps

Lower DNS TTL

At least 24 to 48 hours before migration, lower your domain's DNS TTL to 300 seconds (5 minutes). This ensures that when you eventually switch DNS, the change propagates quickly. Verify the new TTL is active by querying your DNS records with a tool like dig or nslookup.

Create a complete backup

Back up everything:

• All website files, including hidden files like .htaccess
• Complete database dump (use mysqldump with the --single-transaction flag for InnoDB tables)
• Email data if stored on the server
• SSL certificate files and private keys
• Configuration files

Store the backup in a location separate from both the old and new servers. Verify the backup by checking file sizes and attempting a test restore.

Document current DNS records

Export or screenshot all DNS records for every domain being migrated. This includes A records, CNAME records, MX records, TXT records (SPF, DKIM, DMARC), NS records, and any SRV records. You will need this as a reference when configuring DNS after migration.

Phase 3: Migration Execution

Transfer files

Copy all website files from the old server to the new server. Use rsync for large transfers as it supports resume and only transfers changed files. Verify file counts and directory sizes match between old and new servers. Check that hidden files (dotfiles) were included in the transfer.

Transfer and import databases

Export databases from the old server and import them on the new server. Create the database, user, and permissions on the new server before importing. After import, verify table counts) and run a few queries to confirm data integrity.

Update configuration files

Update any configuration files that reference the old server:

• Database connection settings (hostname, username, password, database name)
• File paths that may differ between servers
• Any hardcoded server IP addresses or hostnames
• Email relay configuration if applicable

Set correct file permissions

Ensure file and directory permissions are set correctly on the new server. Directories should typically be 755, files should be 644, and sensitive configuration files should be 600 or 640. Check that the web server user has read access to all website files.

Phase 4: Testing

Preview with HostCheck

Use HostCheck to preview every website on the new server before touching DNS. Enter each domain and the new server's IP address to generate preview links. This is the most critical step in the entire migration — it is your last chance to catch problems before they affect visitors.

Test checklist

For each website, verify the following through the preview:

• Homepage loads correctly with all images, styles, and scripts
• Navigate to at least 10 internal pages — check for broken links and missing content
• Test all forms (contact forms, search, login, registration)
• Verify dynamic content loads from the database correctly
• Check that uploaded media files (images, PDFs, videos) are accessible
• Test the CMS admin panel if applicable (WordPress wp-admin, etc.)
• Verify custom URL rewrite rules work (pretty permalinks, custom routes)
• Check for PHP errors in the server error log
• Test email sending if the server handles outgoing email
• Verify cron jobs are set up and running

Phase 5: DNS Switch

Update DNS records

Once testing is complete and all issues are resolved, update your domain's A record to point to the new server IP. If you have multiple domains or subdomains, update them all. Do not change MX records unless you are also migrating email.

Set up SSL on the new server

If you have not already, generate SSL certificates on the new server. With Let's Encrypt and Certbot, you can generate certificates as soon as DNS points to the new server. Monitor your site for mixed content warnings after enabling HTTPS.

Phase 6: Post-Migration

Monitor closely

For the first 48 hours after migration, monitor your website intensively:

• Check uptime monitoring alerts
• Review server error logs every few hours
• Monitor website analytics for unexpected traffic drops
• Test the website from different devices and locations
• Ask team members and trusted users to browse the site and report issues

Keep the old server running

Do not decommission the old server for at least one week after migration. If a critical issue is discovered, you can quickly revert DNS to the old server while you fix the problem. Only cancel the old hosting after you are confident everything is working correctly.

Increase TTL

After verifying the migration is successful and DNS has fully propagated, increase your TTL back to a normal value (3600 seconds or higher). This reduces DNS query load and improves resolution speed for repeat visitors.

Update external references

Update any external services that reference the old server IP — monitoring tools, CDN origin settings, firewall rules, API configurations, and deployment scripts.

Build a Rollback Plan Before You Switch

The strongest migration plans include an explicit rollback path. If a critical issue appears after the DNS switch, you need to know exactly how you will respond in the first fifteen minutes. That usually means keeping the old hosting active, keeping a copy of the previous DNS values, and identifying the threshold that would trigger a rollback rather than continued debugging on the live issue.

A rollback plan should answer three questions clearly: who decides whether to revert, how quickly the DNS change can be reversed, and what data or content might be affected during the window between the cutover and the rollback. Even when you never need to use it, the existence of a rollback plan leads to better migration decisions and less panic during launch.

Final Sign-Off Checks

Before you declare the migration complete, check the handful of things that most often get missed after technical testing is done:

• Important redirects still point to the right destination and do not create loops
• Forms send mail or data to the correct live endpoint
• CDN, firewall, and caching layers now reference the new origin where needed
• Search Console, analytics, uptime monitoring, and external services are still reporting normally
• The old server remains available until you are confident no hidden dependency is left behind

Conclusion

A server migration checklist is not just a nice-to-have — it is essential for a smooth, zero-downtime migration. Print this checklist, adapt it to your specific needs, and work through it methodically. The key steps that most prevent problems are lowering TTL in advance, creating verified backups, and thoroughly testing with HostCheck before switching DNS. Follow this process, and your migrations will be predictable, professional, and stress-free.