Refactoring 1.2 Million Lines of Legacy Banking Code: A 90-Day Journey
A Pune-based fintech acquired a 12-year-old core banking software product from a company that was shutting down. The codebase: 1.2 million lines of Java. Documentation: zero. Original engineers: all gone. Their task: understand it, stabilize it, and modernize it for 40,000 active users who could not afford downtime.
The Archaeology Problem at Scale
Sneha Kulkarni was brought in as the engineering lead for the modernization project. She had 4 engineers, a 90-day timeline before the first planned feature addition, and a codebase that had been written by at least 30 different people over 12 years.
The first two weeks were a disaster. Engineers would open a file, trace a function call, land in another file, trace another call, get lost in a chain 12 layers deep, and give up. Nobody had a mental model of the system. Every change felt like defusing a bomb blindfolded.
On day 14, Sneha ran the codebase through ArchSetu.
The Map They Never Had
The call graph was the single most valuable output. For the first time, the team could see the system as a whole. The entry points revealed the actual structure: a transaction processing engine, a reporting subsystem, a notification service, and a configuration management layer. These were not documented anywhere. They were inferred from the call graph in an afternoon.
“In two weeks of trying to read the code, we had built a rough mental model of maybe 15% of the system. The ArchSetu call graph gave us a structural map of 100% of it in 90 seconds. We printed it, put it on the wall, and every discussion happened in front of that graph for the rest of the project.”
Sneha Kulkarni, Engineering Lead
Phase 1: Dead Code Removal (Days 15 to 35)
They started with the dead code. 4,891 functions with zero callers. Using ArchSetu's dead code list grouped by file, they identified 89 files that were entirely dead and deleted them outright. Then they tackled partial files, removing dead functions one cluster at a time, using the blast radius tool to confirm zero impact before each deletion.
After 20 days of dead code removal: the codebase went from 1.2M to 840K lines. The number of functions dropped from 18,402 to 13,511. The build time dropped by 28%. And for the first time, engineers could actually read the code around them without getting lost in code paths that went nowhere.
Phase 2: Complexity Reduction (Days 36 to 70)
The complexity report identified 23 functions with a cyclomatic complexity above 50. These were the real landmines, functions where 12 years of business logic had been layered without any refactoring. The highest was a tax calculation function with complexity 134.
They used a strict rule: one function per sprint, complexity must be below 20 before moving on. No exceptions. Each refactor started with reading the ArchSetu explanation for the function to understand what it was doing before touching it.
The 90-Day Result
On day 90, they shipped the first new feature on the platform: a UPI integration that 40,000 users activated within 48 hours. The feature was built in 6 days with zero production incidents.
“We went from being afraid to change anything to shipping a major integration in a week. The difference was not that the engineers got smarter. The difference was that they could finally see the system they were working in. ArchSetu gave us that visibility.”
Sneha Kulkarni, Engineering Lead
What This Means for Legacy Modernization
Legacy codebases are not fundamentally unsolvable. They are architecturally opaque. Developers cannot fix what they cannot see. Static analysis provides the X-ray. It does not tell you what to do, but it shows you exactly what is there, and that is almost always enough to get started.
Run ArchSetu on your own codebase
Paste a GitHub URL and get your full analysis report in under 60 seconds. Sign up first to save the results, or try it free without an account.
Analyze your repository