How to Switch Software Development Vendors Without Losing Your Codebase

What Actually Goes Wrong When You Switch Development Vendors?

Not the code. The context. Companies switching vendors usually receive the repository intact and then discover that the repository was never the valuable part.

The predictable failure sequence looks like this. You give notice. The outgoing vendor's best engineers are immediately reassigned to accounts that still have a future, leaving a skeleton crew to run out the clock. Your incoming team clones the repo and finds it builds, which is reassuring for about a week. Then they hit the first production incident and discover that the deployment runbook lives in a Slack thread from 2024, the staging environment was configured by hand by someone who left, and there is a scheduled job on a server nobody documented that quietly reconciles payment data every night.

None of that is in the repository. It was in people's heads, and those people are now working for someone else. This is the actual content of "knowledge transfer" and it is why transitions that look simple on a Gantt chart routinely take twice as long as planned.

The scale of the exposure is worth stating plainly. Organizations now report that a substantial majority of IT work — development, infrastructure, and support — is delivered by external providers rather than internal staff. When that much of your delivery capability sits outside your walls, the ability to move it without breaking anything stops being a procurement detail and becomes an operational capability in its own right. Most companies do not have it, and find out during the one week they need it most.

Why Do You Have to Negotiate the Exit Before You Need It?

Because the day you give notice is the day your leverage disappears. Every term you did not secure at signing is now something you are asking a vendor to grant you while you are actively leaving them.

This is the single most consequential point in this article and the one buyers most reliably ignore. At signing, both parties want the deal. The vendor will agree to reasonable exit provisions because refusing looks bad and because the exit feels hypothetical to everyone in the room. At termination, the vendor has no commercial reason to be generous, their account team has already written off your revenue, and any cooperation you want is a favour rather than an obligation.

Outsourcing lawyers are close to unanimous on the structure: the contract should contain an exit and transition schedule — effectively an operational playbook for replacing the provider — and the parties should be obliged to review and update it periodically through the term, typically annually. An exit plan drafted at signing and never revisited describes a system that no longer exists by year three.

Regulated buyers no longer get to treat this as optional. Under the EU's Digital Operational Resilience Act, which has applied since 17 January 2025, financial entities must maintain documented exit strategies with tested transition plans for ICT services supporting critical or important functions, and their contracts must cover termination, exit, and transition conditions explicitly. The regulatory test is not whether you exit within a fixed deadline — it is whether the function survives the move. That is a good standard for unregulated buyers to borrow, because it is the question that actually matters.

Which Four Clauses Actually Matter in an Exit Provision?

Most exit clauses in mid-market software contracts are one sentence saying either party may terminate with 30 days' notice. That is a termination right, not an exit plan. The four provisions below are what turn one into the other.

A termination assistance obligation with a defined duration. The outgoing vendor must continue providing services, and actively assist migration, for a specified period after notice — commonly 60 to 180 days depending on system complexity. Without a duration, "reasonable assistance" means whatever the vendor decides it means in the week they lose your account.

A documentation and credentials handover list. Specify it concretely in the contract rather than trusting a general obligation: source code and full commit history, infrastructure-as-code definitions, environment variables and secrets inventory, deployment and rollback runbooks, architecture decision records, third-party account ownership, domain and certificate control, and a list of every scheduled job and external integration. If it is not enumerated, expect to argue about it.

A cooperation clause covering the incoming vendor. The outgoing team must work directly with your replacement provider, not only with you. Otherwise you become a manual relay between two engineering teams during the highest-risk period of the engagement, translating technical questions you may not fully understand.

Transition fees payable on successful completion. Termination assistance is real work and should be paid for — but structure it so a meaningful portion is contingent on the transition actually succeeding against defined criteria. A vendor paid in full up front has no remaining incentive to answer the incoming team's questions in week eight.

What Should You Secure Before You Give Notice?

Administrative control of everything, in your own organisation's name, before the vendor knows you are leaving. This is not adversarial — it is the arrangement you should have had from day one, and a good vendor will not object to it at any point in the relationship.

Work through this list specifically. Is your source repository owned by your company's organisation account, with the vendor's engineers added as members — or is it owned by the vendor's organisation with you added as a guest? The second arrangement is common and it means your access can be revoked by someone else's administrator. The same question applies to your cloud accounts, DNS registrar, CI/CD pipelines, error monitoring, app store developer accounts, and any third-party API subscriptions bought on the vendor's card.

App store accounts deserve a specific mention because they cause disproportionate pain. A mobile app published under the vendor's Apple or Google developer account cannot simply be handed over as a file — transferring an app between developer accounts is a procedural exercise with its own eligibility conditions, and it fails badly if the relationship has already turned sour. Check this before you need it.

Then audit what only the vendor knows. Ask for a current architecture diagram, a written deployment procedure, and an inventory of scheduled jobs and external integrations — as a routine engagement-health request, not as an exit signal. What comes back tells you two things: how much undocumented context exists, and how long a real transition would take. Both are useful to know while you still have a functioning relationship, and it is a reasonable thing to ask of any partner at any time.

How Long Does a Vendor Transition Actually Take?

For a mid-sized production system, budget 60 to 90 days of genuine overlap, and treat anything under 30 days as an emergency rather than a plan. Large or regulated estates run considerably longer.

The number is driven by system complexity and documentation quality, not by team size. A well-documented service with infrastructure-as-code, a working CI pipeline, and current runbooks can transition in weeks because most of the context is already written down. A system where deployment involves tribal knowledge and manually configured servers will take months regardless of how good the incoming team is, because the transfer is bounded by how fast one group of humans can explain things to another.

