How do you switch software outsourcing vendors without stalling the roadmap?
You switch outsourcing vendors safely by running a structured transition — overlap the incoming and outgoing teams for four to eight weeks, transfer knowledge into artefacts rather than conversations, and take back control of every account and credential before the old contract ends. Companies that skip the overlap and terminate first typically lose a full quarter of delivery.
Switching is common and rarely a catastrophe. It becomes one when the exit was never designed — when the outgoing supplier holds the cloud accounts, the domain registrar, the CI secrets and the only person who understands the billing service.
When is it right to switch vendors?
| Signal | Fixable with the current vendor? |
|---|---|
| Senior engineers quietly replaced by juniors | Sometimes — escalate once, with named replacements demanded in writing |
| Estimates consistently double, quality static | Sometimes — often a requirements problem on your side |
| You cannot speak to the engineers directly | Rarely — that layer is usually their business model |
| Refusal to accept EU governing law, audit or data-residency terms | No |
| Code, infrastructure or accounts held as leverage | No — switch, and treat it as urgent |
| Strategy shift: from project delivery to an in-house-style team | Not a failure — a different model is simply needed |
Diagnose honestly first. A meaningful share of failing engagements fail on the buyer's side — unclear ownership, absent product decisions, a backlog written as instructions. Changing supplier will not fix any of those, and you will repeat the experience. If the underlying issue is the engagement model rather than the people, compare the alternatives in staff augmentation vs managed services vs freelancers before starting a search.
What should the exit clause say?
Read your current contract before you tell anyone you are leaving. The clauses that determine how expensive the switch will be are:
- Notice period — 30 to 90 days is normal; check whether it can run concurrently with the transition.
- Transition assistance — a defined obligation to support handover at agreed rates, for a defined period. Without it, cooperation ends at termination.
- Deliverables on exit — source code, infrastructure-as-code, credentials, documentation, CI configuration, design files, and any data the supplier holds.
- IP assignment — present assignment, not a promise to assign on final payment. Verify it was executed by the individual engineers, not only the company.
- Non-solicitation — check whether you may hire the engineers you have worked with for two years, and at what fee.
- Data deletion — certified deletion of personal data at the end of processing, as your Article 28 agreement requires.
If you are negotiating a new contract now, fix these first. The IP and data-protection detail for India-based suppliers is covered in our guide to GDPR, IP and contracts when outsourcing to India.
What if the vendor controls the code or the accounts?
This is the situation that turns a routine change of supplier into a crisis, and it is more common than most boards realise — particularly where the original engagement started as a small project and grew without anyone revisiting the paperwork.
Work through it in order. First, establish what you actually own: a present IP assignment gives you the code regardless of who currently hosts it, whereas a promise to assign on final payment does not. Second, identify the accounts registered to the supplier's email domains — cloud, registrar, app stores, error tracking, payment providers — since each of those is a separate recovery process with its own proof-of-ownership requirements, and app-store transfers in particular can take weeks. Third, get the invoices settled, because an unpaid balance is the leverage that keeps a reluctant supplier from cooperating. Only then open the conversation about leaving. Involving a lawyer early is cheap; involving one after access has been revoked is not.
What does a transition plan look like?
| Phase | Duration | Focus |
|---|---|---|
| 1. Inventory | 1–2 weeks | List every repository, account, credential, domain, pipeline and third-party contract, and who controls each |
| 2. Take control | 1–2 weeks | Move ownership of cloud, registrar, app stores and CI to your own organisation accounts |
| 3. Overlap | 4–8 weeks | Both teams active; incoming team ships small changes while the outgoing team still answers questions |
| 4. Shadow reversal | 2–4 weeks | Incoming team owns delivery; outgoing team on standby only |
| 5. Close | 1 week | Access revoked, data-deletion certificate obtained, final invoice settled |
Do phase two before you announce anything. Recovering a cloud account or an app-store listing from an uncooperative supplier is the single most common way a transition turns into a legal dispute.
How do you transfer knowledge that only lives in people's heads?
Knowledge-transfer sessions are the weakest form of handover: they happen once, at the wrong time, and nobody remembers them. Demand artefacts instead, and make them contractual deliverables of the transition phase.
- A service catalogue — one page per service: purpose, owner, dependencies, deployment path, failure modes.
- Runbooks for every recurring operational task, including the ones done manually once a month.
- Architecture decision records for the last two years, or at minimum a written rationale for the five decisions the incoming team will most want to reverse.
- A reproducible environment — the incoming team must build and deploy from a clean machine using only committed instructions.
- Recorded walkthroughs of the two or three subsystems nobody wants to touch.
The acceptance test for the whole transition is simple: the incoming team deploys a real change to production without asking the outgoing team anything.
How do you keep the outgoing team cooperative?
A supplier that knows it is being replaced has little incentive to hand over well, and its best engineers will be reassigned to paying accounts first. Three things preserve cooperation:
- Pay properly for the transition. Treat handover as billable work with a defined scope, not as an obligation squeezed out of goodwill. It is the cheapest insurance in the process.
- Name the people. Agree which specific engineers stay through the overlap, and make final payment contingent on the artefacts being delivered rather than on the calendar.
- Stay professional in writing. Transitions frequently end in a reference conversation or, occasionally, a renewed relationship on a different scope. Nothing is gained by conducting it as a dispute.
Where the relationship has already broken down, invert the approach: shorten the overlap, rely entirely on artefacts you can verify, and accept a larger temporary throughput loss in exchange for a clean break.
How do you avoid needing to switch again?
Most repeat switches trace back to the same three omissions in the original engagement. Close them in the new contract:
- Everything lives in your accounts. Cloud, registrar, app stores, CI, error tracking and analytics belong to your organisation, with the supplier holding named user access you can revoke in an afternoon.
- You interview the engineers. Named individuals with a notice period and an approval right over substitutions, not roles on a rate card.
- Documentation is a deliverable. Runbooks, architecture decision records and a reproducible environment maintained continuously — not assembled during an exit, when incentives are worst.
Get those three right and a future change of supplier becomes a staffing decision rather than a rescue project.
How much does switching cost?
Budget for paying two suppliers during the overlap, a temporary drop in feature throughput of roughly 20–40% for six to ten weeks, and some remediation of shortcuts inherited from the old codebase. Against that, the recurring saving is usually a better rate card and materially higher delivery quality — most switches pay back within two quarters.
The larger risk is repeating the original mistake. Run the new selection properly: interview the named engineers, insist on direct access to them, check references including one client who left, and negotiate the exit clause before signature. The full evaluation framework is in how to choose a software outsourcing partner in Europe.
ILMTEC takes over in-flight European products regularly and builds dedicated senior engineering teams that run inside your organisation's own accounts and repositories — so the next transition, if there ever is one, costs you a handover rather than a rebuild.
