4,000,000 Lines on Paper, 409,833 in Scope: How Software Archaeology Produced a Defensible Modernization Budget

AI/LLM, Discovery phase, Fintech, Modernization

4,000,000 Lines on Paper, 409,833 in Scope: How Software Archaeology Produced a Defensible Modernization Budget

A fintech software company in the USA needed a modernization budget it could commit to, and its documentation described a system of 4M lines. Our software archaeology process measured 409,833 lines that genuinely had to be rebuilt and tied every exclusion along the way to files in the repository, so the scope behind the estimate can stand up to the board and to technical due diligence.

Documented vs. measured size

4,000,000 → 409,833 lines

per the client’s documentation and per our team’s measurement of the repository

Taken off the documented figure

3.6M lines

2.6M as named exclusions, the rest a gap between the documentation and the repository’s own count

Projects the documentation missed

more distinct projects in the repository than the documentation listed

Project overview:

Client

Fintech software company

Location

USA

Industry

Fintech

Services

Legacy system size measurement and file-level classification

Architecture-to-code contradiction analysis

Reverse-engineered documentation and requirement recovery

Freeze-vs-rebuild decisioning

Target-stack fit scoring

Auditable scope-exclusion reporting

Solution

A measured rebuild scope of 409,833 lines, established before a single hour was estimated. Every exclusion from the repository count is named and reproducible, and the specification the system never had was recovered as numbered requirements the estimate could attach hours to.

Business Challenge

A budget built on the client's documentation

would have failed its first technical review

The client needed a figure they could commit to and present internally. The only description of the system was its documentation, which recorded the system as people had once described it, while the repository held the system as it runs.

Our analysts compared the two and found three problems.

The documentation overstated the system by nearly 10x

The documents put the system at roughly 4,000,000 lines. Years of dead code, generated files, vendored libraries, and duplicated source trees sat in that total next to the code that runs the business, and nobody had separated the two.

The same documents understated the number of projects fivefold

In the opposite direction, the documentation listed one fifth of the distinct projects the repository contained. Each missing project carried its own build, dependencies, and integration points, so correcting the size alone would have left a second error inside the estimate.

Either error would have surfaced in front of the people who approve the budget

An estimate priced from four million lines charges for millions of lines that never needed rebuilding. An estimate that misses four-fifths of the projects hides work that appears only during delivery. A due-diligence reviewer finds the first problem, the delivery team finds the second around month three, and both land on whoever signed off on the number.

Discovery & Planning: why we chose depth before speed on this system

With this much of the budget riding on one figure, a standard assessment would not have been enough. We routed the engagement into our six-phase deep archaeology pipeline, which we use whenever a wrong number would be commercially expensive.

Our analysts measured the system, and our consultants priced it, and the two roles stayed separate for the whole engagement, deadline pressure included. If one person measures and prices, the measurement drifts toward the number everyone hopes to see.

Our analysts recorded every step down from the repository count as a named exclusion with its reason and file paths, so anyone can check a line item on its own and reproduce it from the repository.

A solution architect signed off at the end of every phase, and no phase started on findings that had not yet been reviewed.

Facing an estimate you can't fully trust?

We’ll measure your system before anyone prices it, so every figure you present traces back to source.

Arrange a Measurement Review //

Project in Detail: how the six-phase archaeology pipeline built a scope the client could defend

Each phase answered one question the estimate depended on and closed with an architect’s sign-off.

We started by confirming what was being priced and under which constraints, because a delivery option missed at this stage never gets costed. Our analysts built a verified inventory of inputs and recorded each hard constraint with the evidence behind it.

Our team mapped the system as it stood and as it needed to become, built an interface table, and catalogued every contradiction between the documentation, stakeholder interviews, and the source code.

This phase determined the estimate. Our analysts measured in-scope size module by module and classified every file as hand-written, generated, vendored, duplicated, or out of scope, naming each exclusion and tying it to its file paths. The five readings below show the result.

Scope is measured in lines, but effort follows requirements, because obsolete and duplicated code distorts a line count in both directions. Our team reverse-engineered the specification the system never had from method names, resource strings, and settings keys, and indexed it as numbered requirements with complexity bands that hours could attach to.

Our architects turned every subsystem into an explicit freeze-or-rebuild decision and attached the ongoing compatibility cost to each freeze, so the client could see what keeping an old component would keep costing.

Our team judged each target technology against the same drivers, taken from the recovered requirements, and marked it suitable, awkward, or failing. The distilled manifest from this phase is what the final estimate was built from.

Five readings of one system: how 4,000,000 lines became 409,833

Each reading removes one named category of code, and each removal can be reproduced from the repository. The multiplier shows how far that reading sits above the true rebuild scope.

What each count shows

4,000,000 lines

Client’s documented figure, 9.8x above the true scope

3,011,327 lines

Raw repository count, 7.3x above the true scope

1,101,574 lines

Code in the solution, 2.7x above the true scope

933,672 lines

Hand-written code, 2.3x above the true scope

409,833 lines

True rebuild scope, the baseline behind the estimate

What we excluded next

988,673 lines not in the repository

Gap between the documentation and the repository’s own count

1,909,753 lines excluded

Generated code and tests

167,902 lines excluded

Vendored libraries, frozen tooling, duplicated trees

523,839 lines excluded

The out-of-scope tier

2,601,494 lines excluded in total

Each exclusion named and reproducible from the repository

AI agents vs Experts

Our agents researched the codebase, and our architects own the number

Classifying every file of a system this size by hand would take weeks, and consistency would slip long before the end. We split the work so that machines supplied the speed and people kept the accountability.

What our agents did on this system

They applied one classification rule to every file in the repository, recovered enumerations value by value, and cross-referenced meeting transcripts against diagrams and source. Everything they produced was evidence with a file reference, passed on for review.

What our architects decided

Our solution architects decided what each contradiction meant, which reading of an ambiguous scope was the real one, what was safe to assume, and what had to go back to the client as a question. They own the 409,833 figure.

Why the speed did not cost accuracy

Assessment work that usually takes our team one to two weeks was produced in a fraction of that time. It stayed reliable because the classification rubrics were fixed before research began, every finding had to cite its evidence, and an architect reconciled the whole picture before anything was priced.

“For us, AI does not replace engineering judgment. It gives our engineers better information to make their judgment.”

Igor Omelianchuk, CEO, Corsac Technologies

Results & Impact: a modernization budget built on a scope the client can defend

The client replaced a documented figure that was wrong in two directions with a measured rebuild scope of 409,833 lines, broken down by module and classified file by file.
Our analysts reconciled the project count, five times higher than documented, before estimation, so the work in the missing projects sits in the budget from the start.
Every exclusion is named and reproducible from the repository, which gives the client a file-level answer to any line item a board member or due-diligence reviewer challenges.

409,833 lines

measured rebuild scope, the basis of the final estimate

2.6M lines

removed as named exclusions, each reproducible from the repository

Start today!

We’d love to hear from you. Share your vision, and let’s explore how we can make it real together.

Our team will

1 Process your request within 1-2 business days.
2 Get back to you with an offer based on your project's scope and requirements.
3 Set a call to discuss your future project in details and finalize the offer.
4 Sign a contract with you to start working on your project.

Corsac Technologies Corporation

+1 416 505 4524 Toronto, Canada info@corsactech.com