Skip to content

system assessment

Legacy code audit: a map of the system, ranked risks and a costed plan

Read access to the repository, a few hours with the people who still know it, and our platform over the whole codebase, in whatever it happens to be written: COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#. Back comes a module map, a measured list of dead code, a ranked risk register and a phased plan with prices. Three to five days, and the document is yours whether or not you rewrite anything.

Get a quoteFive fields, no phone number required. What you get is a scope, a price and a date.

3–5 days from access to the finished report


Everything on the right is a document you keep, including the version where the recommendation is to leave the system alone.

Unknown

A source tree of unknown size, jobs nobody documented, no tests.

  • source treeunknown size
  • nobody left who wrote itrisk
  • undocumented jobscron · JCL
  • no testscoverage 0

Mapped

Module map, measured dead code, ranked risks, a plan with phases and prices.

  • module mapgraph
  • dead code listmeasured
  • risk registerranked
  • migration planphased · costed

3–5 days from access to the finished report

Everything on the right is a document you keep, including the version where the recommendation is to leave the system alone.

How the work goes

Two passes over the same system, one by machine and one by a person, then a session where the findings get argued with.
  1. 01day 1

    Access and interviews

    Read access to the repositories, build instructions, job schedules, and two or three hours each with the people who maintain it. Access held up in legal is the most common reason this slips.

  2. 02days 1–3

    Machine pass

    The platform parses everything: call graph, module boundaries, external interfaces, database usage, reachability. Size is rarely the problem. The module written in a dialect nobody supports is.

  3. 03days 3–4

    Human pass

    An engineer works through what the machine flagged and what it could not read, then checks the findings against what your people said. Those two accounts rarely agree on the first pass.

  4. 04days 4–5

    Findings and plan

    A written report and a working session: what is dead, what is dangerous, what a rewrite costs in phases, and what we would do first if it were our system.

What the platform does, what a person does

The machine reads every line and misses the context. The interviews supply the context and miss half the code. The report is what comes out when both have run.
The report is written for your engineers to read first. If it only works as a document for a board, it has failed.
What the platform does, what a person doesWho does itNotes
Parsing and graphing the codebasePlatformEvery language in the tree, including the two you forgot were in there.
Measuring dead codePlatformStatic reachability, plus production traces or logs when you can give us a period of them.
InterviewsEngineerWhat was never written down exists only in conversation, and it leaves with the people who hold it.
Ranking the risksBothThe platform finds the sharp edges. Ranking them needs to know which system costs you money on a Friday.
Estimating the phasesEngineerFrom measured module sizes and coupling, as ranges with the assumptions written next to them.
The recommendationEngineerIncluding 'leave this alone and fix your release process' when that is what the evidence says.

Who reads your code

Engineers with more than ten years on legacy systems and dozens of migrations behind them, plus a platform that parses COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#, Fortran, ABAP and a handful of dialects that only exist inside one company. Between the two of them, very little in a source tree arrives as a surprise.


The audit is fixed-price bounded work and the document is yours either way. Finding out in the last week of a rewrite what a five-day audit would have told you is the expensive version of this.

Questions we get from engineers

Do we have to hire you afterwards?
No, and the plan is written so that your own team or another vendor can execute it. Phases are described in modules and interfaces rather than in our tooling, which is also the only way you can compare quotes.
How much access do you actually need?
Read access to the repositories and instructions for building the thing. If you can add job schedules and a period of production logs, dead code stops being an estimate and becomes a measurement.
What about the parts we have no source for?
They get listed as exactly that: a binary with no source, its interfaces, and what reproducing or replacing it would take. Leaving them out of the map is how migrations blow their budget in the last week.
How long for a large system?
Three to five days covers most of what we see. Above roughly two million lines, or with more than a handful of languages in the tree, we split it and price the first part on its own.
Will you sign an NDA before we send anything?
Yes, before access, as a matter of course. Most of our work starts under one.

Ask for the map of your system

Tell us what the system is, roughly how large, and what is prompting the question now. We reply with the scope for a system that size, a duration and a price.

Get a quote

An engineer replies, and the first message usually contains three questions about access.