Legacy project assessment: deciding whether to maintain or rewrite

When a product has been running reliably in the field for years, no one wants to touch the codebase. Then a key microcontroller reaches end of life, an industry regulation changes, or a critical customer requests a new feature. Suddenly, you’re forced to alter software that hasn’t been compiled in half a decade. While a full rewrite is often commercially simpler for software vendors, it’s not always the option that carries the most value.

Hardware obsolescence regularly catches teams out. When a processor or peripheral — an analogue-to-digital converter, a USB controller — stops being manufactured, code written years ago must be ported to a target it was never designed for.

And external regulatory pressure is compounding the challenge. From 11 September 2026, vulnerability reporting under the EU Cyber Resilience Act (CRA) applies even to products shipped years ago and never modified since. Safety standards are following a similar trajectory: the draft update to IEC 62304 would attach new documentation expectations to medical device software the next time it’s modified.

All of this raises a critical question: can your codebase safely absorb the change, or has it reached the point where starting again is more cost-effective?

That’s not a question that you should answer with assumptions. Instead, we suggest a legacy project assessment, providing the evidence you need to decide.

What is a legacy project assessment?

A legacy project assessment is the systematic analysis of existing software, typically examining code that’s ageing, poorly documented, or inherited from a team that has since moved on. It establishes how much technical debt has built up, how sound the architecture is, and how much room there is to change it.

While it shares similarities with a code audit, it takes a more strategic approach. A code audit looks for defects, vulnerabilities and standards violations in the code as it stands. A legacy project assessment goes further into decision support: assessing whether the change you have in mind is viable and what it might cost before anyone commits to a route.

A legacy project assessment usually takes one of two forms. A light-touch assessment is timeboxed to a single day, giving a fast, high-level view of maintainability and risk. A deep-dive assessment typically takes one to two weeks because the time scales with the codebase’s size and complexity, and with how much existing documentation there is to work from.

Short on time? This video breaks down our legacy project assessment in two minutes, before we get into the details.

What to have ready before a codebase assessment

Two things need to be procured before anyone dives into your codebase: materials to support your current build and the core reason for the update.

The supporting materials come first. Of course, you’ll need to provide the source code, but an assessment gets more complete with the more context that you can provide. This could be existing documentation, whatever unit tests you have, and schematics. For regulated projects, compliance documentation, including the software development plan, is essential for assessing where compliance gaps exist relative to everything else.

Secondly, the reason for the update determines what an assessment covers. A straightforward legacy project — you want to add features to something that already works — gets a standard assessment. Anything else needs an extension, and it’s better to establish that in the brief than to discover it halfway through. These include:

• Obsolescence: estimates for replacing a driver or porting the code to a new processor, and whether that has to happen at the same time as the feature work or can be scheduled separately.
• Compliance: a gap assessment against whichever standards and risk classification apply to the product.
• Performance or reliability: a targeted investigation into a known problem, whether that’s code that’s slow or unresponsive or a protocol that drops out intermittently.
• Cybersecurity: a security review, folded into the same report rather than run as a separate exercise.

Can you assess legacy code without documentation?

Sparse documentation doesn’t prevent an assessment, but it does change what an assessor can tell you. With less to work from, more of the picture has to be built from the code itself, and more of the report carries caveats. Still, we’d recommend starting with what you have rather than waiting for someone to write documentation after the fact.

How to measure the cost of change

During the assessment, you’re often aiming to answer a simple, narrow question: how hard would it be to add features to this code?

That’s not deciding whether the code is good. Anyone can criticise someone else’s code, and it costs nothing. What you need to measure is the effort required to change it safely. A product can run faultlessly for a decade and still be expensive to modify, because the qualities that govern the cost of change are mostly the ones you can’t see from the outside.

During our legacy project assessments, we measure cyclomatic complexity, loop depth, and any existing unit test coverage, using AI tools — with your approval — to surface the areas that deserve closer attention.

What a legacy project assessment report contains

The breadth and depth of reports can vary between providers. For a useful legacy project report, we recommend you ask for two things: a comprehensive picture of code maintainability, and a clear cost comparison between upgrading your existing codebase versus rewriting parts — or all — of it.

How we grade recommendations

While each vendor will use a unique reporting method, our report’s recommendations are graded on a simple traffic-light system, highlighting immediate risks without forcing you to fund unnecessary overhaul work.

Compliance gaps are graded the same way, with severity depending on the standard involved and the risk classification the software falls into.

Deciding which assessment recommendations to prioritise

A report should provide you with clear metrics and a prioritised list of recommendations — but deciding which items to address depends entirely on your product roadmap.

• How much life does the product have left? A green recommendation on something you’re about to retire is money you won’t get back. The same recommendation on a product with years of service ahead changes the calculation entirely.
• Are you already going to be in that part of the code? The cost of tidying something while you’re in there might be a fraction of the cost of coming back to it later, which means the sequencing of feature work changes what’s worth doing alongside it.
• And what’s coming that you should account for now? If a conformity deadline is on the horizon, a green item today — better test coverage, a working update mechanism — becomes a red item when it arrives. Doing it now is often easier and more cost-effective than doing it under deadline pressure.

Sometimes those conversations produce a bigger answer than the report proposed: swapping out a library rather than working around it, replacing a component, or taking a different approach to part of the architecture because the incremental option turns out to cost more over the product’s remaining life than the structural one. None of that is a decision to hand off entirely. It’s about your product and your roadmap, and it’s better worked through as you go, so you end up focusing on the outputs that are actually worth having.

What happens next

If maintaining the codebase is the right decision, the report should become a maintenance plan you can approve and budget for. It needs to set out what requires fixing, in what order, and what each part costs. Once that is in place, you can look at quotes for the new features and start building.

If the evidence points to a rewrite, the same work applies. Knowing what the existing software does is what lets us scope a replacement properly, rather than blindly estimate it.

Why we assess rather than default to a rewrite

Many suppliers won’t quote for anything other than a rewrite of a legacy project. Defaulting to a full rewrite is often commercially simpler for software vendors, but it’s rarely the most valuable choice for product owners.

The comparison that makes rewrites look attractive isn’t a fair one. You’re weighing a codebase whose flaws you can see against a replacement whose flaws haven’t even been written yet. And in discarding the old code, these teams throw away every edge case someone fixed during its lifetime in the field.

We take a more pragmatic view: a rewrite should be an evidence-based conclusion driven by your codebase’s health.