Making a Legacy System With No Test Coverage Safe to Change
A business-critical legacy system with no automated tests, no original developers, and stale documentation had pushed the team into avoidance — changes batched, deferred, and kept as small as possible, because every change carried unknown blast radius. That is a rational response to an untested system, and it compounds. Envion’s QA lead scoped coverage to the paths where failure was unacceptable rather than merely unwelcome: characterization tests captured what the system currently does — including behaviour that looked wrong — and became the regression baseline. Behaviour questions were raised to the business, not silently fixed. Release criteria for the high-risk system were stricter than for a greenfield product, deliberately. The team stopped batching changes because a safety net in CI made every unintended difference visible immediately.
The challenge
No automated tests. Original developers gone. Documentation absent or stale. The team's working practice was avoidance: changes were batched, deferred, and made as small as possible, because every change carried unknown blast radius. That is a rational response to an untested system, and it compounds — the longer changes are deferred, the larger and riskier each eventual release becomes.
They were not afraid of the code. They were afraid of not knowing what the code did. Those feel the same from the inside but they have completely different solutions — and the second one you can fix without a rewrite.
Decision path
A full test suite for a legacy system of this size was not fundable and would not have been the right spend anyway. Coverage was scoped to the paths where failure was unacceptable rather than merely unwelcome.
The work traced the money and the data — every path that touched billing calculations or customer records got coverage first, because a wrong invoice is a customer relationship and a compliance question, not a bug ticket. Change-frequency analysis from version control history found where the team actually needed to work. And the large parts of the system that were stable, untouched, and low-consequence were deliberately excluded — coverage there would have cost budget and produced maintenance liability with no risk reduction.
You do not need to understand the whole legacy system. You need to understand the parts you are about to change and the parts that will hurt if they break. Those two sets are usually much smaller than the codebase, and confusing "test everything" with "test the right things" is how legacy testing projects die.
Envion contribution
Characterization tests came first: not tests of what the system should do — nobody knew — but tests that captured what it currently does, including behaviour that looked wrong. Those became the regression baseline; anything that changed under a code change became visible immediately.
Behaviour questions were raised, not silently fixed. Cases where the captured behaviour appeared incorrect were logged and taken to the business — several turned out to be deliberate and undocumented, and correcting them unilaterally would have broken downstream consumers who had adapted to them. A regression safety net went into CI so the team could stop batching changes, and targeted exploratory sessions ran around each change, charter-scoped to the affected area and its integrations.
Delivery
Release criteria here were stricter than for a greenfield product, and deliberately so: the characterization suite green with zero unexplained differences, parallel-run output comparison for calculation changes, an exploratory charter completed on the changed area and its integration points, and a documented rollback verified rather than assumed.
In a legacy system the first job is not to fix the behaviour — it is to freeze it. Write down what it does today, get that green, and then you have a baseline. Change anything before that and you cannot tell your improvement apart from your regression.
Outcome and evidence
Releases moved from batched, deferred, and anxious to smaller and more frequent, with the characterization suite catching unintended differences before they shipped. Outcome instrumentation — release frequency, average change size, production incidents from releases, characterization coverage on critical paths, and undocumented behaviours surfaced and confirmed with the business — is tracked by the client's team rather than asserted here.
The toolkit
The toolkit this practice runs on
Tool choice follows the risk model, not the other way round — the stack for each engagement is selected after the risk map exists, not before.
From the engagement lead
What I’d tell anyone considering this
“In a legacy system the first job is not to fix the behaviour, it is to freeze it. Write down what it does today, get that green, and then you have a baseline. Change anything before that and you cannot tell your improvement apart from your regression.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
A system nobody wants to touch, with releases that keep getting bigger and scarier? Envion freezes the behaviour, maps the risk, and makes change safe — no rewrite required.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.