The history is noisy
Years of commits, vendored libraries, generated files, and half-finished migrations sit in the same tree. Before anything touches the code, you have to separate the live path from the sediment.
Zero Conjecture · Legacy Systems
Your oldest codebase has the least room for guessing.
You have a ten or fifteen year old .NET, PHP, or Java system that still runs the business. The people who wrote it are gone, the tests are thin, and every upgrade feels like a bet. I help engineering leaders map what the code actually does, put a safety harness around the risky parts, and ship the next change with evidence.
Read-only first. Your code stays on your infrastructure or in an isolated, networkless environment.
The problem
Why generic AI coding tools stall on legacy systems.
Most coding tools are tuned on recent open-source Python and TypeScript. A fifteen-year-old commercial codebase looks nothing like that, and a plausible diff is not the same thing as a safe change.
The intent is in the tickets
Why a module looks strange is rarely in a comment. It is in an old issue tracker, a release note, or a three-commit bug fix from 2014. If you ignore that trail, you reintroduce the bug.
There is no oracle
If a change compiles, nobody knows whether it broke a billing rule or an edge-case workflow. Without a test that fails before the fix and passes after, review falls back on whoever remembers the system best.
What you already own
Your repository and issue history are the asset.
Every bug report, commit message, and multi-commit fix your team has ever shipped is a record of how the system behaves under stress. Most companies treat that history as dead weight. Used carefully, it tells you where the risk sits and what a safe change has to preserve.
Code + issue linkage
Reconstruct what past fixes actually did
Link tickets to the commits that resolved them, strip out post-fix chatter that muddies the problem statement, and identify the modules where small changes repeatedly cause follow-up patches.
Isolated verification
Prove the symptom before trusting the fix
For changes that can run headlessly, build a small check in an isolated virtual machine that reproduces the failure on the old code and passes on the new code across repeat runs.
Engagements
Start with a read-only diagnostic.
You do not need a six-month commitment to find out whether this will help. Each stage produces a standalone deliverable your team keeps.
01 · Two to three weeks
Legacy Risk Review
Read-only archaeology on one repository and its issue history. Separate active source from dead weight, map change hotspots, link historical bugs to the modules they touched, and identify where test coverage is missing.
Deliverable: written risk register, hotspot map, and a ranked list of modernization or stabilization targets with effort and verification paths.
Typical fee: $20,000 to $35,000 fixed.
02 · Six to ten weeks
Bounded Modernization Sprint
Take one target from the review, such as a .NET Framework to .NET 8 module boundary, a fragile PHP or Java subsystem, or a recurring bug class. Put fail-before and pass-after checks around it, make the change, and hand the harness to your team.
Deliverable: merged or ready-to-merge changes, repeatable verification harness, runbook, and walkthrough with the owning engineers.
Typical fee: $60,000 to $120,000 fixed by scope.
03 · Ongoing
Private Regression Harness
Keep the verification tasks running as your team or your vendors ship changes, or use them to evaluate coding tools against your own stack before you buy them. Your code and test cases stay private.
Deliverable: isolated runner configuration, task suite built from your real defect history, and periodic review as the codebase moves.
Scoped after the first sprint.
Where this fits
Built for the stacks public benchmarks ignore.
| Area | What I work with | How we handle boundaries |
|---|---|---|
| Languages and runtimes | C# and .NET Framework / .NET Core, PHP 5/7/8, Java 6/7/8+, classic JavaScript, SQL, C and C++ | We focus automated harnesses on services, libraries, CLI paths, and data layers that can run headlessly. |
| Version control and trackers | Git, Subversion (SVN), Trac, Jira, GitHub, GitLab, and exported ticket archives | Read-only clones or exports. If the history has duplicate mirrors, vendored trees, or binary bloat, we clean that up first. |
| UI-bound legacy code | WinForms, WPF, classic ASP.NET, IIS-coupled modules, older mobile clients | Where a full headless harness is not practical, we isolate the business logic that can be tested and document the manual review boundary for the rest. |
| Security and provenance | Customer-owned repositories and internal issue trackers | Your code is never used to train shared models or sold to third parties. Runs happen on your hardware or in an isolated, networkless VM. |
How we work
Four steps, clear off-ramps.
-
Scope one system
We pick one repository or subsystem and one business problem: an upgrade that keeps slipping, a module nobody wants to touch, or a vendor handoff you need to audit.
-
Read the trail
I inventory the tree, separate source from binaries and vendored code, and link commits to the issues they fixed so we are working from evidence rather than folklore.
-
Build the check before the change
Where the code can run headlessly, we capture the failure mode in an isolated check that fails on the unpatched state and passes when fixed. Where it cannot, we state that plainly.
-
Hand over what we build
Your engineers get the risk register, the harness, and the changes in your own repo and CI. Nothing depends on keeping me in the loop for routine work.
Operator and engineer
Twenty years of commercial software and infrastructure.
I have run a software company, led cloud platform and observability engineering, and worked with enterprise systems going back to the Subversion and early cloud era. You work directly with me, not a junior delivery bench.
Start with one repository
See what your history says before you commit to a rewrite.
Bring the system your team is most nervous to touch. In thirty minutes we can tell whether a two-week Risk Review is worth doing.