Skip to content
Hosting Operations11 min read

managed hosting migration: causes and solutions: Troubleshooting Checklist

Diagnose and fix managed hosting migration failures. Step-by-step troubleshooting guide with DNS, database, file transfer, and performance checks.

Written by Abdul AbrorTechnical Hosting Support Engineer
Focused view of a modern data server rack with blinking lights in a blue-lit environment.
Photo by panumas nikhomkhai on Pexels
On this page

TL;DR — Key takeaways

  • DNS propagation delays cause 70% of post-migration access issues; verify nameserver updates and TTL settings before declaring failure.
  • Database connection failures after migration stem from incorrect credentials, changed hostnames, or missing user privileges on the new server.
  • File permission mismatches break applications silently; always verify ownership and execute permissions match the web server user after transfer.
  • SSL certificate errors occur when certificates aren't reinstalled or AutoSSL hasn't regenerated; manual certificate installation resolves most cases.
  • Performance degradation signals resource limits, misconfigured caching, or missing PHP extensions; compare server specifications and installed modules.

Managed hosting migrations fail for predictable reasons. DNS records point to the wrong server. Database credentials don't match the new environment. File permissions break after transfer. SSL certificates expire or aren't installed. Performance suddenly tanks.

This troubleshooting guide walks through the most common managed hosting migration failures in order of diagnostic priority. Each section identifies symptoms, provides diagnostic commands, and lists concrete fixes. Use the quick-reference checklist at the end for rapid triage.

Common Migration Failure Symptoms

Migration failures present in distinct patterns. Recognizing the symptom category narrows the diagnostic path and prevents wasted troubleshooting time.

Access failures show error pages, timeouts, or the old site still loading. Content failures display broken layouts, missing images, or database connection errors. Performance failures manifest as slow page loads, timeout errors, or resource exhaustion messages. Security failures trigger SSL warnings, mixed content errors, or permission denied responses.

  • Site unreachable: DNS issues, firewall blocks, or incorrect domain configuration
  • Database errors: Connection refused, access denied, or wrong hostname
  • Broken assets: 404 errors on images, CSS, or JavaScript files
  • SSL warnings: Certificate not installed, expired, or domain mismatch
  • Permission errors: 403 Forbidden or 500 Internal Server Error
  • Slow performance: Resource limits, missing cache, or inefficient queries

DNS and Nameserver Diagnostics

DNS propagation is the leading cause of post-migration access issues. Your migration may be complete, but visitors still reach the old server because DNS records haven't updated globally.

Check what IP address your domain resolves to using dig or nslookup. Compare that IP to your new server's IP address. If they don't match, DNS hasn't propagated or wasn't updated correctly. Nameserver changes take 24-48 hours to propagate globally, but you can test immediately using the new server's IP in your hosts file.

  • Run `dig yourdomain.com +short` to see the current A record IP
  • Verify the IP matches your new hosting server's assigned address
  • Check nameservers with `dig yourdomain.com NS +short`
  • Use `nslookup yourdomain.com 8.8.8.8` to test against Google's DNS
  • Lower TTL values to 300 seconds before migration for faster updates
  • Add your domain to /etc/hosts pointing to the new IP for local testing

Database Connection Troubleshooting

Database connection failures after migration typically involve incorrect credentials, changed database hostnames, or missing user permissions. Managed hosting environments often use localhost for database connections, but some use remote hostnames or IP addresses.

Check your application's configuration file for database settings. Common files include wp-config.php for WordPress, .env for Laravel, or config.php for custom applications. Verify the database hostname, username, password, and database name match what your hosting provider assigned on the new server.

  • Locate configuration file: wp-config.php, .env, config/database.php, or settings.php
  • Verify DB_HOST matches new server hostname (often localhost or 127.0.0.1)
  • Confirm DB_USER and DB_PASSWORD match credentials on new server
  • Test connection with `mysql -h hostname -u username -p` from SSH
  • Check user privileges: `SHOW GRANTS FOR 'username'@'localhost';`
  • Recreate database user if privileges are missing or incorrect
  • Ensure database was imported completely without errors

File Transfer and Permission Verification

Incomplete file transfers and incorrect permissions break applications silently. Files may transfer successfully but land with wrong ownership or missing execute permissions, causing 403 or 500 errors.

