From 4,000,000 Lines to 409,833: Proving the True Rebuild Scope of a Legacy System

AI/LLM, Discovery phase, Fintech, Modernization

From 4,000,000 Lines to 409,833: Proving the True Rebuild Scope of a Legacy System

This case follows one client project through software archaeology. The client’s documentation said four million lines; measurement found the true size roughly 10x lower. The same stage matters to any CEO or CTO planning a legacy modernization.

Reported vs. actual size

4,000,000 → 409,833 lines

per client documentation and per our team's measurement

Scope reduction

3.6M lines

that our analysts excluded from the rebuild

Documentation gap

how far the same documentation understated the project count

Project overview:

Client

Fintech software

Location

USA

Industry

Fintech

Services

Verified scope & constraint mapping

Architecture-to-code contradiction analysis

Legacy system size measurement & file-level classification

Structural-risk and undocumented-surface assessment

Reverse-engineered software documentation & requirement recovery

Auditable scope-exclusion reporting

Freeze-vs-rebuild decisioning

Target-stack fit scoring

Corsac's six-phase software archaeology pipeline

Solution

Establishes what a legacy system actually is before anyone prices its modernization — measuring the true rebuild scope, mapping structural risk invisible to any line count, and recovering the specification the system never had, through a defensible, auditable process.

Business Challenge

Are You Sure

your legacy system was priced correctly?

Roughly 80% of the legacy modernization projects that reach our team start the same way: a client needs the system modernized, but nobody can price it responsibly until someone knows what it actually is.

This client came to us in exactly that position — documentation in hand, claiming roughly four million lines, looking for a number they could commit to. Once our software archaeology process got underway, it surfaced a very different picture:

The Client's Own Documentation Overstated the System by Nearly 10x

The documentation our team inherited put the system at roughly 4,000,000 lines. That’s simply what happens when a system accumulates dead code, generated files, and duplicated trees for years without anyone separating what’s real from what’s noise.

The Same Documentation Understated the Project Count by 5x — in the Opposite Direction

The same set of documents that overstated total size by 10x understated the number of distinct projects by 5x. Two errors, pulling in opposite directions, sitting in the same sentence. Our team had to catch both — catching only one would have left half the estimate still wrong.

Total Volume Conflated Dead Code with Real Rebuild Scope

Generated files, vendored libraries, frozen tooling, duplicated trees — none of it needed rebuilding, and all of it sat in the same total as the code that did. That’s exactly the kind of gap that pushes an estimate three, five, sometimes ten times past what the system actually needs.

Measuring the System and Pricing It Had Always Been One Job

We build this separation into how our team works, in principle. The moment the person measuring a system is also the person pricing it, the number starts bending toward whatever’s convenient — not out of dishonesty, just because that’s how incentives work on anyone.

Discovery & Planning Phase

Given how much was riding on this number, our team decided early on that a standard assessment would not be enough, so we routed the engagement into our six-phase deep archaeology pipeline instead. Whenever a wrong figure would end up this expensive, we go deeper by default.

From day one, our analysts handled the measurement and our consultants handled the pricing, and we held that separation regardless of how much pressure the deadline put on us.

Every step down from the client’s claimed figure was logged as a named, defensible exclusion rather than treated as a blanket discount, so our analysts could check and defend each line item on its own.

4Our architects signed off at the end of every phase before the next one began, because we never let a phase move forward on work that nobody had reviewed yet.

Facing an estimate you can't fully trust?

Let our team measure the system before anyone prices it.

Arrange a Measurement Review //

Project in Detail: The Six-Phase Deep Archaeology Pipeline

A documented framework gives every engagement the same shape. A deep excavation gives it depth when the stakes require it. Here’s the six-phase pipeline our team ran on this engagement.

Before anything else, we needed to know exactly what we were being asked to price and against which constraints, because a delivery option missed at this stage is an option that never gets costed. Our analysts built a verified input inventory and captured every hard constraint with evidence behind it, so nothing that mattered got left out before pricing began.

Once scope was fixed, we had to establish what the system actually does and whether the documentation agreed with the code, because years of drift usually mean it doesn’t. Our team built as-is and to-be maps, an interface table, and a catalogue of every contradiction between the documents, the interviews, and the source itself.

This is where we answered the question that decides the whole estimate: how much of this genuinely has to be rebuilt. Our analysts measured the true in-scope size module by module, classifying every file as generated, vendored, duplicated, or out of scope, and named each exclusion instead of folding it into a vague discount.

Legacy code alone misleads, because obsolete and duplicated volume hides inside it in both directions. So our team reverse-engineered the specification the system never had, mining it from method names, resource strings, and settings keys, and indexed it as numbered requirements with complexity bands our estimators could attach hours to.

Not every subsystem needs to be rebuilt, but keeping one always carries an ongoing cost, so we made that cost explicit rather than leaving it assumed. Our architects turned every subsystem into a clear freeze-versus-rebuild decision, so the client could see what staying on the old version would keep costing them.

