Legacy code isn't bad code — it's code that outlived the context it was written for. The business runs on it, nobody fully understands it, and every change is a small act of courage. We refactor and modernize such systems without the big-bang rewrite that takes a year and delivers nothing.
How we approach it
- Audit first — we map what's actually there: dependencies, dead code, security issues, the parts everyone is afraid to touch.
- Characterization tests — before changing anything, we write tests that capture what the code does today, bugs included. Behavior is pinned down before it's changed.
- Incremental replacement — the strangler pattern: new features go to new code, hot paths migrate module by module, the old system shrinks until it can be retired.
The strangler approach
public function test_invoice_rounding_is_pinned(): void
{
$legacy = new LegacyInvoiceCalculator();
// Characterization test: pins current behaviour, quirks included.
$this->assertSame(1049.99, $legacy->total($this->fixtureOrder()));
}Before touching legacy code we pin its behaviour with characterization tests — even the quirks. Refactoring may change the inside, never the observed output.
Old and new run side by side against the same database. Routing decides which feature goes where. There's never a point where the business waits for a rewrite to finish — value ships continuously.
What we typically find
PHP 5-era codebases, framework-less spaghetti, abandoned Symfony 2/3 apps, WordPress sites held together by sixty plugins. Common wins: upgrading to a supported PHP version, extracting a framework around existing code, replacing the worst queries, and putting deployments on rails so changes stop being scary.
If you have a system that works but nobody dares change — that's exactly the project shape we handle. Show us the code and we'll tell you what's worth keeping.