After migration, verify file counts match between source and destination. Check that ownership matches the web server user (often www-data, apache, or nobody). Directories typically need 755 permissions, files need 644, and executable scripts need 755. Configuration files containing sensitive data should be 600 or 640.

  • Compare file counts: `find /path -type f | wc -l` on both servers
  • Check ownership: `ls -la` and verify files belong to the web server user
  • Set correct ownership: `chown -R webuser:webuser /path/to/site`
  • Fix directory permissions: `find /path -type d -exec chmod 755 {} \;`
  • Fix file permissions: `find /path -type f -exec chmod 644 {} \;`
  • Verify .htaccess transferred and contains correct rewrite rules
  • Check for hidden files: `ls -la` shows files starting with a dot

SSL Certificate and HTTPS Issues

SSL certificate errors appear when certificates aren't transferred, haven't regenerated via AutoSSL, or don't match the domain. Browsers display warnings about untrusted connections or mixed content when the certificate is missing or invalid.

Managed hosting providers often use Let's Encrypt with automatic renewal. After migration, the certificate may need 24-48 hours to generate automatically, or you may need to trigger manual generation through the hosting control panel. If you used a custom SSL certificate, you must reinstall it manually on the new server.

  • Check certificate status with `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com`
  • Verify certificate matches your domain name in the Subject Alternative Name field
  • Trigger AutoSSL regeneration through hosting control panel if available
  • Install custom SSL certificate and private key if you're not using AutoSSL
  • Update application URLs from http:// to https:// in configuration and database
  • Fix mixed content warnings by updating hardcoded http:// links to https://
  • Enable HSTS header after confirming HTTPS works: `Strict-Transport-Security: max-age=31536000`

Performance and Resource Diagnostics

Performance degradation after migration signals resource constraints, missing caching layers, or configuration mismatches. The new server may have lower resource limits, different PHP settings, or missing performance modules that existed on the old server.

Compare PHP memory limits, max execution time, and upload limits between old and new servers. Check that caching mechanisms like Redis, Memcached, or OPcache are installed and configured. Verify database query performance hasn't degraded due to missing indexes or different MySQL settings.

  • Check PHP settings: `php -i | grep memory_limit` and compare to old server
  • Verify PHP extensions: `php -m` and confirm all required modules are installed
  • Test OPcache status: create phpinfo() page and check opcache section
  • Monitor resource usage: `top` or `htop` to see CPU and memory consumption
  • Check error logs for timeout or memory exhaustion: `/var/log/apache2/error.log`
  • Enable query logging temporarily to identify slow database queries
  • Compare MySQL configuration: max_connections, query_cache_size, innodb_buffer_pool_size

Application-Specific Configuration Checks

Content management systems and frameworks require specific post-migration configuration updates beyond database credentials. Cached configuration files, hardcoded URLs, and environment-specific settings cause failures when not updated.

WordPress requires updating site URLs in wp_options table and regenerating .htaccess. Laravel needs cache clearing and environment file updates. Magento requires reindexing and cache flushing. Drupal needs cache rebuilding and settings.php verification.

  • WordPress: Update siteurl and home in wp_options table or use wp-cli search-replace
  • WordPress: Regenerate .htaccess by saving permalink settings in admin
  • Laravel: Run `php artisan config:clear` and `php artisan cache:clear`
  • Laravel: Update APP_URL in .env file to match new domain
  • Magento: Run `bin/magento setup:upgrade` and `bin/magento cache:flush`
  • Drupal: Clear cache with `drush cr` and verify settings.php database settings
  • Check for absolute paths in configuration that reference old server directories

Email Delivery and MX Record Validation

Email delivery breaks after migration when MX records aren't updated or email accounts aren't recreated on the new server. Outgoing mail fails when the server's SPF or DKIM records don't authorize the new IP address.

If your hosting provider manages email, verify MX records point to the correct mail server. If you use external email like Google Workspace or Office 365, confirm MX records weren't accidentally changed during migration. Test email delivery by sending from the application and checking mail logs for errors.

  • Check MX records: `dig yourdomain.com MX +short`
  • Verify MX priority values match pre-migration configuration
  • Test SMTP connection: `telnet mail.yourdomain.com 25`
  • Check mail logs for delivery errors: `/var/log/mail.log` or equivalent
  • Update SPF record to include new server IP if hosting email locally
  • Regenerate DKIM keys if using email authentication
  • Recreate email accounts on new server if not using external provider

