Most of what goes wrong in a software vendor transition is paperwork, not code. A competent team can read an unfamiliar codebase. What stops them is not having the keys, the history, or an honest account of what actually works.
This article sets out what to agree before signing, what to collect before leaving, and how to judge whether the change was worth making.
In this article
- When to consider a change
- The short answer
- Why handover fails more often than code does
- Seven items to collect
- What to agree at signing
- The first six weeks with the new team
- What it costs, honestly
- How to judge whether it worked
- Frequently asked questions
The short answer on a software vendor transition
A software vendor transition succeeds or fails on seven items: repository access with full history, infrastructure and account access in your own name, a written statement of current state, the deployment path, third-party credentials and contracts, the data with its export format, and a named person available to answer questions for an agreed period.
Six of those seven cost nothing to agree at the start of a relationship and are difficult to obtain at the end of one. That asymmetry is the entire argument for putting them in the original contract.
The seventh — a person available to answer questions — has to be paid for, because the outgoing team has no remaining incentive to provide it.
Why a software vendor transition fails on paperwork rather than code
Software projects already have a poor baseline. McKinsey and the University of Oxford, studying 5,400 large IT projects, found an average cost overrun of 45% with 56% less value delivered than predicted.
Those figures come from Delivering large-scale IT projects on time, on budget, and on value. The study looked at projects under a single vendor, which makes it a floor rather than a ceiling for what happens when the vendor changes mid-flight.
The reason is specific. A new team inherits the code but not the reasoning. Why that library, why that database schema, why that workaround in the payment flow. When the history is missing, every one of those decisions has to be rediscovered or repeated.
Market conditions make the timing harder than it used to be. Technology services spending in Asia Pacific grew 80% last quarter to a record US$10.0 billion, according to the ISG Index for Q3 2026. Strong demand means good engineers are allocated earlier, so a software vendor transition started without a replacement team already secured can leave a product unattended for weeks.
Signs it is time to consider a software vendor transition
Changing provider is disruptive enough that it should not be the first response to a bad quarter. Five signals, taken together rather than individually, usually mean the arrangement is no longer recoverable.
- Nothing runnable for several weeks. Progress reported as a percentage, with no build anyone can open and use. A demo cannot be faked the way a percentage can.
- Answers moved from numbers to reassurance. Specific questions receive general confidence in reply. This usually precedes a missed deadline by about a month.
- The named people changed without a handover. The engineers who built the system left the account and nobody wrote down what they knew.
- Small changes now take days. A rising cost for trivial work is the clearest measurable sign of an unmaintained codebase.
- Risks only surface after they have happened. If raising a problem early has ever cost someone on the team politically, you have bought silence.
One signal on its own is normal in any engagement. Three or more at once, over a month, is the point at which a software vendor transition usually costs less than continuing.
It is worth asking the opposite question too. A software vendor transition fixes a supplier problem; it does not fix an unclear scope, an absent decision-maker on your side, or a roadmap that changes every month. If those are the real constraints, a new team will hit them just as hard as the previous one did.
Seven items to collect in a software vendor transition
1. Repository access, including history
A compressed archive of the latest version is not a software vendor transition. Past commits are where the reasoning lives. Ask for access to the repository itself, with the commit history intact and any branches still in use.
2. Infrastructure and accounts in your own name
A software vendor transition stalls fastest on access. Cloud hosting, domains, app store accounts, payment providers, monitoring, error tracking. The common failure is an account registered to one engineer’s personal email. Check the registered owner of each one now, while the relationship is still good.
3. A written statement of current state
Three lists: what runs in production, what is broken, what was scoped but never started. Ask for it in writing and treat vagueness as information. A team that cannot describe the current state in a page does not have a clear picture of it either.
4. The deployment path
How code gets from a developer’s machine into production, and who can approve it. If the answer lives in one person’s head rather than in a document or a pipeline, that person is the real dependency.
5. Third-party credentials and contracts
Every paid service the product depends on, who is billed, and when each contract renews. Products have been taken offline by an expired certificate nobody knew existed.
6. Data, with an export you have tested
Ask for the export format and run the export once while the outgoing team is still available. An export that has never been tested is a promise, not a backup.
7. A named person, for an agreed period
Two to four weeks of availability for questions, written into the exit terms and paid for. This is the single item most often skipped, and the one that most reliably shortens the handover.
What to agree at signing to make a software vendor transition possible
The time to negotiate a software vendor transition is when neither side expects to need one. Four clauses do most of the work:
- Ownership. Who owns the source code, the data, and anything created during the engagement. State it plainly rather than by reference to a schedule nobody reads.
- Transfer mechanism. Not just that you own it, but how you receive it and in what format, within how many days of a request.
- Notice period, both directions. A vendor can end an engagement too. Equal notice is easier to agree at the start than to argue for later.
- Handover period. A defined number of days of question-answering after the final invoice, at an agreed rate.
Our note on choosing business software and vendors covers the ownership questions in more detail, and why software projects go over budget covers what scope changes do to a contract that was never written for them.
The first six weeks after a software vendor transition
A new team is slower at the start, and that is a normal feature of a software vendor transition rather than a sign of the wrong choice. What matters is whether the slowness is decreasing.
Weeks one and two. Reading, running the system locally, and producing their own version of the current-state list. Compare it against the outgoing team’s version; the differences are the most useful document you will get.
Weeks three and four. Small changes shipped to production. The purpose is to prove the deployment path works for them, not to deliver features.
Weeks five and six. Normal delivery resumes. If it has not by week eight, the problem is usually missing access or an undocumented dependency rather than the team’s ability.
Resist the urge to hand the new team a long backlog in the first week of a software vendor transition. A product nobody can deploy is a worse position than a product with a queue of unbuilt features.
What a software vendor transition costs, honestly
Three costs of a software vendor transition sit outside the new team’s rate, and counting them changes the decision more than comparing hourly prices does.
Rediscovery time. Two to four weeks of a new team reading code you have already paid to have written. This is unavoidable; it is only made worse by a thin handover.
Work in progress that cannot be reused. Anything half-finished at the point of change is usually restarted. The more complete the feature, the more likely it survives.
Your own team’s time. Someone internal has to answer questions, make decisions and set priorities during the change. Budget four to six hours a week for the first month.
Published starting rates are a useful reference point before any of these conversations. Ours are listed at software outsourcing rates in Vietnam, and offshore development team for Australian companies covers the longer-term arrangement a transition often leads into.
One cost is rarely discussed: the decision itself takes weeks of attention from whoever makes it. Deciding quickly, with a clear rule agreed in advance, is often worth more than deciding perfectly.
How to judge whether the software vendor transition worked
Set the measure before the new team starts, not after the first invoice:
- Time from a feature being specified to it running in production.
- Number of defects found after release, compared with the previous six months.
- Hours your own team spends on coordination each week.
Record today’s values before the software vendor transition begins. Compare after ninety days, which is long enough to pass the learning curve and short enough to act on. If nothing has moved by then, the problem is usually the working arrangement rather than the people.
A software vendor transition is not a reset. It carries forward every decision already baked into the product, and the new team inherits those whether or not anyone wrote them down.
Frequently asked questions
How long does a software vendor transition usually take?
Plan for four to eight weeks before the new team reaches normal output, assuming the handover documents exist. Two to four of those weeks go to reading the existing codebase. Without repository history or infrastructure access, the same work takes two to three times longer.
What should be in the handover agreement before any work starts?
Four things: who owns the source code and data, how they are transferred, what notice each side must give, and a defined handover period with someone paid to answer questions during it. Agreeing this at signing costs nothing; agreeing it at the exit meeting costs leverage.
Should we rewrite the existing code or continue it?
Continue it unless there is a specific reason not to. A rewrite restarts the clock on every problem the previous team already solved, including the ones nobody documented. Rewrite only the parts that block the next three months of work.
In short: a software vendor transition is decided by what you agreed at signing, not by what you ask for at the exit meeting. Seven items, four clauses, and one named person for an agreed period.
