Short answer
#What to understand first
Dependency on a supplier is not one thing. It is five, and they have very different costs and very different fixes:
- Ownership — whose name each account is in. Can leave you unable to operate.
- Operability — whether anybody else can run and release the system. Costs weeks.
- Understanding — whether anybody outside the supplier can describe the system. Costs months.
- Credentials — where the keys live. Costs hours to fix and can cost everything if it interacts with the first.
- Replaceability — how long from decision to a new team shipping. The consequence of the other four.
The reason to separate them is that most companies find the relationship is fine and the arrangement is fragile. That is a good outcome: it means the fix is administration rather than a supplier change.
#The six moves
-
Move every account into company identities
Domain, DNS, cloud, database, backups, repository, CI, payment provider, email, monitoring — and the recovery addresses on all of them.
About an afternoon of work, and it removes the only category of exposure that cannot be undone with money. Do this one first even if you do nothing else.
-
Have somebody outside the supplier deploy, once
A single supervised release, performed by an in-house person or an independent contractor. It converts “they have a process” into a fact and reliably finds two or three undocumented steps.
-
Restore a backup into a scratch environment
Also performed by somebody who is not the usual person. This is the test that most often fails, and it produces your real recovery time as a by-product.
-
Derive a technical picture the company owns
What the system is made of, what it depends on, and what nobody can currently confirm — derived from the code rather than written by the party you might one day leave.
Not as a challenge. As a company asset that would survive any change of supplier, including one the supplier initiates.
-
Write down the questions only they can answer
The gaps in that picture are the list. Ask them now, in writing, as part of normal work rather than as part of an exit.
-
Put the transition terms in at the next renewal
Accounts remain company-owned; on termination, a defined handover period with defined acceptance tests; a paid consultation window afterwards.
Both sides benefit from this existing before it is needed, which is exactly why it is easy to agree when it is not needed.
#What does not help
Asking for more documentation.
Instead Derive the structural half and ask specific questions for the rest. A documentation request produces a document written to satisfy a request.
Hiring one in-house developer to “keep an eye on them”.
Instead A single person who is not the supplier is a new single point of failure. Fix ownership and operability first; hire because you need capacity, not as insurance.
Splitting work between two agencies to avoid depending on one.
Instead Usually produces two partial dependencies, a coordination cost, and nobody who understands the whole. Reduce the dependency instead of dividing it.
Demanding source code you already have.
Instead You almost certainly have the repository. The dependency is not the code; it is the understanding and the accounts.
Threatening to leave as a negotiating tactic.
Instead It damages a working relationship and changes nothing structural. Do the six moves quietly; they are more effective and are not adversarial.
#Talking to the supplier about it
The framing that works is continuity: "we need to be able to answer these questions to an investor, an acquirer or an insurer." True, not about them, and carries a deadline that is not you.
Three things worth knowing about how this lands:
- Most suppliers are relieved. Holding a client's domain is an obligation nobody asked for.
- A competent supplier already knows. They have seen a client's business threatened by an account in the wrong name, and they would rather it not be theirs.
- Resistance is the most useful signal available. If asking who owns the domain causes a problem, that reaction has told you more than the answer would have.
#The dependency you cannot remove
Some of it is structural rather than relational, and it is worth naming separately so it can be managed instead of resented:
- Familiarity. A team that has worked on a system for four years is faster than any replacement, and no amount of documentation closes that gap entirely. This is a real cost of switching and it is not anybody's fault.
- Proprietary components. A supplier's own framework or internal library inside your product outlives the contract. Worth knowing about; sometimes worth paying to remove.
- Unusual technology. A stack few people know is a small hiring market whoever the supplier is.
- Undocumented convention. Strong internal patterns nobody has written down are expensive for any newcomer.
Vendor lock-in deals with which of these are worth spending money to avoid.
#What goes wrong
Starting with the understanding rather than the ownership.
Instead Ownership first. It is faster, it is cheaper, and it is the only part that can leave you permanently worse off.
Doing it all at once as a formal project.
Instead Six moves over a quarter, as normal work. A “supplier risk project” reads as the beginning of an exit whether you mean it that way or not.
Deriving the picture once and never again.
Instead A picture two years old is a picture of a different system. Refresh it when something material changes; the comparison is where the value is.
#What this does not cover
What this does not do
- Whether the supplier is doing good work. That is a separate judgement and this page takes no position on it.
- Contract law, notice periods and intellectual property. Ask somebody qualified.
- What to do if the supplier has already stopped cooperating — at that point read the changing-agency guide instead.
- Pricing and commercial negotiation, which is a different conversation entirely.