Three months ago, an NBFC client walked into our offices with a problem that keeps a lot of BFSI CTOs up at night: a 12-year-old loan management system running on on-premise servers, held together by patches, cron jobs, and one retiring sysadmin who understood all of it. They needed to move to the cloud. They needed it done in a quarter. And they could not afford a single hour of downtime because the system processed EMI collections for over 40,000 active borrowers every single day.
This is the story of how our team at Speqto Technologies pulled that off — not as a theoretical case study, but as a walkthrough of what actually happened, including the parts that went sideways.
Why “lift and shift” was never on the table
The client’s first instinct, like most first instincts, was “just move the servers to AWS.” We pushed back. Their core application was a monolithic Java system tightly coupled to an Oracle database with custom stored procedures running business-critical interest calculations. Lifting that as-is would have meant carrying over the same fragility, just on someone else’s hardware — plus a much bigger cloud bill.
Instead, we proposed a strangler fig approach: build new cloud-native services around the legacy core, route traffic incrementally, and retire legacy components piece by piece. Riskier to plan, far safer to execute.
Week 1-3: Mapping before moving
We didn’t write a line of migration code for the first three weeks. Instead, we did something most migration vendors skip because it doesn’t look like progress to the client: we mapped every dependency.
- Documented all 34 batch jobs, including three that nobody on the client’s current team had touched in over a year
- Identified RBI data residency requirements that dictated which workloads could sit in which AWS Mumbai availability zone
- Built a dependency graph showing which modules touched the core ledger database directly versus through APIs
This phase found us two “ghost integrations” — a collections agency portal and an SMS gateway — that pulled data directly from the production database with no documentation anywhere. Missing these would have caused a silent failure in week 8, not a visible one in week 1.
Week 4-8: Building the parallel path
We stood up the new environment on AWS using ECS for the application layer and Aurora PostgreSQL for the database, with AWS DMS handling continuous replication from the Oracle source. The key decision here: we ran both systems in parallel, writing to both databases, for nearly five weeks before cutover.
For the EMI collection module specifically — the highest-risk piece — we used a dual-write pattern with reconciliation jobs running every 15 minutes comparing record counts and checksums between old and new systems. When discrepancies showed up (and they did, 11 times across the five weeks), we treated each one as a mandatory root-cause investigation before moving forward. Most were timezone handling bugs in the new code, not infrastructure issues.
Week 9-11: The cutover nobody noticed
Actual cutover happened module by module using weighted DNS routing and feature flags, not a single big-bang switch. We moved the customer-facing loan application portal first (lowest risk, highest visibility for quick wins), then the back-office collections dashboard, and the core ledger engine last.
For the ledger engine cutover — the one that genuinely worried the client’s compliance team — we scheduled it for a Sunday at 2 AM, not because we needed a maintenance window, but because we wanted the lowest possible transaction volume while we watched the dashboards for the first hour. Traffic routing shifted gradually: 5%, 25%, 50%, 100% over six hours, with automatic rollback triggers wired to error rate thresholds.
Zero downtime didn’t mean zero risk. It meant every risky step had a rollback path that took under 90 seconds to execute.
Week 12: Decommission and handover
The last week was unglamorous but important: decommissioning legacy servers, closing out the dual-write reconciliation process, and handing over runbooks. We also ran a full DR drill in the new environment before signing off — something the legacy system had never had, honestly.
What actually made the 90-day timeline possible
- No code freeze demand on the client — their product team kept shipping minor features during migration, which forced our architecture to be resilient to change, not just a one-time snapshot
- A dedicated compliance liaison embedded in our team from day one, since RBI reporting formats couldn’t be touched without sign-off
- Daily 15-minute syncs, not weekly status reports — in a project with this many moving dependencies, a two-day information lag is how small issues become outages
The numbers that mattered to the client
Post-migration, infrastructure costs dropped by 34% due to right-sized auto-scaling versus the old fixed-capacity servers. Batch processing time for EOD interest calculations fell from 3 hours to 42 minutes. And across the entire 90 days, including the ledger cutover, recorded customer-facing downtime was exactly zero minutes.
If there’s one thing worth taking away from this, it’s that zero downtime isn’t a feature you build at the end — it’s a constraint you design around from day one. For BFSI and fintech platforms where every transaction has a paper trail and a regulator watching, that discipline isn’t optional. It’s the whole project.
