At some point a company decides its software partner is no longer the right one. The delivery has slowed, the trust has thinned, the invoices no longer match the value. The instinct is to have the hard conversation and move on. But the order of operations matters more here than almost anywhere else, because the thing you are most at risk of losing is not visible on any invoice — and once it is gone, no amount of goodwill brings it back.
The real risk is knowledge and access, not code
People imagine the danger in switching vendors is the code: what if we cannot get it, what if it is a mess, what if they hold it hostage. The code is rarely the problem. The real risk is everything around the code — the knowledge of why it was built the way it was, and the access that lets anyone run it at all. A repository you can download is worthless if you do not have the cloud account it deploys to, the domain it answers on, the credentials to the payment provider, or the one person who knows why the nightly job runs at 3am and must not be moved.
Knowledge and access are also the things a departing vendor loses fastest. Not out of malice, usually — the engineer who held it in their head gets assigned elsewhere, the shared password gets rotated, the account manager leaves. A handover done six months after the decision recovers a fraction of what a handover done before the decision was announced would have. This is why the sequence is everything.
A concrete case shows how quietly this bites. A company we can imagine parts ways with its agency on good terms, downloads the full repository, and feels secure — until the first deploy fails because the production database credentials lived only in a config on the agency's build server, the SSL certificate renews through an account tied to a former contractor's email, and the payment integration points at a sandbox key nobody thought to swap. None of that is in the code. All of it is access, and all of it was recoverable for free the week before the relationship ended and expensive the week after.
Secure what you own, first and quietly
Before you say a word about leaving, make a plain inventory of what should be yours and confirm that it actually is. The source code, in a repository you control, not one inside the vendor's organisation. The cloud accounts the system runs in, owned by your company with your billing behind them. The domain names, registered to you. The DNS. The credentials and API keys for every third-party service — payments, email, maps, analytics. The build and deployment pipelines. And the documentation, such as it is: runbooks, architecture notes, environment variables, the list of scheduled jobs.
Do this quietly and do it while the relationship is still cordial, because a cooperative vendor will hand these over as a matter of course, and a soon-to-be-former one may not. If ownership is already clean, you have lost nothing by checking. If it is not — if the repository lives in their account, if the cloud bill is on their card, if the domain is registered to a developer who left — you have just found the work that has to happen before anything else, and you have found it while you still have leverage.
A clean handover checklist
A handover is not an email with a zip file attached. It is a deliberate transfer, and it is worth writing down what "complete" means so both sides can agree it happened. You want the code and its full history, not a snapshot. You want administrative ownership of every account transferred to your people, with the vendor's access removed on a known date, not left dangling. You want a documented way to build the software from nothing and deploy it — proven by actually doing it, ideally with the new team watching. And you want the tacit knowledge extracted while there is still someone to extract it from: a few recorded sessions where the outgoing engineers walk through the parts of the system that are not obvious from the code.
The test of a good handover is simple and unforgiving. Can a competent engineer who has never seen the system get it running in a fresh environment using only what was handed over? If the answer depends on emailing someone at the old vendor, the handover is not done.
Documentation deserves particular suspicion, because its absence is invisible until you need it. A vendor can hand over a repository that builds perfectly on their machine and still leave you stranded, because the knowledge of which environment variables the system needs, which external services it depends on, and which manual step happens once a month lives in someone's head rather than in a file. The way to surface this is not to ask for documentation — everyone says it exists — but to ask a new engineer to stand the system up from scratch and write down every question they had to ask. That list is the documentation you were actually missing.
Overlap or hard cutover
There are two honest ways to make the switch, and the wrong one is expensive. A hard cutover ends the old relationship on a date and starts the new one the next day. It is cheaper and cleaner on paper, and it works when ownership and documentation are genuinely in order — but it leaves no margin if something the old team knew turns out to matter.
An overlap keeps the outgoing vendor available, at reduced scope, for a few weeks after the new team starts — to answer questions, not to build. It costs more in the short term and it is worth it in almost every case where the system is load-bearing, because the questions you cannot anticipate are exactly the ones that surface once real work begins. Pay for the overlap and treat it as insurance. The alternative is discovering, at 3am on the first incident, that the only person who understood the retry logic left three weeks ago.
Assess the inherited codebase honestly
When a new team meets an inherited codebase, there is a strong and unhelpful reflex: this is a mess, we should rebuild it. Sometimes that is true. Far more often it is the sound of engineers who did not write the code meeting the ordinary compromises of code that has been shipping and earning money for years. An honest assessment separates the two. It looks at whether the architecture can carry where the business is going, whether the code is testable and deployable, where the real risks are — security, data integrity, single points of failure — and what it would cost to live with it versus replace it.
The output should be a ranked list of what actually needs attention, not a verdict of good or bad. A codebase can be unlovely and entirely fit for purpose. The job of the assessment is to tell you which parts are which, so your money goes to the risks that matter rather than to an engineer's aesthetic discomfort.
An example clarifies the difference between messy and unfit. A codebase might have no automated tests, inconsistent naming, and a folder structure only its author understood — and still deploy reliably, handle every real edge case, and be perfectly safe to change carefully. That is messy but fit. Another might read beautifully and yet store passwords in plain text, or model its core entity in a way that makes a promised feature impossible without a migration that touches every table. That is tidy but unfit. Only the second kind justifies real spend, and telling them apart is precisely what a sober assessment is for.
Resist the rebuild-from-scratch reflex
The temptation to start over is strongest exactly when you have just changed partners, because a new team has no emotional investment in the old code and every incentive to prefer a clean slate. Be careful. A rebuild throws away not just the code but everything the old code silently encodes — the edge cases handled after real incidents, the odd rule that exists because a regulator asked for it, the behaviour a customer depends on and never mentioned. Rebuilding re-runs all of those risks, and it does so while the business waits and pays for two systems.
The disciplined move is to take the system as it is, stabilise it, get it deploying cleanly under the new team, and only then decide — with evidence — which parts are worth replacing and in what order. A partner who proposes a full rewrite in the first week is telling you more about their preferences than about your system.
Keep the lights on during transition
Whatever else happens, the software has to keep working while it changes hands. Customers do not care that you are mid-transition. That means the new team's first job is not features and not cleanup — it is operational control: the ability to deploy, to see when something breaks, to roll back, to respond to an incident. Until the new partner can keep the lights on unaided, the handover is still in progress no matter what the contract says. Feature work that starts before operational control is in place is building on a floor no one yet owns.
Start with an assessment
The safest way to change vendors is to let the incoming partner reduce the risk before anyone commits to a full engagement. That is what a short, fixed-fee assessment does. It reviews the inherited codebase and its real condition, checks that ownership and access are genuinely in your hands, and produces a concrete takeover plan: what to secure first, whether to overlap or cut over, and what the honest first phase looks like. It is a small, bounded step that turns a nervous decision into a documented one — so you move to a new partner with your eyes open and your work intact, rather than hoping it all comes across in the zip file.