How to Safely Migrate a WordPress Site to a New Server (Step-by-Step Guide)

8. Debugging with wp-config.php and the WordPress debug.log

When a migrated site isn’t working properly and you can’t immediately tell why, enabling WordPress’s debug mode can shed light on the problem. WordPress has built-in debugging constants that, when enabled, will display or log error messages for PHP issues. We’ll focus on using the debug log so you can capture errors in a file.

Open the wp-config.php on the new server and ensure the following lines are present (add them if not):

Putting WP_DEBUG to true turns on debugging mode (which causes PHP notices/warnings to be triggered). WP_DEBUG_LOG set to true will save those errors to a file called debug.log in the wp-content directory​. Setting WP_DEBUG_DISPLAY to false ensures that errors are not shown on the webpage to visitors (so your site won’t visibly break or reveal warnings to users), but instead they’ll be silently logged. After adding these, save wp-config.php. Then, load the page or action that is causing trouble.

Now, via FTP or File Manager, check the file wp-content/debug.log. This file will contain any errors, warnings, or notices that have occurred. The messages here can be very insightful. For example, you might see a PHP Fatal error about a function redeclaration or an undefined function – which could indicate a plugin didn’t load properly. Or a MySQL error indicating a missing table. Or a warning about file permissions, or a notice about a deprecated function. Each entry is timestamped, so look for entries corresponding to your recent tests.

Some common findings and how to address them:

• Allowed memory size exhausted…: This indicates a PHP memory limit issue – the site ran out of memory. The error will look like “Fatal error: Allowed memory size of X bytes exhausted…”. If this happens right after migration, possibly the new server’s PHP memory limit is lower. You can increase the memory available to WordPress by editing wp-config.php and adding:

  define('WP_MEMORY_LIMIT', '256M');


  (256M is a good value for most medium sites)​. This sets WordPress’s memory limit for the front-end. If the error occurs in admin, you might also bump WP_MAX_MEMORY_LIMIT. You could alternatively adjust the server’s PHP configuration (php.ini) if you have access. After increasing, reload and see if the error goes away​.

• Plugin-specific errors: The debug log might show an error coming from a specific plugin PHP file. For instance, “Call to undefined function curl_init() in …/pluginX/file.php” would hint that the cURL extension isn’t enabled on the new server’s PHP – enabling that extension would fix it. Or it might be a simple path issue. If a plugin is causing fatal errors and you can’t easily fix it, you might deactivate that plugin (rename its folder) until you figure out a solution or update it.

• Table not found errors: e.g., “Table ‘mydb.wp_sometable’ doesn’t exist”. This tells you something didn’t import. Perhaps a custom plugin had its own table that wasn’t in your SQL dump (some backup exports only include standard tables). You’d need to migrate that table as well or reinstall that plugin so it recreates the table.

• Notice about translation domain or missing translation files: If WP_DEBUG is true, you might see notices like “PHP Notice: load_textdomain… translation file not found for domain X”. These are usually benign and mean that a plugin or theme tried to load a language file that isn’t present. For example, if a plugin’s translation files didn’t get copied over, or if a domain name changed (affecting a path in the file). These warnings (often referring to a text domain for translations) won’t break the site; you can resolve them by ensuring the .mo language files for that plugin/theme are in wp-content/languages or the plugin’s languages folder, or simply ignore if you don’t need those translations. To suppress such notices, you can leave WP_DEBUG false on live sites.

• Deprecated function warnings: These might appear if the new environment uses a newer PHP or WP version and some old code in a theme/plugin is outdated. While not urgent, it’s a good reminder to update those plugins or code.

After debugging and fixing issues, remember to turn off debug mode (set WP_DEBUG back to false, and/or WP_DEBUG_DISPLAY true if it was changed). Or at least disable display and logging on production, because leaving debug on can slightly impact performance and fill your server with log files over time. Only keep it on while troubleshooting.

If the site is now functioning correctly on the new server with no significant errors in debug.log, you can breathe a sigh of relief – the migration is essentially successful. The final steps are to deal with any lingering plugin-specific issues and ensure the live site transition is smooth.