# Two Hours, Zero Surprises: Retiring End-of-Life Postgres Inside a Bank's Change Window > The bank was running PostgreSQL 9.3, a release that had been end-of-life for years. No more security patches. No more bug fixes. For a regulated financial institution, that is not a technical debt line item, it is an audit finding waiting to happen. # Two Hours, Zero Surprises Retiring End-of-Life Postgres Inside a Bank's Change Window [ Learn More ]() [ Get Support ]() * **Industry:** Trust banking and financial services * **Organization:** The trust-bank subsidiary of a Fortune 500 financial-services company * **Environment:** Self-managed PostgreSQL on Linux, on-premises, two datacenters * **Engagement:** Project-based PostgreSQL consulting * **Services:** Major-version upgrades · Disaster recovery · Streaming replication Outcome --- End-of-life PostgreSQL 9.3 upgraded, executed inside a hard two-hour change window, completed exactly per the approved plan Every command rehearsed on a production clone before the change-approval board ever saw the runbook WAL archiving implemented, closing a disaster-recovery gap we identified proactively Cross-datacenter streaming replication with a cascading standby, which carried the bank through its datacenter move and the retirement of the old primary Three and a half years of work delivered entirely inside the bank's security perimeter Results at a glance ## Get in touch Find out why after almost 3 decades we are still taking the Postgres and Open Source world by storm. [Learn More]() ## The Client A federally chartered trust bank, the subsidiary of a Fortune 500 title-insurance and financial-services company. Its PostgreSQL databases sit behind the daily movement of client funds, which means every change to them answers to bank-grade change control: a change-approval board, scheduled maintenance windows, and an audit trail for everything. ## The Challenge The bank was running PostgreSQL 9.3, a release that had been end-of-life for years. No more security patches. No more bug fixes. For a regulated financial institution, that is not a technical debt line item, it is an audit finding waiting to happen. The obvious fix was not obvious to execute. The change-approval board would grant a hard two-hour window, on a Saturday morning, with a one-hour buffer before the production team needed the system back. There would be no second attempt that day. And all of it had to happen inside the bank's security perimeter: VPN, jump servers, and dedicated laptops the bank shipped to our engineers, locked down with no administrative rights, before we could touch a single server. Two hours is not much time to jump a database several major versions. Unless nothing about those two hours is a surprise. ## The Solution The bank stood up a copy of the production server, and we refreshed it from production itself so the rehearsal environment matched the real thing. Then we rehearsed. We installed the new PostgreSQL version, ported the configuration, and turned the entire upgrade into scripts: one to initialize the new cluster, one to run pg_upgrade, with a dry-run check mode that validates compatibility without changing anything. We ran the procedure on the clone, found the surprises there, and fixed the scripts until there were none left. Only then did we write the production runbook: a numbered plan where every step named its owner. The bank's team would stop the applications and snapshot the VM. Our engineer would receive temporary root access for the window, run the dry-run check, run the upgrade, and hand the system back for the bank's own testing. The bank took that plan through its change-approval board and got the window approved. On the scheduled Saturday morning, our engineer executed the plan. The upgrade completed inside the window, according to plan, and the ticket closed two days later with nothing left to say. The relationship did not stop there. We identified that the cluster was not archiving WAL, a gap that put disaster recovery at risk, and implemented archiving the same way: tested first, then walked through production step by step with the bank's administrator confirming each one. We built streaming replication from the primary to a second datacenter, with a cascading standby behind it. That replication carried the bank's databases through its datacenter move, and the old primary was retired a month later. ## Why it Matters Regulated environments do not reward heroics. They reward procedures that survive a change-approval board and finish inside the window, every time. In a shop like that, the deliverable is not the upgrade. It is the certainty. A rehearsed runbook is certainty you can schedule. --- [View this page online](https://www.commandprompt.com/about/success-stories-case-studies/two-hours-zero-surprises-retiring-end-of-life-postgres-inside-a-banks-change-window/)