12 Common Server Migration Mistakes (And How to Avoid Them)
Server migrations do not fail because the technology is difficult. They fail because of overlooked details, skipped steps, and poor planning. After helping thousands of users preview their sites on new servers, we have seen the same mistakes repeated over and over. Here are the 12 most common server migration mistakes — and how to avoid every one of them.
1. Not Creating a Complete Backup
The most dangerous mistake is starting a migration without a full, verified backup. This includes website files AND the database. A files-only backup is useless without the database, and vice versa. Always verify that your backup can be restored before proceeding.
2. Forgetting to Lower DNS TTL
If your DNS records have a 24-hour TTL and you change them, some visitors will see the old server for up to 24 hours. Lower your TTL to 300 seconds at least 24 hours before migration. This one step can be the difference between a smooth transition and hours of complaints.
3. Not Testing on the New Server
This is the most common and most preventable mistake. Too many people switch DNS first and then discover problems. Use HostCheck to preview your site on the new server before making any DNS changes. Test thoroughly — every page, every form, every feature.
4. PHP Version Mismatch
If the old server runs PHP 7.4 and the new server runs PHP 8.2, your code may produce errors due to deprecated functions and changed behaviours. Check the PHP version on both servers and test for compatibility before migrating.
5. Incorrect File Permissions
Different servers may have different default file permissions and user/group ownership. After transferring files, ensure directories are 755 and files are 644. Configuration files with sensitive data should be 600 or 640.
6. Missing .htaccess File
The .htaccess file is hidden by default and easily missed during file transfers. Many FTP clients do not show hidden files unless explicitly configured. A missing .htaccess can cause broken URLs, missing redirects, and security issues. Always verify hidden files are transferred.
7. Forgetting About Email
If the old server handles email, switching DNS without configuring email on the new server will break email delivery. Before migrating, identify where your email is hosted and ensure MX records, SPF, and DKIM are correctly configured.
8. Hardcoded URLs
Websites sometimes contain hardcoded references to the old server or domain. This is common in WordPress databases, CSS files, and JavaScript. After migration, search for and replace any references to the old server hostname or IP address.
9. SSL Certificate Not Configured
Modern browsers block or warn users about sites without valid SSL. If you do not set up SSL on the new server before switching DNS, visitors will see security warnings. Generate a Let's Encrypt certificate on the new server before the DNS switch.
10. Cancelling Old Hosting Too Soon
Always keep the old server running for at least one week after migration. If something goes wrong, you can quickly revert DNS back to the old server while you fix the issue. Cancelling immediately leaves you with no fallback.
11. Not Checking Server Logs After Migration
After switching DNS, check the new server's error logs for problems. You may find 404 errors for URLs that worked on the old server, PHP errors from version differences, or database connection issues. Proactive log monitoring catches problems before visitors report them.
12. Migrating Without a Plan
The biggest meta-mistake is not having a written migration plan. Document every step, assign responsibilities, set a timeline, and prepare a rollback procedure. A migration checklist ensures nothing is overlooked and provides a record for future migrations.
Conclusion
Every one of these mistakes is preventable with proper planning and testing. The most critical step is number three — testing on the new server before switching DNS. HostCheck makes this easy by letting you preview your site on any server IP instantly. Combine thorough testing with a written migration plan, and you will avoid the vast majority of migration failures.