How to Take Over a Software Project From an Underperforming Vendor
The decision to leave a vendor is usually made in a single meeting, after months of accumulated frustration finally cross a threshold — a missed deadline that cost a customer, a security question nobody could answer, an invoice that arrived for work nobody remembers approving. What almost never gets decided in that same meeting is what happens in the weeks immediately after.
A software project takeover is a knowledge-extraction operation with a legal relationship and a delivery commitment running on top of it. The biggest risk is rarely technical. It is behavioral: a vendor who senses they are on their way out does not always keep operating at full cooperation.
The three phases of a controlled takeover
A takeover run well moves through three distinct phases: Extract, Stabilise, Transfer. Each phase has a different owner, a different pace, and a different failure mode if it is skipped or rushed.
Phase 1 — Extract: get the knowledge and the assets out before the relationship ends
Extraction covers four workstreams: access, code, infrastructure, and documentation. All four need to move in the same window, because they depend on the same thing — a vendor who is still contractually obligated to cooperate.
Access means a complete, verified inventory of every credential, repository, third-party account, domain registration, and signing key connected to the system. Code means source code matched against what is actually running in production — not what the vendor's repository claims is current. Infrastructure means the deployment pipeline, hosting configuration, and the operational muscle memory of how releases actually happen. Documentation means everything that should exist but frequently does not, including a technical debt register naming every shortcut the current team knows about.
Phase 2 — Stabilise: shadowing and managed overlap, not a clean handoff date
A managed overlap period, where the incoming team works alongside the outgoing one rather than simply reading what they left behind, exists because documentation captures decisions, not judgment. The length of this phase should scale with system complexity, not with how quickly leadership wants the old vendor gone.
Phase 3 — Transfer: acceptance is an event, not a feeling
Acceptance needs explicit, written criteria agreed before the transition begins. Reasonable criteria include: the incoming team has independently deployed a release, has resolved at least one production incident without escalating to the departing team, and every item in the access and IP inventory has been verified as rotated or transferred.
What if the outgoing vendor will not cooperate?
The access and IP inventory is the one workstream that does not depend on cooperation at all, and it should be completed before the vendor is told the relationship is ending. Code and infrastructure extraction is harder without cooperation but not impossible — a codebase can be reverse-engineered from the code itself and from production behavior.
| Workstream | Phase | If the vendor cooperates | If the vendor does not cooperate |
|---|---|---|---|
| Access and IP inventory | Extract | Vendor confirms and hands over credentials directly | Rebuilt from billing records, DNS, and account ownership |
| Code (matched to production) | Extract | Vendor provides repository access and confirms production parity | Extracted from live production and reverse-engineered |
| Infrastructure and deployment | Extract | Walkthrough of pipeline, environments, and release process | Reconstructed from hosting provider configuration |
| Documentation and debt register | Extract | Vendor documents known issues and architectural decisions | Built independently through code review and system behavior analysis |
| Shadowing and managed overlap | Stabilise | Two to six weeks of joint operation | Not available; replaced with a longer, more cautious solo stabilisation |
| Acceptance and sign-off | Transfer | Formal sign-off with outgoing vendor confirming closure | Sign-off based on incoming team's independent verification alone |
How long does a software project takeover actually take?
The full sequence typically runs five to twelve weeks: five to ten business days for the transition readiness assessment, two to six weeks for knowledge extraction and shadowing, and two to four weeks for incoming team onboarding. A simple system with a cooperative outgoing vendor can land at the shorter end. A large, poorly documented system with an uncooperative vendor can reasonably extend well past twelve weeks.
Recognised this situation?
Five business days, fixed scope — a clear recommendation on what to do next.
Was this useful?
Frequently asked questions
How do you manage a software vendor transition without stopping delivery?
Through a managed overlap period rather than a single cutover date. The incoming team takes on production responsibility gradually, while the outgoing vendor's support decreases across a defined stabilisation window — typically two to six weeks — rather than ending abruptly on a fixed handover date.
What are the risks of switching software development vendors?
The three biggest are knowledge loss — undocumented decisions and operational judgment that leave with the outgoing team — delivery interruption during the handover, and inherited technical debt that was never disclosed. All three are manageable with a structured, phased transition.
How long does a software vendor transition take?
Typically five to twelve weeks end to end: five to ten business days for the readiness assessment, two to six weeks for knowledge extraction and shadowing, and two to four weeks for incoming team onboarding. Complexity, documentation quality, and vendor cooperation all affect where in that range a specific transition lands.
What should be in a vendor transition plan?
A complete access and IP inventory, verified source code matched against production, infrastructure and deployment documentation, a technical debt register, a defined shadowing or overlap period, and explicit written acceptance criteria for when the transition is considered complete.
When should we start transition planning?
Before the outgoing vendor is formally notified, wherever contractually possible. The access and IP inventory does not depend on vendor cooperation and can begin immediately, which matters because cooperation levels sometimes change once a vendor learns the relationship is ending.
What if we do not have a new vendor selected yet?
The extraction and access-inventory work still needs to happen on the current relationship's timeline. Completing that work first protects the knowledge regardless of how long the selection process takes.