WritingTechnical assessment

What a technical assessment of a legacy system should include

A technical assessment is worth paying for when a decision depends on it: whether to rewrite, what to fix first, how much it will cost. That makes its value easy to judge in advance. It should examine the things that determine the answer, and deliver something a decision can actually be made from.

Written by: Dorian Ben Haim, Principal
Published: September 2026
Reading time: 7 minutes

In short

A useful assessment answers a specific question — why change has become expensive, and what it would cost to fix — rather than cataloguing everything wrong with the code.
It examines the whole path a change travels: the people involved, the code on that path, integrations, data, deployment and operations. A review limited to one layer tends to recommend replacing everything.
It delivers a current-state diagnosis, risks, a target-state recommendation that says what not to change, a sequenced roadmap, a cost and effort model with stated confidence, and an honest scope statement.
Warning signs include a predetermined answer, a vendor behind the recommendation, no stated scope, no costs, and no possibility of recommending less.
Expect weeks rather than days or months: enough to trace real changes through the system, bounded enough to stay a diagnosis.

The purpose

An assessment exists to support a decision

Technical reviews fail in two directions. Some are a two-day skim that produces generic observations — the codebase is complex, test coverage is low, the framework is old. Others expand into open-ended consulting that becomes its own project before it has told anyone anything.

A useful assessment is bounded by a question: is this system worth continuing to invest in, and if so, what exactly should change first? Everything it examines should serve the answer, and everything it delivers should help someone decide.

An assessment that cannot recommend doing less is not an assessment. It is a proposal.

What it examines

What a credible assessment examines

Systems rarely become expensive to change in a single layer, so the investigation has to follow the path a change actually travels:

The people who know: Sessions with engineering leadership, the engineers who work in the system daily, whoever performs releases, and the operations staff who deal with the consequences when something fails. Most of what matters about a legacy system is not written down.
Real changes, traced end to end: Recent changes that took far longer than expected, and the change the business is currently trying to price, followed from request to production to establish where the time and the risk accumulate.
The code on those paths: Deep reading of the components those changes pass through — not a line-by-line audit of everything, which a bounded engagement cannot honestly deliver.
Integrations: How each connection to another system is built, what depends on it, and how its failures are detected. Integrations are where coupling and silent failure concentrate.
Data: Which component owns which data, where it is duplicated, and which constraints the schema imposes on change.
Deployment and operations: How code reaches production, how long that takes, how often it fails, how rollback works, and what the logs show about how the system actually behaves.
Knowledge and ownership: Which parts depend on specific people, and where that concentration materially affects delivery.

What it delivers

What a credible assessment delivers

The output has two audiences. A CTO should find it technically credible enough to argue with; a CEO or CFO should be able to fund or decline the recommendation from it without anything being translated.

A current-state diagnosis: What exists, where change is difficult, and the specific mechanisms that make it so.
Risks and constraints: Architecture, technical debt, integration dependencies, deployment risk, operational bottlenecks and knowledge concentration — ranked by how much they affect the business.
A target-state recommendation: What should change, and explicitly what should be left alone.
A sequenced roadmap: Phases, dependencies and priorities, including what deliberately waits.
A cost and effort model: Ranged estimates with stated confidence, clear about which numbers are plans and which are orders of magnitude.
A scope statement: What was examined, and what was not.
A walkthrough: A live session with leadership on the decision and its cost, and one with engineering on the findings and the design.

The example assessment shows what this looks like in full, for a fictional company.

Warning signs

How to tell a diagnosis from a justification

The answer was known before the work began: If the recommendation matches what the firm sells — a rewrite, a migration, a platform — ask what finding could have changed it.
A product or platform stands behind it: Assessments tied to a vendor tend to find that the vendor’s product is the answer.
No stated scope: Without a statement of what was not examined, there is no way to judge what the conclusions rest on.
No costs, or costs without ranges: A recommendation without an effort model cannot support a funding decision, and a single precise number for a year of work is a guess presented as a plan.
No possibility of doing less: A credible assessment may conclude: do not rewrite this, do not migrate yet, do not buy another platform. If that outcome was never possible, the document is a proposal.
Only its author can act on it: The test of a useful roadmap is whether another competent team could execute it. If it only works in the hands of the firm that wrote it, it is a sales document.

Time and cost

How long it takes, and how it is scoped

Long enough to trace real changes and read the parts of the system that matter; short enough to stay a diagnosis. For a single business-critical system, that is a matter of weeks. An assessment measured in days cannot read enough to be specific, and one measured in months has turned into a different kind of engagement.

A scope, duration and deliverable agreed in advance are what keep it bounded for both sides. For reference, Antegrate’s Technical Systems Assessment takes three weeks, with a fixed scope and no implementation credit: the report is meant to stand on its own.

What any assessment needs from the client: access to the relevant code, database, logs and deployment materials; whatever documentation exists, however incomplete; and a small number of focused sessions with engineering, operations and the business owner of the problem.

When not to

When an assessment is the wrong instrument

The problem is already understood: If the scope is clear and the work simply needs doing, skip the diagnosis and start delivery.
The system is actively failing: Outages or data loss need stabilization first. Diagnosing change cost while production is on fire is the wrong order of operations.
The decision has already been made: An assessment commissioned to validate a decision rather than examine it is an expensive way to hear what you expected — or to be annoyed when it disagrees.
The system is small: If one engineer can explain the whole thing in an afternoon, weeks of external investigation are probably unnecessary.

If the question behind the assessment is whether to rewrite, the reasoning in why rewriting a legacy system is often the wrong first move is a useful place to start.

Questions

Questions and answers

What is a technical assessment of a software system?

A bounded investigation of a system — its code, integrations, data, deployment and the people who work on it — aimed at a specific decision, such as whether to modernize, rewrite or leave it alone, and what to fix first. It ends in a written recommendation with costs.

How is a technical assessment different from a code audit?

A code audit examines code quality line by line. An assessment follows the path changes take through the whole system, including deployment, integrations and operations, to explain why change is expensive and what to do about it. It reads code deeply where that matters, not everywhere.

How long does a technical assessment take?

For a single business-critical system, a matter of weeks: enough to talk to the people involved, trace real changes and read the relevant code, while staying bounded. Antegrate’s Technical Systems Assessment takes three weeks.

How much does a technical assessment cost?

It depends on the scope and depth of the investigation. What matters most is that the scope, duration and deliverable are fixed and agreed before the work starts, so the assessment stays a diagnosis rather than turning into an open-ended engagement.

Should the firm that does the assessment also do the implementation?

It can, but the assessment should not depend on it. A useful test is whether another competent team could execute the roadmap. An assessment fee that is credited against later work suggests the diagnosis was priced as a sales step.

Written by

Dorian Ben Haim leads Antegrate, a principal-led software engineering consultancy for business-critical systems that have become hard to change. About the practice