The useful framing is not "how long until the new team has the code" — that takes an afternoon — but "how long until the new team can handle a 3am production incident without calling anyone at the old vendor." That is the milestone that ends the transition, and it is the only one worth measuring. A transition plan that declares success at code handover has declared success at the easy part.

Plan the sequence so that the highest-risk knowledge moves first, while the outgoing team is still engaged and still being paid. Production incident response, deployment, and data integrity procedures come before feature roadmap context. If the relationship deteriorates mid-transition — which happens — you want to have already extracted the things that cause outages, not the things that cause missed sprints.

Do You Still Need Source Code Escrow?

For most custom development engagements, no — and this is a place where buyers often spend money solving a problem they do not have while ignoring the one they do.

Source code escrow is a tri-party arrangement in which a neutral agent holds deposited source code and releases it to the customer if the supplier fails to meet obligations or ceases trading. It was designed for a specific scenario: licensed software where the vendor retains the code and the customer has no access at all. If your engagement is custom development where you already own the IP and hold the repository, escrow is largely redundant — you have the code.

Where escrow still earns its place is the genuine dependency case: a vendor-hosted component you license rather than own, a proprietary tool embedded in your product, or a regulated context where a supervisor wants evidence of continuity arrangements. Even then, insist that deposits are verified and current. An escrow deposit that has not been updated in two years releases you a build that no longer matches production, which is a certificate of comfort rather than an actual remedy.

The more useful modern substitute for most buyers is boring and free: own the repository organisation yourself, require the vendor to work inside it, and ensure that a full clone plus your infrastructure-as-code plus a runbook is sufficient to rebuild the system from scratch. If your team cannot stand the environment up from what is in version control today, escrow would not have saved you either — the missing piece was never the code.

How Do You Run the Overlap Without a Knowledge Vacuum?

Structure it as documented, verifiable transfer with the incoming team doing the work under supervision — not as a series of meetings where the outgoing team explains things.

Meetings feel productive and transfer very little. The pattern that works is reversal: during overlap, the incoming team performs the actual operations — they run the deployment, they take the on-call rotation with the outgoing team shadowing, they fix a real bug end to end — while the outgoing team is available to unblock rather than to demonstrate. Anything the incoming team cannot do unaided is an unresolved gap, and you have found it while you still have someone to ask.

Insist that every transfer session produces a written artefact in your repository rather than a recording in someone's drive. A recorded walkthrough is nearly unsearchable at the moment of an incident eleven months later. A runbook in the repo is the thing your engineer opens at 3am.

This is also the point where the choice of incoming partner matters more than most buyers weigh at selection time. Teams that regularly inherit other people's systems handle this very differently from teams that mainly build greenfield — they arrive expecting undocumented context and they write things down as a reflex. It is a fair question to ask directly in a selection conversation: what proportion of your work is taking over existing codebases, and what does your first thirty days look like on an inherited system? At StepTo a large share of what our Belgrade-based dedicated teams pick up is exactly this — production systems built by someone else, with the documentation gap that implies — and the honest answer is that the first month is mostly reading, writing things down, and asking the previous team questions while they are still reachable. Any partner who describes inheriting a codebase as straightforward has probably not done it recently.

One structural warning: do not let the incoming team start rewriting during the overlap. The pull to refactor an unfamiliar codebase is strong and it destroys your ability to distinguish inherited bugs from newly introduced ones at precisely the moment you need that distinction. Stabilise, document, take ownership — then improve.

When Is Switching Vendors the Wrong Move?

Often enough that it deserves a section. Switching is expensive, disruptive, and frequently addresses a symptom rather than the cause.

When the real problem is your own specification quality. If requirements arrive late, change mid-sprint, or are never written down, a new vendor will produce the same disappointing outcome about four months in, and you will have paid a transition cost to learn that. The tell is whether the complaints are about quality of execution or about things being built that nobody wanted.

When you have no internal technical owner. A transition without someone on your side who can evaluate what is being handed over is not a transition; it is an unsupervised transfer of things you cannot assess. If nobody internally can read the architecture diagram, hiring that capability comes before changing vendors, not after.

When the relationship is recoverable and the issue is structural. A team assigned to too many accounts, an unclear escalation path, a pricing model creating bad incentives — these are contract and governance problems. Fixing them with your current vendor, who already has the domain knowledge, is usually cheaper than buying the same fix along with a knowledge gap.

When you are mid-way through something critical. A migration, a compliance deadline, a launch. Switching vendors during any of these compounds two hard problems into one much harder one.

The honest counterweight: when a vendor is genuinely not delivering, has resisted every attempt to fix it, and holds knowledge hostage as a retention strategy, switching gets more expensive the longer you wait — because the undocumented surface keeps growing. Decisiveness has real value here. The question is whether you are switching to solve a vendor problem or to avoid an internal one.

What Should You Do This Month?

Five things, none of which require you to be planning an exit. They are engagement hygiene, and doing them while the relationship is healthy is the entire point.

First, verify ownership: repository organisation, cloud accounts, DNS, CI/CD, monitoring, app store accounts, and third-party subscriptions should all sit in your company's name with the vendor holding access rather than title. Second, read your current contract's termination section and note what it actually obliges the vendor to do after notice — for most readers this will be a short and uncomfortable exercise.

Third, request a current architecture diagram, deployment runbook, and inventory of scheduled jobs and integrations. Treat the quality of the response as a health metric. Fourth, ask your team the operative question: if this vendor disappeared on Monday, what would break first, and who would know how to fix it? Write the answer down.

Fifth, at the next contract renewal — or now, if the relationship is good — add the four provisions above. A vendor confident in the relationship will sign them without much friction. A vendor who resists them is telling you that your dependency is part of their commercial strategy, which is itself the most useful information you will get this quarter.