Introduction

A WordPress site can migrate successfully and still break because its Redis object cache is trying to connect to the old server. The homepage may load slowly, the admin may throw Redis connection errors, or parts of the site may behave inconsistently because cached values are still coming from the wrong place. This is usually not a generic cache-plugin problem. It is a migration configuration problem in the Redis connection layer.

The fix is to find where WordPress is still getting the old Redis host, socket, port, or authentication details, then clear stale cache state so the site reconnects cleanly to the new environment.

Symptoms

  • WordPress starts showing Redis connection errors after host migration
  • The site worked on the old server but fails or slows down immediately after cutover
  • The object cache plugin reports connection refused, no route to host, or socket errors
  • The admin area loads partially or behaves inconsistently after migration
  • Disabling the object cache temporarily improves the site
  • The site is using Redis, but the new host has a different Redis hostname, socket path, or credentials

Common Causes

  • WP_REDIS_HOST, WP_REDIS_PORT, or related constants still point to the old server
  • The site moved from TCP Redis to a Unix socket or vice versa and the config was not updated
  • A host-level environment variable or config include is still injecting old Redis settings
  • The destination server uses different Redis authentication, database index, or socket permissions
  • The object cache plugin kept stale connection details or cached values from the previous environment
  • A cloned config file or deployment secret was copied without updating Redis endpoints

Step-by-Step Fix

  1. Confirm that Redis is actually the failing component by checking the WordPress error output, object cache plugin status, or server logs, because a generic post-migration slowdown is not enough to prove the old Redis endpoint is the problem.
  2. Check wp-config.php and any server-side config includes for Redis-related constants and environment variables, because old hostnames, ports, socket paths, or passwords are often preserved there during migration.
  3. Verify whether the destination server expects Redis over TCP or a Unix socket, because moving between hosting environments often changes the connection method even when the plugin stays the same.
  4. Compare the new Redis endpoint details with the old server configuration, because the site may still be trying to reach a private IP, container hostname, or socket file that only existed on the previous host.
  5. Update the Redis connection settings to the correct destination values and make sure any authentication or database index settings also match, because a correct host with wrong auth or wrong database can still leave the cache effectively broken.
  6. Flush or disable the object cache briefly after correcting the connection target, because stale cache data and old connection state can make the site keep behaving as if it is still attached to the previous environment.
  7. Re-enable the cache and verify the plugin can connect cleanly from the new host, because a successful save of settings alone does not prove WordPress is using the updated Redis backend during real requests.
  8. Test both the frontend and wp-admin after the reconnection, because some migration-side cache issues only show up in authenticated sessions, background tasks, or plugin-heavy admin pages.
  9. Document the final Redis host, socket, auth, and plugin settings after the fix, because object cache configuration is easy to miss during future server moves and can quietly break an otherwise healthy migration.