Legacy Rescue
Systems nobody wants to touch, made safe to change again. Usually eight years old, business critical, understood by one person, and carrying a rewrite proposal that has been declined three times for good reasons.
We take the risk off the codebase.
The job is to move a system from one nobody dares touch to one anybody can. Operations stay with you throughout, because the point is that nothing breaks while we work.
The rewrite is almost never the cheapest option.
A working legacy system encodes years of decisions nobody wrote down. Rewriting throws all of it away and discovers the important parts one outage at a time. We would rather make the existing thing safe to change and then change it.
Two weeks of reading, no commits
Understanding why it does what it does, including the parts that look wrong and are not. Changing code you do not understand is how rescues become outages.
Tests around the risk, not everywhere
Characterisation tests on the behaviour the business depends on. Not full coverage, which would cost more than the system is worth.
Strangle rather than replace
New code takes over one module at a time, with both paths live until the old one is cold. No date on which everything changes.
The last engineer is interviewed, not replaced
The person who knows the system is an asset. We get what is in their head written down while they are still there.
Three ways to work with us. This is one.
Same bench, different shape. Pick the wrong one and you pay for coordination you did not need.
Sometimes the honest answer is to leave it alone.
Good fit
- Changes take weeks because nobody is sure what they will break.
- One person understands it and they are leaving.
- A rewrite has been proposed and keeps being declined.
- It runs on something that is going out of support.
Poor fit
- The system is genuinely finished and never needs changing. Leave it.
- You want a rewrite decided before anyone has read the code.
- The business process it encodes is itself being retired.
Before you book the call.
Usually not, and anyone who says yes in the first ten minutes has not read it. Rewrites discard undocumented behaviour that turns out to matter, and they run long precisely because nobody knew what was in there. We will say when a rewrite is right, and it is rarer than the industry pretends.
That is the normal starting position. We add characterisation tests that lock in what it currently does, including the bugs, so that any change becomes visible. Correctness comes after safety.
Usually. .NET Framework, older PHP, classic Java and legacy database platforms are routine. Tell us what it is on the first call and we will be straight about whether we have someone genuinely strong in it.
No. A restored copy and read access to logs is almost always enough, and we would rather not hold credentials to a system we are still learning.
Tell us what nobody wants to touch.
Thirty minutes. Occasionally the right answer is that this system is fine and the money belongs somewhere else, and we would rather say that early.