Introduction

An application migration can move code and even copy database data successfully while the app still connects to the old database server through an unchanged hostname. The site may load partially, admin tools may look correct, and one direct database test may pass, but the live application keeps using a database host value that still resolves to legacy infrastructure.

Treat this as a database-target problem instead of a generic app failure. Start by checking the exact hostname the application is using for its database connection, because migrations often update the database itself but leave one config value or alias still pointing at the previous server.

Symptoms

  • The app still connects to the old database server after migration
  • Recent content or settings changes appear on the wrong environment
  • The migrated site works partly, but data clearly comes from legacy infrastructure
  • Admin tools and app behavior disagree about which database is live
  • The issue started after server migration, app cutover, or database host replacement
  • One configuration test looks correct, but the running app still reaches the old DB host

Common Causes

  • The application config still contains the old database hostname
  • An environment variable overrides the new DB host with a legacy value
  • The database hostname in DNS still resolves to the old server
  • A shared database alias or local hosts override was never updated after migration
  • The application was redeployed, but the runtime config cache still uses the previous host
  • Migration validation focused on database imports and credentials instead of the live connection target

Step-by-Step Fix

  1. Check the exact database hostname the running application is using, because you need the live connection target rather than the value you expect to be active.
  2. Compare that hostname across application config files, environment variables, and deployment settings, because one higher-priority runtime value can silently keep the app pointed at the old database server.
  3. Verify what the database hostname resolves to from the application environment, because DNS or local host overrides can make a correct-looking config still reach legacy infrastructure.
  4. Compare the live application data with the intended destination database, because mismatched records or missing recent changes often reveal that the app is still reading from the previous host.
  5. Check whether the app or platform caches runtime configuration, because a migrated deployment may continue using an older database host until the config cache is rebuilt or the process restarts.
  6. Update the real active hostname source and retest the exact app behavior that exposed the mismatch, because changing only one config file may not fix the runtime path the app actually uses.
  7. Confirm the old DB server stops receiving traffic from the application after the change, because successful page loads do not prove the legacy connection path is gone.
  8. Review related worker, cron, or background-job configs if the app has multiple runtime entry points, because one process can still target the old database after the main web app is fixed.
  9. Document the final database hostname and where it is defined, because DB host aliases are easy to miss during future application migrations.