Run · Handover
“The one person who understood our systems has gone.”
The software still runs. What left is the ability to change it, and that stays invisible until the first thing that has to change.
What is actually going on
For a while nothing happens, which is the dangerous part. Traffic gets served, everyone concludes the risk was theoretical. Then a payment provider deprecates an API, or a certificate expires, or a customer asks for something small, and it turns out nobody can safely touch it.
What's missing is rarely the code. It's the reasoning. Why the data model is shaped like that, which environment variable is load-bearing, what the 4am cron job is for, which deploy quietly breaks things on a Friday. That lived in someone's head and was never a deliverable.
The obvious next move often makes it worse. A new developer is hired, spends three months orienting, concludes it should be rewritten, because everyone concludes that. Now there are two systems.
What we do about it
We take it on, write down how it really works, and keep it running.
-
We take it on and read it properly
Run it, trace it, map what talks to what. The output is a written picture of the system as it is, rather than as somebody once meant it to be.
-
The knowledge becomes a thing you own
Architecture, decisions, environments and the fragile parts, written down and kept current. It stops living in one person.
-
We stabilise before improving
Access, backups, certificates, deploys nobody can reproduce. Improvements come once the thing can be safely changed.
-
Then it is watched and maintained
It keeps running, it keeps changing, and the knowledge does not walk out again.
Where we have done this
Picking up systems somebody else built, with no documentation and no original team, is ordinary work for us rather than an exception.
See the case studies →Questions
What people ask next.
There is no documentation and no handover. Is that a problem?
It's the normal starting point. We work out how it behaves by running and reading it, then write down what we find so the next gap is smaller.
Will you insist on rewriting it?
No. A rewrite is a recommendation we make when finishing genuinely costs more, not the default position of everyone who inherits somebody else's code.
Can you just keep it alive while we decide?
Yes. Stabilising and watching it is the first job. The decisions get easier once it is not one incident away from a crisis.
Also in Run
It's live, and nobody is watching it.
“Something broke overnight and we heard about it from customers.”
Every log line watched around the clock, with the incident staffed before your users notice.
How we handle it Stagnation“We've been live two years and nothing's changed since launch.”
A team that keeps shipping after launch, on one monthly number.
How we handle itKeep exploring