Most guides are about choosing a software partner. Fewer are about leaving one, even though that is often the harder decision. A system is already in production, people depend on it every day, and the only team that fully understands it is the one you are no longer sure about. We inherit projects like this regularly, and the ones that go well have something in common: the client planned the exit before announcing it.
Signs it is time to change partners
Every engagement has a bad month. What matters is whether problems get explained and fixed, or simply repeated. These are the patterns that, over two or three quarters, usually mean the relationship will not recover:
Missed dates without reasons. A delay with a clear cause and a new plan is normal. Delays that arrive as surprises, with no change in how the work is run, are a management problem the vendor is not solving.
Only the vendor can deploy. If releasing a change needs a specific person at the vendor, you do not fully own your system - and the longer that lasts, the more expensive leaving becomes.
Every change costs more than the last. Rising estimates for similar work are the clearest sign of a codebase that is getting harder to change, and of a team that is not paying down that debt.
The team keeps rotating. New faces every quarter and no documentation means knowledge leaves with every person. Ask who still works on your project from the first month.
If two or more of these are true, run the checklist for choosing a software development partner on your current vendor as if you were meeting them for the first time. Sometimes an honest conversation and a changed setup fix it. Often it confirms what you already suspected.
What to secure before you tell anyone
The order matters more than the new vendor. Before you announce the change - even before serious conversations with a replacement - make sure your company holds the following, in its own name:
- Admin access to every code repository, including the ones only the vendor's CI uses
- Ownership of the cloud accounts, domains, DNS and app-store listings - in your company's name
- Every secret and credential: API keys, database passwords, signing certificates, third-party logins
- Database backups you have restored yourself at least once
- Whatever documentation exists - architecture notes, runbooks, deployment steps, however thin
- A list of every third-party service the system depends on, and who pays for it
Most of this should already be yours under your contract. Check the agreement for clauses on intellectual property, handover duties and notice periods, and keep the tone professional: you need the outgoing team’s cooperation for weeks after the decision.
The cheapest moment to secure access to your own system is before anyone knows you are leaving.
A staged handover plan
The riskiest way to change partners is a single cut-over date. A staged handover keeps the system running and gives the new team time to learn it while the old team can still answer questions.
Weeks 1-2: shadow. The new team reads the code, sets up its own environments, and watches the outgoing team deploy and handle incidents. The goal is a written map of the system: components, data flows, integrations and the parts nobody understands.
Weeks 3-4: supervised changes. The new team makes small, real changes and deploys them, with the old team reviewing. This is where missing documentation and fragile build steps surface - better now than during an outage.
Weeks 5-8: ownership by area. Responsibility moves one area at a time - first the parts with the best test coverage, last the parts with the most risk. The outgoing vendor stays on call, ideally on a small retainer, until the last area has moved.
Resist the urge to rewrite as soon as the new team arrives. A new partner who proposes rebuilding everything before they understand the system is repeating the mistake you are trying to escape. Stabilise first, then improve one module at a time - the approach we describe in legacy modernisation without the big rewrite.
Choosing the next partner
The second choice should be stricter than the first. Ask the candidate how they have taken over systems before, and ask for a redacted handover plan from a real project. Agree on milestone billing rather than an open-ended hourly contract, and make documentation a deliverable, not a favour. Most of all, check that leaving the new partner would be easy - because the best protection against ever reading this post again is a relationship you could end cheaply.
Frequently asked questions
When should I change my software development partner?
When problems stop being explained and start being repeated: missed dates without reasons, a system only the vendor can deploy, rising cost per change and constant team rotation. One bad month is normal; a pattern over two or three quarters is a signal.
How do I switch software vendors without losing my project?
Secure the code, infrastructure, credentials and backups before you announce the change, then hand over in stages: the new team shadows, then deploys with supervision, then takes ownership of one area at a time while the old vendor is still on call.
How long does a software handover take?
For a typical business system, four to eight weeks of overlap between the old and new team. Systems with no documentation or no tests take longer, because the new team has to rebuild that knowledge first.
Do I need to rewrite the software when I change partners?
Almost never as a first step. A new partner should stabilise and understand the system before proposing changes. Replace parts only where there is a clear reason, one module at a time.