legacy fintech deployment

the problem

a digital wallet with 1,500 active accounts, real money and an audit by a public body needed seven new features. what i inherited: no staging (staging was production), code delivered as folders with no git history, a web app built from a repo the client could not access, docs claiming one framework version while production ran another (two majors newer, because dependencies were unpinned), and a discontinued container platform where a deleted service could not be recreated.

the build

i rebuilt the entire system locally against real volume: 1,500 accounts, the same total money, 131,000 transactions. i rehearsed the full deployment four times, each rehearsal verifying that the old version worked as in production, that the database migrations applied without moving money, and that the old version still worked against the migrated database, which makes rollback safe in seconds. one rehearsal caught a real bug: the old version could not create users against the migrated schema, so i wrote a targeted migration and re-rehearsed. before starting i defined the truth metric: total money, account count, held balance, transaction count and last-transaction timestamp, measured minutes before and after. i left three verified rollback paths (database copies, previous service versions tagged server-side, a downloaded web artifact), none depending on my laptop.

the result

zero money moved. 11 seconds of downtime per service. 5 migrations without errors. the truth metric came back identical to the microsecond, the served files matched the locally-built artifact by cryptographic hash, and there were zero rollbacks. the client also received their own repos with history and secret scanning, a 31-finding report ordered by severity, a documented and tested deployment procedure, and six security fixes already live, including an unauthenticated page and an export that leaked the whole customer registry in one call.