Legacy · safer releases
Legacy code & cleanup
Deploys should be boring. Ours aim for that.
01
The situation
Deploys feel risky every time. Change is slow, outages sting, and too much knowledge sits in one person's head — so every ticket is a negotiation and every Friday has a quiet prayer.
The code is not cursed. It is unmaintained, under-tested, and owned by habit. Patches stack on patches until nobody can say which shortcut is load-bearing and which is folklore.
Teams often live in two modes: freeze everything, or hotfix in panic. Neither is a strategy — both are expensive.
02
What you get
Risk trimmed with small, safe releases; structure and deploy discipline improved; we say outright when a controlled rewrite beats death-by-a-thousand patches.
You get a release path someone else can run, monitoring on what actually breaks customers, and documentation that survives the next hire — not a stealth rewrite dressed up as cleanup.
When a controlled rewrite is the honest answer, we scope it like adults: phased, with a line between what ships and what gets cut.
03
Cleanup work
- Release and rollback path you can run on a Tuesday — not only when the hero is in
- Tests and monitoring on the flows that actually break customers and margin
- Incremental refactors with visible checkpoints — not a stealth rewrite
- Dependency and security hygiene proportionate to exposure
- Runbooks and architecture notes for the next person who inherits it
- Clear call on patch vs replace — with numbers, not vibes
→
How legacy cleanup runs
Small slices — confidence per release, not a six-month rewrite in hiding.
Step 1 Start safe
Map blast radius
What must not break this month — revenue, compliance, customer paths — before anyone edits a line.
Step 2 Boring deploys
Release discipline
Rollback you trust, deploy path someone else can run on a Tuesday — not only when the hero is in.
Step 3 Prove it
Tests on scary paths
Monitoring and coverage on flows that break customers and margin — incremental refactors with visible checkpoints.
Step 4 Out loud
Patch vs rewrite call
Evidence-based decision with numbers — phased rewrite if honest, or disciplined patching if that is the grown-up answer.
Legacy is not a moral failing. Hero-dependent systems are.
04
Signs this might be you
- Nobody wants to touch production except one person — and they are tired
- Rollback is a story, not a button you trust
- Incidents repeat with different symptoms but the same root cause
- The board asks for features; engineering asks for a rewrite — nobody aligns on risk
- Staging never matches prod and everyone knows it
- You are paying for shelfware because the old system cannot be changed safely
05
How we approach legacy without denial
We start with what must not break this month — revenue, compliance, customer-facing paths — and map blast radius before anyone edits a line.
Small slices ship first: logging, deploy discipline, tests on the scary paths, then structure where it earns its keep. The goal is confidence per release, not a six-month rewrite in hiding.
06
Patch culture vs controlled rewrite
Death-by-a-thousand-patches is real — but so is rewrite fantasy. We name which side you are on with evidence: cost of change, incident history, and who can maintain what you have.
If rewrite is honest, we phase it so you are not betting the company on a single go-live.
→
Good fit when
- You have revenue on the system and cannot afford a big-bang replacement
- Leadership will fund incremental improvement, not only hero projects
- Someone inside will own the system after we step back
×
Probably not when
- You want a rewrite quote without stabilising what is live
- Nobody will grant access, logs, or time with the person who knows the shortcuts
- The real problem is process — and nobody will name an owner