A risk nobody documents
Every supplier relationship carries a risk that is acknowledged in the abstract and written down nowhere. Asked whether your platform would survive an unplanned supplier change, you would probably say yes, because the code is yours and the contract says so. Asked where the repositories are hosted, who pays for the cloud account, and who holds the admin login for the search service, you would slow down.
It stays undocumented because asking feels like an accusation. Raising continuity with a supplier who is delivering well sounds as if you expect them not to be there next year, so the questions wait for a trigger. By the time there is one, the people who could answer are distracted or gone.
Treat it as insurance rather than suspicion. You insure the office without expecting it to burn down. Everyone's supplier is stable until it is not.
What you actually stand to lose
The instinctive fear is the source code. In practice that is the most recoverable part. It sits in a repository, it can be exported in an afternoon, and the contract usually says it is yours. Everything around it is harder.
Decisions. A long build produces hundreds of choices: why the product model has that shape, why one integration polls and another listens, why a field that looks redundant is still there. Each was settled in a ticket or a call, and the record lives in the supplier's tooling.
Environments. Staging, preview and production differ in small ways nobody wrote down. Secrets, feature flags, scheduled jobs and the one manual step in the deployment live in the heads of the engineers who set them up.
Access. Accounts accumulate: hosting, DNS, content system, search, email delivery, monitoring, payments, analytics. Some are in your name, some in the supplier's, some under an engineer's personal login. Nobody has the full list.
History. The ticket backlog is the only record of what was asked for, what was declined and why. In a regulated sector it is also part of your evidence.
Code is recovered in days. Context, when it is recovered at all, takes far longer.
Where ownership sits, and how to check this week
You can establish most of this in a week, without a difficult conversation, by treating it as housekeeping. Send the supplier a short written request with five items:
- Every repository containing code or configuration for your platform, with the organisation that owns each.
- Every hosted service and cloud account the platform depends on, with the account owner and the billing party.
- Every person, on both sides, with administrative access to any of the above.
- Written confirmation of where intellectual property in the delivered work sits, with reference to the clause that says so.
- Where the project history lives (tickets, decisions, documentation) and whether you can export it.
Call it an access inventory you intend to maintain. A good supplier answers in an afternoon, because they already have the list. A slow or partial answer is itself information, and you want it before there is any reason to worry.
The pattern to aim for is client owned repositories and client owned accounts with the supplier granted access, rather than the reverse. If your team objects that nobody in house can operate these accounts, separate ownership from operation. You can own the account, pay for it, and grant the supplier full rights to run it. What changes is who can revoke access, not who does the work.
Moving the history
If the answer to the fifth item is "it lives in our tooling", move it. Ticket history, decision records and documentation belong in a system you control, with the supplier working inside it. Most project tools allow a guest organisation; the practical difference is whose subscription it sits on and who can export it.
This matters more than people expect. Tickets are where the reasons live. When a future engineer asks why the order export skips one status, the answer is in a ticket from the first year of the build, and finding it is the difference between a quick fix and a week of archaeology. In regulated sectors the history is also evidence: what was specified, what was tested, who approved the change. An auditor will ask for it, and "the previous supplier had it" is not an answer anyone enjoys giving.
Do the migration while the relationship is calm. Under pressure it is possible but slower, and things go missing that you only notice later.
Keeping delivery going through a change
If a supplier change arrives, the question that matters is whether delivery continues through it or stops while everyone renegotiates. It continues when three things are already true: the code and accounts are in your name, the history is in your system, and the people doing the work are identifiable and willing to carry on.
We have seen at first hand which arrangements make a transition survivable and which make it painful. Several client programmes continued without interruption through a supplier transition: project history was migrated into a new instance so the record of decisions survived the change, and each contract was re-established directly with the client under its own governing law. What makes any transition survivable is not goodwill. It is whether those three conditions are already in place, or can be put in place quickly. Where neither is true, every step of the move needs somebody else's permission, and the people who can give it are on the list nobody made.
Give procurement that argument before you need it. Contracting directly with the team already doing the work keeps delivery running. A tender usually pauses delivery and hands the platform to people who have to rediscover the context first. Keep the direct route open by knowing who the delivering people are, not only which company holds the contract.
Clauses for your next contract
Most contracts cover deliverables, payment and intellectual property, and say nothing about continuity of operation. Six clauses close the gap. Your legal team will have their own wording; what matters is that each is present.
- Repository and account ownership. Code, configuration and cloud accounts are held in organisations you own. The supplier is granted access, which you can revoke.
- Escrow or equivalent. Where ownership cannot sit with you, a stated escrow position with defined release triggers.
- Handover obligation. On written request, the supplier hands over code, credentials, documentation and history within a defined number of working days, whether or not the contract is ending.
- Transition period. A defined period after notice during which the supplier continues to deliver and supports a handover, at the contracted rate.
- Named key personnel. The people who hold the context are named, with an obligation to tell you before they roll off and to hand over when they do.
- Access inventory as a deliverable. A current list of accounts, services, people and billing parties, delivered at an agreed interval and on request.
None of this is hostile. A supplier who intends to be around will sign it without much discussion, because every clause describes how they already work. The checklist with this post is written to go straight into a requirements list.
