You have already decided. This post is not about whether to switch, it is about doing it without setting fire to four months of work in the process. That distinction matters because the most expensive mistakes in a vendor change happen in the first week, before anyone has written a line of new code, and they are almost all about access rather than engineering.
TL;DR
- Confirm you can reach your own accounts, repositories, and data before you open the conversation. Not as a tactic, as ordinary sequencing.
- Ask for the nine-item handover package while the relationship is still cordial.
- Budget 20% to 40% rework. Integrations and pipelines usually survive; untested prompt logic usually does not.
- Rule out scope, data, and ownership problems first, because switching vendors fixes none of those.
- Change the contract as well as the vendor, or you will run the same failure with a different logo.
Do this before you send any email
Verify, today, that you can independently log in to: your cloud accounts, your model provider accounts, your code repository, and your domain and DNS. Then run a data export and confirm the file opens. None of this is hostile. It is checking that things you already own are actually reachable, and the moment to discover otherwise is well before a hard conversation rather than after one.
First, make sure the vendor is the problem
Switching is expensive and it only fixes one category of failure. Three tests before you commit.
Was the scope ever clear? If the definition of done changed three times, the build was chasing a moving target and the next team will chase it too. Fix the specification first, and you may find you do not need a new vendor at all.
Did they get the data they needed? A large share of what looks like vendor underperformance is a data access problem that nobody escalated. If the required system was never connected, that is an internal blocker wearing a vendor's name. Stalled AI project triage walks through separating these.
Was there an owner on your side? A project with no internal decision-maker drifts, and every vendor drifts with it. Replacing the vendor without appointing an owner reproduces the outcome at a higher cost.
If all three come back clean and the work is still not landing, the vendor is the problem. Have one direct conversation first, naming the specific gap and what would resolve it, and give a concrete dated answer a single sprint to prove itself. Vague reassurance is its own answer.
The nine-item handover package
Ask for all of it in one written request, ideally while the relationship is still cordial. A handover request that arrives after a difficult conversation gets a slower, thinner reply, which is human and predictable and worth designing around.
| Item | Why it matters |
|---|---|
| Repository with full commit history | History shows what was tried and abandoned |
| Prompt and system instruction files | This is where the business logic lives |
| Infrastructure configuration as code | Otherwise the next team reverse-engineers the environment |
| Evaluation and test cases | Without these, nobody can change anything safely |
| Environment variables and secrets, documented | The classic three-week blocker |
| Data export in an open format | Conversations, embeddings source, labelled examples |
| Architecture description | One page beats a call |
| Third-party account inventory | Who owns each, whose card is on it |
| Known issues, written | The most valuable and least likely to be offered |
The last one deserves a specific ask. Every build has a list of things held together loosely and known to be fragile, and it lives in a departing engineer's head. Ask for it directly and in writing: what would you warn the next team about? Most people answer that honestly, because it is a professional courtesy rather than an admission.
If your contract does not clearly assign the first four items to you, read who owns the AI system you paid for before you send anything, because the answer changes how you ask.
Running the exit well
Keep it factual and unemotional. You are not required to justify the decision, and a detailed critique invites a debate you do not need to have.
Pay what you owe, promptly. This sounds like advice about ethics and it is mostly advice about speed: an unpaid invoice is the most common reason a handover goes slow or incomplete, and the delay costs more than the disputed amount nearly every time.
Offer a paid handover window. Two to five days of the outgoing team's time, scoped to answering the new team's questions, is the cheapest insurance available in this whole process. Vendors generally accept, because it is a clean ending and it pays.
Get the new team on the call. A direct conversation between the outgoing and incoming engineers transfers more in ninety minutes than any document will. Be in the room, keep it technical, and take notes yourself.
Revoke access on a defined date, communicated in advance, applied to everyone. Not as a statement, as routine hygiene.
What the takeover actually costs
Expect 20% to 40% of the original scope to be redone. The variance is almost entirely about documentation quality.
The new team has to read the codebase and, more importantly, verify it. "This module handles escalation" and "this module handles escalation correctly" are different claims, and only one of them can be trusted without testing. That verification pass is real work producing no visible progress, which makes it the part clients most often try to skip and the part that most reliably causes a second failure.
What usually survives: integrations, data pipelines, cloud infrastructure, access and approvals, and any labelled data. That is frequently half the original spend and it is the half nobody enjoyed paying for.
What usually does not: prompt logic with no tests and no history. Not because it is bad work, but because it is unverifiable. A new team that cannot measure current behaviour cannot change it without risk, so they rebuild it with tests. That is the right call even though it looks like waste.
Ask any incoming vendor for a fixed-price assessment before a fixed-price build. One to two weeks, reading everything, ending in a written report on what works, what is salvageable, and what a realistic finish looks like. A vendor who quotes a full build before reading the existing code is guessing, and you will pay for the guess later.
Free PDF · No fluff
The 2026 AI Development Rate Sheet
Real build, agent, RAG, and consulting rates by tier — the numbers vendors quote behind NDAs, in one PDF.
Do not repeat it: change the contract too
Most vendor failures become visible in month four because nothing before month four was verifiable. That is a contract design problem, and it is fixable in four clauses.
Require a working deployment in your own cloud account from week one, even if it does almost nothing. This single term prevents the most common failure mode, which is a build that exists only on someone else's laptop until it is late.
Require weekly commits to a repository you own. Not a demo, not a status update. Code you can see.
Require the evaluation set as a delivered artifact, with cases and expected outputs. It is your quality bar made concrete, and it is what lets you judge progress without taking anyone's word for it.
Write the handover package into the agreement as line items, so a future exit is a checklist rather than a negotiation.
Questions to ask an AI consultant covers the selection stage, and what an AI agent engagement includes covers what a well-scoped one looks like from the start.
The bottom line
A mid-project vendor change is survivable and routinely worth doing. It goes wrong in predictable ways: access discovered too late, a handover requested after the relationship soured, and a new team quoting a build before reading the code.
Do the boring parts in order. Confirm access to what is already yours. Request the nine items in writing while things are still civil. Pay what you owe and buy a short handover window. Have the incoming team assess before they estimate. Then fix the contract so the next relationship is visible from week one rather than month four.
Next step: If you want an independent read on what is salvageable before you commit to a new vendor, the AI Profit Leak Audit reviews the existing build and reports what works, what has to be rebuilt, and what a realistic finish costs. Or tell us where the project stands and we will tell you whether switching is the right move at all.
What should I get from an AI vendor before ending the contract?+
Nine things: repository access with full commit history, the prompt and system instruction files, infrastructure configuration as code, the evaluation and test cases, environment variables and secrets documented, a data export in an open format, an architecture diagram or written description, a list of every third-party account and who owns it, and a written walkthrough of known issues. Ask for all nine while the relationship is still cordial, because a handover request after a difficult conversation gets a slower answer.
How much rework should I expect when switching AI vendors mid-project?+
Plan for 20% to 40% of the original scope to be redone, and be pleasantly surprised if it is less. The new team has to read the codebase, verify what actually works rather than what is claimed, and rebuild anything undocumented. Integration work and data pipelines usually survive intact. Prompt logic with no tests usually does not, because nobody can safely change what they cannot measure.
Should I tell the vendor I'm looking at alternatives?+
Not until you have confirmed access to your own accounts and repositories. This is not about being adversarial, it is about ordinary sequencing: verify you can log in to your cloud accounts, your model provider accounts, and your repository, and that a data export completes. Once that is done, an early honest conversation often produces a better outcome than a surprise, and sometimes it fixes the relationship instead of ending it.
Is it cheaper to fix the relationship than to switch vendors?+
Usually, if the failure was communication rather than capability. Switching costs you the rework tax, the ramp-up time, and the risk that the second vendor has the same problem for different reasons. Before you move, have one direct conversation naming the specific gap and what would resolve it. If the answer is concrete and dated, give it one sprint. If it is reassurance without specifics, you have your answer.
How do I avoid a second failed AI vendor relationship?+
Change the contract, not just the vendor. Require a working deployment in your own cloud account from week one, weekly commits to a repository you own, an evaluation set delivered as files, and a defined handover package written into the agreement. Most vendor failures become visible in month four because nothing before month four was verifiable. Make it verifiable from week one and the failure surfaces while it is still cheap.
Free PDF · No fluff
The 2026 AI Development Rate Sheet
Real build, agent, RAG, and consulting rates by tier — the numbers vendors quote behind NDAs, in one PDF.
Written by
Pankaj Kumar
Founder · Metageeks Technologies
Metageeks builds production-ready AI products for $1M–$15M companies — shipped in fixed-price sprints, not open-ended retainers. We write about what actually works in the field.
Connect on LinkedInThe AI Build Brief
Ship AI that actually works.
Practical playbooks on building, pricing, and shipping production AI — one email, every other week. No fluff.
