1
Agree the scope in writing
We confirm systems in scope, access arrangements, what you will receive and the quote. You approve it before work begins.
Fixed-scope assessment
Legacy code audit: a written assessment and modernization roadmap
A fixed-scope review of your code, data and integrations. You receive a written assessment, a risk list and a phased roadmap you can take to your own team.
- Scope agreed in writing before work starts
- Mutual NDA available before code is shared
- A roadmap your own team can take forward
What is a legacy code audit?
A legacy code audit is a structured, read-only review of a system you are thinking about modernizing. We look at the code, the data it uses, the jobs that run it and the interfaces around it. The output is a document, not a change to your systems.
The aim is to replace guesses with a written picture: what the system contains, where the risk is, which parts are worth moving and which are not. It is the first step in the engagements described on our legacy application modernization page, and it stands on its own if you decide to proceed with your own team or another provider.
What you receive
Every audit is scoped in writing, so the exact list is agreed up front.
-
A written assessment
A plain-language report on structure, condition and risk, with evidence from your code.
-
An inventory and dependency map
Programs, jobs, copybooks, stored procedures, tables and interfaces, and how they connect.
-
Static analysis findings
Complexity hot spots, duplication and dead code, where tooling supports your languages. Where it does not, we review by hand and say so.
-
A risk list
What could go wrong in a migration, how likely it looks and what would reduce it.
-
Options for each component
Retain, wrap, rehost, replatform, refactor, rebuild, replace or retire, with the reasoning.
-
A phased roadmap
A suggested order of work, pilot candidates, rollback points and open decisions.
How the audit runs
2
Sign an NDA and set up access
A mutual NDA comes first if you want one. Access is read-only and runs through your security controls.
3
Collect and scan
We inventory the code and data and run analysis tools on the languages they support.
4
Interview and validate
We talk to the people who run and change the system, and check our findings against how it really behaves.
5
Deliver the report and a readout
You receive the written report and a session to walk through it and answer questions.
What we need from you
An audit is only as good as the access it gets. We usually ask for:
- Read-only access to source code, or an export in an environment you control
- A list of platforms, languages, databases and hosting
- Time with someone who knows the batch schedule and the integrations
- Any existing documentation, even if it is out of date
- A named decision maker for scope questions
- Masked or synthetic data if the review needs sample records
We do not need credentials or production data in the request form. Please do not paste source code or secrets into it.
Limits of an audit
An audit describes your system and recommends options. It does not guarantee a migration outcome, a cost saving or a timeline. Where cost comparison is in scope, it uses figures you supply, because only you know your contracts.
It also does not replace your own security review, and it will not change your code. The honest result may be to leave a component alone. If so, the report says that and explains why.
If a migration follows, see how we approach mainframe modernization, cloud migration and COBOL modernization.
Questions about the audit
- Is the audit free or paid?
The scope and quote are agreed in writing before any work begins, and you approve them. There is no public price list because the effort depends on the size of the system, the languages involved and the access available. Tell us about your system in the form and we will reply with a proposed scope.
- How long does an audit take?
That is part of the written scope. It depends on size, languages, how quickly access is arranged and how available your people are for interviews. We will not quote a duration before we know what is involved, and you see the agreed plan before work begins.
- Do we have to share source code?
Sharing code is part of most audits, but only after the NDA is in place and only in the way your security team allows, usually read-only and inside your environment. Please do not paste source code into the form or into chat.
- Which languages and platforms can you review?
Common enterprise stacks such as COBOL, PL/I, RPG, Java, .NET and PL/SQL, along with the databases and job schedulers around them. Tool coverage varies by language, and the report states where findings come from tools and where they come from manual review.
- What happens after the audit?
You decide. You can proceed with us, with your own team or with another provider, or decide not to modernize at all. The roadmap is written so that someone else could pick it up, and the options analysis explains the reasoning behind each recommendation.
Request a legacy code audit
Four short steps. We reply by email or WhatsApp, and can sign a mutual NDA before you share anything.
Ready to assess your legacy system?
Send the request form or message us on WhatsApp with what the system does and what it runs on.