A large Indian bank (can’t disclose the name) operating 461 branches, 851 ATMs, and 300 locations needed to move its core banking platform from a legacy stack to next-generation Finacle in a single day, with zero disruption to customers.
Avekshaa’s P-A-S-S™ Assurance methodology identified and resolved performance, availability, and scalability risks before go-live, resulting in a same-day cut-over with zero post-go-live defects.
Migration from Legacy to next-gen Finacle stack across all bank branches and ATMs with one day cut-over and zero post go-live defects across 461 branches and 300 locations.
The big-bang migration approach meant that any missteps, even minor ones, could result in huge ripples in such a critical transition. The disruptions could impact business and brand image, as a consequence result in significant financial losses for the institution.
Big-bang cut-over, no rollback window
All 461 branches and 851 ATMs moved in a single day, no parallel run, no gradual fallback once live.
Multi-vendor stack, no single owner
Legacy and target environments each spanned different vendors, with technical silos between them.
Hard SLA exposure
Missed service-level agreements meant contractual penalties and customer trust damage.
Zero-defect requirement from hour one
No post-launch triage window, banking downtime carries immediate financial and reputational cost.
1. Risk and SLA mapping
Contractual SLAs translated into testable technical parameters, response times, throughput, availability targets across every layer.
2. Stack-wide vulnerability assessment
P-A-S-S™ Assurance methodology applied to review interfaces, code, and customisations at the network, database, storage, application, and integration layers.
3. Bottleneck identification and fixes
- Database layer: 50+ performance improvements at both architecture and query level.
- Web-to-app server communication: thread and memory management tuned for high transaction volume.
- Load simulation: stack-wide testing surfaced issues before go-live, not after.
4. Live monitoring through cut-over
Real-time monitoring during and after the migration window, rather than handing off and waiting for issues to surface.
Why It Matters
Performance and availability risk has to be tested before cut-over, not discovered after, a big-bang migration gives you one shot, with no gradual rollback.
SLA obligations only matter if converted into measurable technical thresholds early. “Maintain uptime” isn’t testable; “response time under X ms at Y concurrent transactions” is.
Database tuning and web-to-app server communication are the two most common failure points in high-transaction banking migrations.
