12 May 20267 min read
Ask a cautious buyer what worries them about outsourcing and they will describe quality, or communication, or a project that fails. Those are the recoverable problems. The one that actually traps companies is stranger: the arrangement works, everyone is content, and four years later the work cannot come back because the ability to do it internally no longer exists.
It is worth being clear that this is not a reason to avoid outsourcing. It is a reason to treat reversibility as a design decision that gets made at the beginning, when it costs almost nothing, rather than at the end, when it costs a great deal and you have no leverage.
Why reversibility is the risk question
Every other risk in an outsourcing arrangement has a floor, because you can leave. Bad quality, rising prices, a partner who has stopped caring: all of these are tolerable if the exit is real. Once it is not, every one of them becomes unbounded, and the commercial relationship changes character even if nobody says so out loud.
This is also the axis nobody scores during selection. Buyers compare rates, references, and process maturity. Almost none ask what leaving looks like, and providers do not volunteer it. The question is not adversarial and a good partner will answer it plainly, because a partner confident in the relationship has no reason to depend on the exit being hard.
The four locks
Reversibility is lost in four specific ways, and each has a cheap prevention.
- Knowledge. The reasoning behind the system lives in conversations you were not part of. Nothing is hidden; it simply was never written down, and nobody noticed because the people who knew it were always available.
- Access. Cloud accounts, domains, certificates, app store listings, monitoring and CI all created under the provider's organisation because it was faster on day one.
- Tooling. The work depends on the provider's internal libraries, templates, pipelines or hosting, which are theirs and not yours, and which you cannot run without them.
- Contract. IP assignment that takes effect on final payment rather than continuously, a notice period long enough to be punitive, or no obligation to assist with a transition at all.
The first is the one that gets you, because it accumulates silently and the other three are visible. Knowledge lock does not feel like a problem at any single moment. It only announces itself the week you need to hire, and discover that the job description would have to be written by the people you are replacing.
What to agree at the start
All of this is negotiable before signature and none of it is after. These clauses are not aggressive and a serious provider will not object to them.
- IP assignment that takes effect as work is produced, not on final payment.
- All accounts and infrastructure in your company's name, with provider staff added as users you can remove.
- Source control, CI and issue tracking owned by you, so the history of the work is yours by default.
- A named transition obligation: a defined number of days of knowledge transfer at an agreed rate, available on notice, whatever the reason for ending.
- Disclosure of any provider-owned components in the delivered system, with either a licence that survives the engagement or an agreement not to use them.
- A notice period you can actually afford to serve, and a ramp-down that steps down rather than stopping dead.
The transition clause is the important one. Without it, knowledge transfer happens during a notice period in which the provider has already lost the account and their best people are already on something else. With it, the handover is a paid, scheduled piece of work, which is the only form in which it actually gets done.
Working practices that keep the door open
Contracts set the floor. What preserves reversibility day to day is a handful of habits that are worth having anyway, because they are the same habits that make the work legible.
Decisions get written where you can read them, in your repository, not in the provider's wiki. Architecture is explained to someone internal at the point it is decided, not retrospectively. The build runs somewhere you control, and someone on your side has run it. And at least one person internally can ask the awkward question about each outsourced system, which is a lower bar than being able to do the work and a much higher bar than trusting the answers.
What a planned insourcing actually looks like
When the day comes, and for successful capabilities it often does, the shape is consistent. You hire ahead of the transition rather than after it, because a new employee learning from the outgoing team is worth more than one learning from a repository. You overlap deliberately, with the provider still responsible for delivery while your people take ownership piece by piece. You move the smallest components first and leave the one everybody is afraid of until the new team has confidence.
You also tell the provider early and honestly. A partner told six months out will staff the handover properly and often help you hire, because their reputation is worth more than the last quarter of an account. A partner told at the last minute behaves as anyone would.
The cost of the option, and when to pay it
Reversibility is not free. Documentation takes time, insisting on your own accounts and tooling is slower on day one, and a transition clause has a price. For a genuinely peripheral system that will never come back, that spend is not always justified, and it is reasonable to accept a degree of lock-in in exchange for speed.
But make it a decision rather than a default. The rule of thumb: pay for reversibility wherever the work touches something that compounds, holds customer data, or would be a serious problem to be without for a month. That is a shorter list than everything and a longer list than most companies act on, and getting it right is what makes an outsourcing decision safe to reverse instead of merely easy to make.