Phase 2 of the financial data hub we built for a Tier-1 financial institution went into production on September 15. That was six weeks after Phase 1, through the same formal change control: a documented change request, test evidence and independent approval.
Inside a regulated bank, six weeks between production releases isn’t the norm. Here’s what Phase 2 does, what let it move at that pace, and the one testing habit we’d insist on for any migration.
What Phase 2 does
Every user of the application sees a summary of what’s waiting for them: items to approve, review or complete, across more than twenty kinds of action. Today the source system works those counts out at login, which makes it the application’s most expensive screen. Phase 2 computes them in the hub on a refresh cycle and hands them to the application through a single governed view.
That was the “what’s next” when we published our latency measurements in September. Under load testing, a full recompute of every user’s counts runs in under two minutes on the smallest warehouse size. Running the categories in parallel made it slower, because they starved each other on a single node, so the cycle runs them in sequence.
Why it moved at that pace
Nothing about the change process got shorter. What changed is what we brought to it.
- The evidence was built with the code. The change request’s test evidence came out of the same validation suite that tested the work, not a separate write-up afterward.
- The deployment was rehearsed. We tore down and rebuilt the test environment in deployment order, so the production run was a repeat, not a first attempt.
- Performance was measured before approval. A load generator drove sustained change traffic through the new layer in test, so performance was a measured result rather than an open question.
- Its controls shipped with it. New checks joined the hub’s validation framework on day one. They confirm that every category recomputes on schedule and that every count reaches the user it belongs to.
Test against what runs, not what’s written down
The acceptance standard was parity: the hub’s counts must match the legacy logic. The obvious way to test that is against the documented logic you were handed. We tested against the legacy procedure as it actually runs in production.
That caught a difference five days before cutover. The legacy logic had changed after the handover, and the documentation didn’t reflect it. That’s the most ordinary thing in the world. Every organization has logic that moved after someone wrote it down.
The cost wasn’t ordinary. Built strictly to the documentation, one of the counts ran more than 70% high across the user base. The cutover package was already locked for approval, so the correction went in two nights later as a planned step of the same change, before anything downstream read those numbers.
If your migration’s test plan is built from your documentation, ask what it actually compares against. If the answer isn’t production behavior, you’re testing the copy.
What’s next
Next, working with the client’s team, we switch the application to reading from the hub. That’s when we can measure the number we promised in September: how fast that login-time summary is when it reads pre-counted rows. We’ll publish it once we’ve measured it.
Is your next release six weeks away, or six months?
If every production change in your regulated environment turns into a quarter-long project, the process usually isn’t the whole problem. What arrives at it is. Let’s talk.