Finally, we had to decide which target technology actually satisfied the requirements we had just recovered, not which one sounded modern. Our team judged every option against the same drivers, marking each one suitable, awkward, or a fail, and handed back a distilled manifest the final estimate was built from.

Reading

Client's own figure

Naive line count

Excludes out-of-scope tier

In the solution

Excludes generated code, tests

Hand-written

Excludes vendored libraries, frozen tooling, duplicated trees

TRUE in-scope

Volume vs. the True Size

4,000,000 lines

9.8x above true

3,011,327 lines

7.3x above true

1,101,574 lines

2.7x above true

933,672 lines

2.3x above true

409,833 lines

he measured, defensible baseline

The Same Discipline, Proven on Two Other Systems

This pattern of over-counting and under-opening shows up often enough that it is worth walking through concretely. Neither of the following examples is from this client. Both come from separate engagements where the same measurement discipline changed the final number.

Classifying a "UI Project" File by File, Not Project by Project

A user-interface project routinely contains a majority of non-interface code. On one engagement, we classified a 47,491-line module file by file instead of trusting a project-level label, and the table below shows what that changed.

Opening a Native Component Instead of Writing It Off

A component that looks platform-locked is often a portable core wearing a platform-specific shell. On another engagement, we opened a 9,892-line C/C++ component layer by layer instead of writing it off unopened, and the table below shows what we found.

UI-module engagement

Scale

47,491 hand-written lines, one module

Naive verdict

100% priced as a UI rewrite, at project level

Archaeology technique

File-by-file classification, interface touch points counted

What it found

65% portable or cheaply decoupled (35% true rewrite); 37%/63% across the full engagement

Verdict

Port or decouple most of it; don’t rewrite it all

Native-component engagement

Scale

9,892 lines (C/C++), one component

Naive verdict

Written off as platform-locked, unopened

Archaeology technique

Layer-by-layer decomposition of the component

What it found

83% portable — a portable core inside a platform-specific shell

Verdict

Port, don’t rebuild — avoided roughly a 5x overcharge

AI agents vs Experts

Deep Research at Machine Scale, Judgment by Our Architects

Speed alone does not make an estimate safe. Here is how we split the work between machines and people, so a fast assessment stays one we can actually stand behind.

What Our Agents Actually Do

Exhaustive, uniform, tireless research across an entire codebase. Classifying tens of thousands of files by the same rule. Recovering every enumeration value by value. Cross-referencing a meeting transcript against a diagram against a line of source.

“What our agents produce is research, not conclusions.”

What Our Architects Do

Every finding goes to our solution architects next. They bring the thing no tool has: domain experience and the judgment to know which finding actually matters. They decide what a contradiction means, which reading of an ambiguous scope is the real one, what’s safe to assume, and what has to be escalated to the client. And they own the number that comes out the other end.

Why It's Fast, and Why That's Safe

Assessment work that would normally take our team one to two weeks gets produced in a fraction of that. But only because the rubrics are fixed in advance, every finding has to cite evidence, and one of our architects reconciles the whole picture before we price anything.

Where We Land on What AI Actually Saves

Where a client lets us use agentic delivery, we band the leverage by work type: highest for repetitive, machine-checkable transformation, close to zero for coordination and customer-owned dependencies. Then we subtract the verification burden it creates, because more code per review-hour still has to be paid for in review.

Our Honest Take

“The realistic net effect is around 20%, not 50%. Anyone claiming AI halives the cost of modernizing a safety-relevant system is selling something.”

Results & Impact

Reliable, auditable measurement replaced a documented estimate that was wrong by nearly 10x in one direction and 5x in the other. Here's what our team delivered:
Project count reconciled after being understated fivefold in the client's own documentation.
A defensible, auditable basis for pricing established before a single hour of rebuild work was estimated.

409,833 lines

proven genuinely in scope — down from a documented claim of 4,000,000

3.6 million lines

excluded from rebuild scope, each exclusion named and reproducible from the repository.

Why We Don't Run the Same Assessment on Every System

Legacy modernization carries more variance than almost any other kind of software work we do. So we built the adaptation rules into the framework itself, rather than leaving them to whoever happens to be running the engagement that week.

System Size

We classify size across seven dimensions instead of a single line count, and when they disagree with each other, we bias toward the larger reading, because underestimating a legacy system costs far more than overestimating one.

Data Complexity

We score data complexity on its own, and wherever the work touches the database, that score overrides the size classification, because database work follows its own cost logic.

Assessment Depth

Depth ranges from a half-day fast-track to a full architecture review depending on what is at stake, and whatever we do not assess gets named explicitly as not assessed, rather than left to disappear quietly.

Engagement Shape

Where a client already has a plan, we narrow our work to validating it instead of rebuilding it from scratch, but we still validate every part of it before anyone commits to it.

Codebase Shape

Systems spread across multiple repositories get a service map, an extra scoring dimension, and coordination multipliers that reflect what stitching those repositories together actually costs.

Start today!

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

Error: Contact form not found.

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