The connection string still references the old server.<\/b> Config files and environment variables often have the database host hardcoded, either as a hostname or an IP address. If this was not updated during migration, the application keeps trying to reach a server that no longer exists in that location.<\/li>\n<\/ul>\nNote:<\/b> ORM settings<\/b> refer to the configuration parameters used by an Object-Relational Mapper (such as Django ORM, Hibernate, Prisma, or SQLAlchemy) to establish and manage the connection between an object-oriented application and a relational database<\/p>\n\n- The database itself moved to a new VM.<\/b> If the database was migrated separately from the application, or moved to a managed database service, the host value needs to reflect the new location exactly, including the correct port if it is non-standard.<\/li>\n
- Multiple environments getting mixed up.<\/b> It is surprisingly common for a staging config to accidentally get deployed to production, or vice versa, especially when migration scripts are rushed. The application looks like it is failing to connect, when really it is trying to reach a completely different environment.<\/li>\n<\/ul>\n
The fix is straightforward but requires patience: go through every config file, environment variable, Secrets Manager entry, and deployment script that references the database host, and confirm each one points to the correct new address.<\/p>\n
2. Old Private IPs Left in Configuration<\/b><\/h2>\n
This is one of the sneakier issues because it often only shows up after everything else appears to be working.<\/p>\n
When a VM migrates to a new network, subnet, or VPC, its private IP address usually changes. If the application was configured to reach the database using a private IP directly instead of a hostname, that old IP is now pointing at nothing, or worse, at a completely different machine if the old IP range gets reassigned to someone else.<\/p>\n
Common places old private IPs hide include:<\/p>\n
\n- Application configuration files<\/li>\n
- Environment variables baked into container images<\/li>\n
- Cached DNS resolutions on the application server itself<\/li>\n
- Load balancer or connection pooler configs sitting between the app and database<\/li>\n<\/ul>\n
The safest long-term fix is to stop referencing private IPs directly and use internal DNS names instead, so future migrations do not require chasing down IP references across dozens of files. In the short term, a full search across the codebase and configuration for any hardcoded IP addresses is the quickest way to catch what was missed.<\/p>\n
3. Database User Permission Issues<\/b><\/h2>\n
Even when the host and network path are correct, the application can still be blocked because the database user does not have the right permissions in the new environment.<\/p>\n
This shows up in a few common patterns:<\/p>\n
\n- User exists but lacks privileges on the new server.<\/b> Sometimes only the database and its data get migrated, but the user accounts and their grants are not recreated identically, so the application user can log in but cannot actually read or write to the tables it needs.<\/li>\n
- Host-based restrictions on the user account.<\/b> In MySQL and MariaDB especially, a user account is often tied to a specific host or IP range (for example, an account created as appuser@10.0.1.5 rather than appuser@%). After migration, the application server’s new IP does not match what the user account allows, so the connection is rejected even though the password is correct.<\/li>\n
- Missing roles or schema-level grants in PostgreSQL.<\/b> PostgreSQL manages permissions at a more granular level, and it is easy to migrate the data without migrating the same role memberships, schema ownership, or table-level grants, leading to permission denied errors on specific operations even though the connection itself succeeds.<\/li>\n<\/ul>\n
Reviewing user grants explicitly after migration, rather than assuming they carried over, saves a lot of confusing troubleshooting later.<\/p>\n
4. Credential Mismatches<\/b><\/h2>\n
Credentials are another area where small inconsistencies cause big problems.<\/p>\n
Typical causes include:<\/p>\n
\n- Passwords not migrated or rotated during the move.<\/b> If passwords were changed as part of a security review during migration, and the application config was not updated to match, authentication fails even though everything else is configured correctly.<\/li>\n
- Secrets stored in a vault or Secrets Manager pointing to the old environment.<\/b> Many modern setups pull database credentials from a Secrets Manager rather than a static config file. If that secret was not updated, or if the application is still pointing at an old secret path, it will pull outdated or incorrect credentials without any obvious error pointing to the real cause.<\/li>\n
- Encoding or special character issues.<\/b> Passwords containing special characters sometimes get mangled when copied between systems or environment variable formats, especially if quotes, ampersands, or percent signs are involved. The password looks correct at a glance but fails silently during authentication.<\/li>\n<\/ul>\n
Testing the exact credentials being used by the application, rather than assuming a password reset elsewhere was reflected everywhere, is the most reliable way to rule this out.<\/p>\n
\n- \n
Firewall Blocks Between Application and Database<\/b><\/h2>\n<\/li>\n<\/ul>\n
Even with correct hosts, users, and passwords, the connection can still fail if the network layer of our new AWC platform is blocking traffic between the application VM and the database VM.<\/p>\n
Common firewall-related issues after migration include:<\/p>\n
\n- Security Group rules not allowing traffic on the database port.<\/b> In our new platform\u2019s basic zone (or any zone using Security Groups), the database VM’s security group needs an explicit ingress rule allowing traffic on the relevant port (5432 for PostgreSQL, 3306 for MySQL\/MariaDB) from the application VM’s IP or security group. Without this, the AWC platform drops the traffic at the hypervisor level before it even reaches the guest OS.<\/li>\n
- Network ACLs on the isolated network or VPC tier.<\/b> In an advanced zone with VPC, traffic between tiers is governed by ACL lists attached to each tier, not security groups. It’s common to allow the port at the VM’s OS firewall level but forget the corresponding ACL rule on the VPC tier, which silently blocks the connection upstream.<\/li>\n
- Host-based firewalls on the database VM itself.<\/b> Independent of our platform\u2019s own network controls, the guest OS firewall (iptables, firewalld, ufw) needs to allow the same traffic. It’s easy to open the security group or ACL and forget the OS-level rule, or vice versa.<\/li>\n
- The database is not listening on the expected network interface.<\/b> If the database service is bound only to localhost or the loopback interface instead of the VM’s network interface, connections will fail even with every security group, ACL, and OS firewall rule correctly configured.<\/li>\n<\/ul>\n
A quick way to isolate this is to test raw connectivity to the database port directly from the application server, separate from testing the application itself, so it becomes clear whether the problem is network-related or something happening at the database or application layer.<\/p>\n
Access Rules for PostgreSQL, MySQL, and MariaDB<\/b><\/h2>\n
Each database engine layers its own access control on top of general network and permission settings, and migrations tend to quietly break this layer without anyone noticing right away.<\/p>\n
PostgreSQL controls access through pg_hba.conf<\/b>, which defines which hosts, users, and databases can connect and how. After a migration, this file needs to reflect the new application server’s IP or subnet. Miss it, and PostgreSQL will reject the connection outright, but only if someone thinks to check this specific file.<\/p>\n
MySQL and MariaDB tie access rules directly to the user account itself, as mentioned earlier. That splits control between the user table and firewall rules, so both need checking rather than assuming one covers the other.<\/p>\n
Either way, changes to access rules usually require restarting or reloading the database service to take effect, a step that gets skipped more often than it should.<\/p>\n
Confirming the Application’s Connection Actually Works<\/b><\/h2>\n
Once the host, credentials, permissions, and firewall rules look fine on paper, the real test is whether the application holds a stable connection in practice.<\/p>\n
A few things worth checking:<\/b><\/h3>\n
Test the connection independently. Use a database client to connect with the same host, port, username, and password the app uses. This quickly tells you if it’s a network\/credentials issue or something specific to the app itself.<\/p>\n
Check connection pooling. Pooled connections can linger, pointing at the old server if the app wasn’t fully restarted. A full restart, not just a config reload, usually fixes connections that seem stuck.<\/p>\n
Read the exact error in the logs. “Connection refused,” “access denied,” “too many connections,” and “SSL required” each point to a different problem. Reading the wording carefully saves time chasing the wrong cause.<\/p>\n
Monitor active connections at the database level. This shows whether the app is even reaching the database, or failing before it gets that far.<\/p>\n
Working through these checks in order, from basic network reachability up to application behavior, is the fastest way to fix connectivity issues without guessing.<\/p>\n