Introduction

A website migration can move the application cleanly while database access starts failing because the new web server is no longer trusted by the remote MySQL server. The app may have the correct database hostname, username, and password, but the database still rejects the connection because the allowed host list, firewall policy, or source IP expectations were never updated for the new server.

Treat this as a host-authorization problem instead of a general database-outage problem. Start by confirming which source IP or hostname the database actually sees from the migrated web server, because remote MySQL setups often fail after cutover even when every application credential looks correct.

Symptoms

  • The site shows MySQL access denied errors right after moving to a new web server
  • The same database user worked before migration but fails from the new host
  • Direct database tools on the database server work, but the migrated app cannot connect
  • The database hostname is correct, yet the app still cannot log in remotely
  • Some application nodes connect successfully while the new node is rejected
  • The issue started after VPS migration, web cutover, hosting change, or load balancer move

Common Causes

  • The database user is only allowed from the old web server host or IP address
  • A database firewall or security group still trusts the previous application server
  • NAT, proxy, or load balancer changes make the database see a different source IP than expected
  • The migrated app now runs from multiple nodes, but only one host was authorized for remote access
  • The database account uses host-specific grants that were never updated during the migration
  • Troubleshooting focused on credentials and imports instead of the source host identity reaching MySQL

Step-by-Step Fix

  1. Capture the exact database error returned by the application and confirm it is an access denied problem rather than a timeout or wrong-host issue, because the fix path for blocked remote access is different from the fix path for broken routing.
  2. Identify the actual source IP or hostname the remote MySQL server sees from the migrated web server, because firewalls, NAT, containers, or load balancers can make the connection appear to come from a different address than the app team expects.
  3. Compare that real source identity with the allowed-host settings for the database user, because a user granted for the old server will be rejected immediately after the web cutover moves to a new host.
  4. Review database firewall rules, security groups, or host-access controls on the database side, because even a correct MySQL grant can still fail if the network policy only trusts the retired web server.
  5. Check whether the migrated application now uses additional nodes, workers, or cron hosts that also need remote database access, because fixing one frontend server may still leave background jobs blocked.
  6. Update the real active allowlist or database host grant only after confirming the source IPs that should be trusted, because broad temporary access can hide the issue while creating unnecessary exposure.
  7. Retest the exact application flow that was failing and confirm the database now accepts the connection from the new environment, because a generic login test may not represent the same source path the app actually uses.
  8. Verify that the old web server can no longer connect if it has been retired, because lingering access from the previous host can confuse cutover validation and leave unnecessary trust behind.
  9. Document the final remote-database access model, trusted source hosts, and any firewall dependencies, because remote MySQL host controls are frequently missed during future hosting migrations.