Migrating a client off self-hosted Postgres

One of the more common jobs we get pulled into isn't glamorous: a client has a self-hosted Postgres instance, usually on a box someone spun up years ago, and it's quietly become load-bearing infrastructure nobody wants to touch.

The migration itself is rarely the hard part. The hard part is everywhere the old connection string has been copy-pasted — deploy scripts, a forgotten cron job, a .env file sitting in three different environments with slightly different values. Every one of those has to be found and rotated, not just updated in the one place someone remembers.

Our usual approach: stand up the managed instance first, run both in parallel behind a feature flag, and mint fresh credentials for every environment rather than reusing the old ones anywhere. It's tempting to just point the old connection string at the new host and call it done — we've learned not to. Stale credentials left behind in an old config file are exactly the kind of thing that outlives the migration that was supposed to retire them.

Once the new instance is verified under real traffic, the old box gets decommissioned outright rather than left running "just in case." A database with no traffic and a login prompt is not a backup plan, it's a liability with a hostname.