How do you know it’s time to change a vendor?

The moment you want to change a vendor is the worst possible moment to find out whether you can. By then, the relationship has usually soured, and the questions you need answered are the ones you haven’t asked in a while. 

• Where does the data live? 
• Who understands why the pricing logic works the way it does. 
• What breaks on the day the contract ends?

This piece is for leaders who are either considering a vendor change or who have never tested whether one is possible. We will cover what the law now entitles you to, why that entitlement is not the same as the ability to act on it, and a five-question test you can run this month.

Key Takeaways

• Your ability to leave a vendor is decided by your systems and your knowledge, not by the contract.
• Every new vendor comes with an unspoken assumption that you could remove them later. Almost nobody checks whether that is true.
• Companies are far more confident about changing vendors than their results suggest they should be.
• Five questions: can you export the data, explain the logic, hire for the stack, run it for six months, and replace the vendor without stopping the business?
• One rule makes the test honest: if you have not tested it, the answer is no.
• Run the test while the relationship is still good. Done in anger, it becomes a negotiation instead of a check.

Every new vendor adds an assumption nobody checks 

Vendor risk has changed shape, and it has little to do with any single supplier.

The number of vendor relationships a medium- to large-sized company has is more than 3. A system here, a platform there, a tool for one team, an AI service connected to your records because it only took an afternoon to set up.

Each one arrives with the assumption: if this stops being useful, we can remove it later.

That assumption is almost never tested. So the number worth knowing is not how many vendors you have. It is how many “We’ll leave later” you have assumed and never checked.

The dependency behind this is measurable. MuleSoft surveyed 1,050 IT leaders for its 2026 Connectivity Benchmark Report. The average company in that survey runs 957 applications. And 71% of the IT leaders said their systems have become too dependent on each other.

That matters for a vendor change. When systems depend on each other, swapping one of them stops being a simple job and becomes a project. It is the same build-up we described in integration debt.

Confidence is a poor guide

The gap between thinking you can leave and being able to leave is wide.

Zapier surveyed 542 US executives who had active AI vendor contracts. Almost 90% believed they could change vendors within four weeks. 41% thought they could do it in two to five working days.

But among the companies that had actually tried to move from one platform to another, only 42% said it went smoothly. For the other 58%, the move either failed or took far more work than expected.

In our piece on data trust, confidence in company data went up the further people sat from data. The same thing happens here. Confidence about leaving is not evidence that you can.

The five-question reversibility test

Five questions. A leadership team can answer them in an afternoon.

1. Can you export your data in a form that still makes sense?

We’re not asking whether the export button exists, but whether what comes out is usable.

A file with 400 tables and column names is an export. In practice, it is also a puzzle.

The real question is whether you have what makes that export readable: field definitions, code lists, what each status value means, which records are still active. If your teams never agreed on those definitions, you have an earlier problem to fix first. That is the argument behind minimum viable data.

2. Can you explain the logic?

Every system contains business rules. 

• How a discount is calculated. 
• When an approval is needed. 
• What triggers an escalation. 
• Which cases skip the normal route.

Ask who in your company can explain those rules without opening the code or calling the vendor.

If the answer is nobody, then the logic is not really yours. 

AI-generated code makes this harder. Code that nobody reviewed is code that nobody can explain, as we wrote in this vibe coding piece. The same is true of all the small changes added after launch and never written down.

3. Can you hire for the stack?

If the system is built on common technology, you have choices: another supplier, a contractor, or your own hire. If it runs on a closed platform or an unusual framework, you may have exactly one option.

A simple version of the question: 

If you advertised a job tomorrow to maintain this system, how many serious candidates would you get in your market?

4. Could you run it for six months without the vendor?

Who has the passwords, the hosting access, the deployment process, the monitoring, the backups? Who gets the alert in the morning?

Six months is the right length because it covers a normal procurement cycle. If the honest answer is that things would start breaking within weeks, it is a dependency, and it should be managed as one.

These are the same questions an operating model should answer before launch. 

5. Could you replace the vendor without stopping the business?

The hardest question because the answer sits in the connections rather than in the system.

A system that stands alone can be replaced over a weekend. A system connected to finance, your CRM, a partner portal, and three scheduled exports cannot.

Most companies have no reliable list of those connections. If nobody can say what connects to this system and what breaks when it stops, there is no real migration plan.

The rule that makes the test honest

Most companies will answer these questions with “we think so” or “probably, with some effort.” So here is the rule that makes the exercise worth doing. 

If you have not tested it, the answer is no.

You only know a system is reversible once someone has proved it. Ask for an export, and give it to a person who did not build the system to read. Have someone inside the company walk through the business rules and write them down. Check who actually holds production access, rather than who is supposed to.

Ideally, you will run the test at three points: before you sign, at every renewal, and, most importantly, while you are happy with the vendor.

Run it while you are angry, and everyone will treat it as a negotiating move. So, try doing it when the waters are calm. That is also when a good vendor will help you pass.

One warning: Changing vendor is often the wrong answer

This test tells you whether you could change vendors. It does not tell you whether you should. 

Many vendor relationships go wrong for reasons that have nothing to do with the vendor. 

• Unclear ownership on the client side. 
• A scope that changed every month. 
• Decisions nobody was allowed to make.

Change the supplier without fixing any of that and you will end up in the same relationship with a different company. We made a version of this point in when to stop a digital transformation project. The honest question is whether the vendor is the problem or the symptom.

The Net Group view: A good partner should pass this test

We have built systems for more than 30 years, and we have been on both sides of this.

Our view has not changed since we wrote that companies should stop buying projects and start building capability. A serious partner should leave the client stronger after every project. That means written decisions, knowledge that transfers, clear ownership, and data the client can actually take with them.

That is easy to claim and hard to fake. 

A good partner will help you build the ability to leave. The ones who avoid the data readiness question have already answered it.