Quick troubleshooting checklist

  • Verify DNS A record points to new server IP using dig or nslookup
  • Check nameserver propagation status and lower TTL if not yet migrated
  • Test database connection with credentials from application configuration file
  • Confirm database user has correct privileges on all required databases
  • Verify file counts match between source and destination servers
  • Set correct ownership: files should belong to web server user
  • Fix permissions: 755 for directories, 644 for files, 600 for sensitive config
  • Check SSL certificate is installed and matches domain name
  • Update application URLs from http to https in configuration and database
  • Compare PHP memory_limit and max_execution_time to old server
  • Verify all required PHP extensions are installed using php -m
  • Enable OPcache and verify it's active via phpinfo
  • Clear application cache: run framework-specific cache clear commands
  • Update hardcoded paths and URLs to match new server directories
  • Test email delivery and verify MX records point to correct mail server
  • Check error logs for permission, timeout, or connection errors
  • Verify .htaccess or nginx configuration transferred correctly
  • Test site functionality: login, forms, payment processing, file uploads
  • Monitor resource usage for first 24 hours to catch limit issues
  • Document any configuration changes made during troubleshooting

FAQ

How long does DNS propagation take after changing nameservers?

DNS propagation typically takes 24 to 48 hours globally after changing nameservers, though many visitors see updates within 4 to 8 hours. TTL (Time To Live) settings on your DNS records determine how long resolvers cache old information. Lowering TTL to 300 seconds (5 minutes) a day before migration speeds updates, but changes to nameservers themselves are governed by the parent zone's TTL and aren't affected by your record TTL. You can test immediately by editing your local hosts file to point your domain to the new IP address.

Why does my site still show the old content after migration?

Your site shows old content because DNS hasn't propagated to your location, your browser cached the old site, or your local DNS resolver cached the old IP address. First, verify DNS propagation by running 'dig yourdomain.com +short' and comparing the IP to your new server. If the IP is correct, clear your browser cache and cookies. If still seeing old content, flush your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS, or restart network-manager on Linux). Some ISP DNS resolvers ignore TTL and cache longer than specified, so testing through a different network or mobile data provides confirmation.

What causes database connection errors immediately after migration?

Database connection errors after migration stem from incorrect hostname, username, password, or missing database user privileges on the new server. Managed hosting environments often use 'localhost' as the database hostname, but some use remote hostnames like '127.0.0.1' or 'mysql.yourdomain.com'. Check your application's configuration file (wp-config.php, .env, or config.php) and verify all four parameters match what your hosting provider assigned. Even if credentials are correct, the database user must have privileges granted on the new server. Connect via SSH and run 'mysql -h hostname -u username -p' to test the connection manually, then check privileges with 'SHOW GRANTS FOR username@localhost' inside the MySQL shell.

How do I fix 403 Forbidden or 500 Internal Server errors after migration?

403 and 500 errors after migration are caused by incorrect file permissions, wrong ownership, or misconfigured .htaccess rules. Directories need 755 permissions (read and execute for everyone, write for owner), regular files need 644 (read for everyone, write for owner), and the web server user must own the files. Run 'ls -la' to check current ownership and permissions. Fix ownership with 'chown -R webuser:webuser /path/to/site' where webuser is your web server user (www-data, apache, or nobody). Fix permissions with 'find /path -type d -exec chmod 755 {} \;' for directories and 'find /path -type f -exec chmod 644 {} \;' for files. If errors persist, check that .htaccess transferred correctly and doesn't contain rules incompatible with your new server's Apache or PHP version.

Why is my site slow after migrating to a new managed hosting provider?

Performance degradation after migration indicates lower resource limits, missing caching layers, or different PHP/MySQL configurations on the new server. Compare PHP memory_limit and max_execution_time between servers using 'php -i | grep memory_limit'. Verify performance modules like OPcache, Redis, or Memcached are installed with 'php -m'. Check that your new hosting plan matches or exceeds the old plan's CPU, RAM, and I/O limits. Database performance suffers when MySQL configuration differs significantly, particularly innodb_buffer_pool_size and query_cache_size settings. Enable OPcache if missing, clear application cache to remove stale configuration, and monitor 'top' or 'htop' during slow periods to identify whether you're hitting CPU, memory, or I/O limits.

Related articles