Contracts end, teams change, suppliers get replaced. It happens to good relationships as well as bad ones — a framework expires, a service moves in-house, a department reorganises.
The question is never whether a service will change hands. It is how much of its value survives the transfer.
Lock-in is rarely deliberate
It is tempting to assume a supplier who is hard to replace planned it that way. Occasionally true. Far more often it accumulated:
- Infrastructure configured by hand over three years, understood by two people.
- Deployment that works from one engineer’s laptop.
- Documentation that describes the original plan rather than the current system.
- Business rules that exist only in code, with no record of which were policy decisions and which were guesses nobody challenged.
Nobody set out to build a hostage. Everyone was busy, and none of these were the sprint’s priority.
What makes a service transferable
The practices are ordinary and mostly things a good team wants anyway:
Infrastructure as code. If the environment can be rebuilt from a repository, the knowledge is in version control rather than in someone’s head. This is also what makes disaster recovery real rather than a document.
Contract-first APIs. Published, versioned interfaces mean a component can be replaced without renegotiating with everything that touches it.
Documentation aimed at the next team, not at the current one. The useful documents are the ones that explain why: why this rule, why this exception, why this deviates from the pattern. What the code does can be read from the code.
Decision records. A short note per significant decision, kept with the code. This is the single highest-return habit here and takes minutes.
Deployment anyone can run. If releasing requires a specific person, the service already has a dependency nobody has priced.
The reason to insist on it early
Because at handover, the incentives are wrong. The outgoing supplier is winding down with people already assigned elsewhere, and the incoming one is being asked to price work it cannot yet see. Documentation written at that moment is written under time pressure by people who are leaving.
Written throughout, it costs almost nothing and is accurate.
What to ask for in a contract
- Source, infrastructure definitions and pipeline in a repository the buying organisation owns from day one, not delivered at the end.
- Documentation as a continuous deliverable, not a closure milestone.
- A named exit approach reviewed periodically, rather than written when notice is served.
- Data export in a documented format that has been tested at least once.
Our position
Nothing about the way we build assumes we stay. That is partly principle and mostly practical: a team that can hand over cleanly is a team whose service can be understood, which is the same property that makes it maintainable while we are still there.
Procuring a service you will still own in five years? Get in touch, or read about our public sector work.