It is a Thursday board meeting. The platform that was supposed to launch in June is six months late. The vendor sends a new schedule every fortnight, every change estimate comes back at twice the expected figure, and the last two releases broke the payment module. The CTO knows that staying with this vendor means more months of the same. The CTO also knows what the board is afraid of: that switching will stall the project for half a year, the code will turn out to be worthless, and the new firm will open with “this needs to be rewritten”.
That fear is reasonable, but it describes the wrong scenario. Projects do not die because they changed vendor. They die because they changed vendor chaotically: without securing access, without rights to the code, without an overlap period and without knowing what they were taking over. A well-planned handover is an operation of a few weeks with a clear scope, an owner and a budget.
This article is for a CTO who has made the call or is one step away from it. It lays out a 30-day takeover plan, the things to secure before you give notice, the factors that really move the cost, the questions to put to the incoming vendor and the signs that switching will not solve your problem.
When does switching vendors mid-project make sense, and when does it just move the problem?
Switching makes sense when the root cause sits with the vendor and cannot be fixed by talking. Typical signs are a lack of predictability (schedules that slip with no explanation of why), a rising number of regressions with every release, churn in the vendor’s team that forces you to explain the system from scratch every quarter, and a lack of transparency: you cannot see the code, you have no access to the backlog, and status reports say nothing concrete. If you recognise three of these and they have lasted more than a quarter, the “let’s fix this together” conversation has usually already happened and changed nothing.
Switching only moves the problem when its source is on your side. If scope changes every sprint, nobody in the business makes product decisions and acceptance drags on for weeks, the next vendor will walk into the same conditions and look exactly like the current one within six months. An honest test before deciding: write down the last three serious delays and name who caused each. If the answer is “we did” in two out of three, fix your own process first.
There is a third case: the vendor is fine but the system is not. Code built under time pressure, often with heavy use of AI assistants, can weigh so much that no team can ship changes on it at a predictable pace. We described the symptoms in seven signs a vibe-coded app needs rescuing. In that situation, switching vendors without assessing the code is a gamble: the new team inherits the same technical debt and starts by explaining why everything takes so long.
So the best first decision is not “we switch”, but “we find out what we have”. An independent code audit answers whether the problem is the team, the system or both, and its result turns a heated board discussion into a factual one.
What must you secure before telling the vendor you are leaving?
Sequence matters. The moment the vendor learns about the switch is the moment your negotiating position weakens and their motivation to cooperate drops. Anything you can secure earlier, secure earlier, as part of normal collaboration and without announcing the decision.
The first list is access. Check whose accounts hold the code repositories (GitHub, GitLab, Bitbucket), the cloud account and its billing, domains and DNS, certificates, CI/CD tooling, monitoring, the ticketing system, the password manager with production secrets, app store accounts and keys to third-party APIs and payment gateways. If any of these sit in the vendor’s account or a single developer’s account, move them to a company account now and frame it as a permissions clean-up. It is standard risk management, and no reasonable vendor should object.
The second list is code and data. Make sure you have a full copy of the repositories with their history, not just the latest state of the main branch. Check whether database migration scripts, infrastructure configuration and deployment pipelines are in the repository. Back up the production database and verify that the backup can actually be restored. Collect whatever documentation exists, even if it is out of date: every architecture diagram and wiki page shortens the reconstruction work later.
The third list is the contract, covered in the next section. Before giving notice you need to know your notice period, whether the contract obliges the vendor to hand over and transfer knowledge, who owns the code and on what terms, and whether there are penalties or minimum commitments.
The fourth item is a communication plan. Decide who tells the vendor and when, what handover offer you will make, and what you will do if they refuse to cooperate. A vendor offered a paid, fairly priced handover period cooperates far more willingly than one who is surprised by a termination notice and loses the revenue overnight.
Which contract terms decide whether a takeover can work at all?
Three areas of the contract decide whether the takeover will be a technical operation or a legal dispute: rights to the code, obligations on termination, and notice terms.
Rights to the code come first. Check what the contract actually assigns or licenses to you, when the assignment takes effect and which law governs it. Many contracts tie the transfer of rights to payment for each milestone, so disputed invoices can mean disputed code. If your vendor is in Poland, as many nearshore teams serving DACH and UK clients are, the Polish Copyright Act states that an assignment covers only the fields of exploitation expressly listed in the agreement (Art. 41(2)) and must be made in writing, on pain of nullity (Art. 53). A clause saying “all rights in the deliverables pass to the client”, without listing uses such as modification, distribution or combination with other software, may not give you what you need. This is a question for a lawyer, not the CTO, but the CTO has to raise it before anyone says “we are terminating”.
Obligations on termination are the second area. A good contract has an exit clause: an obligation to hand over code, documentation and access, a defined period for knowledge transfer and the rates for that time. If yours does not, all is not lost, but the handover becomes something you negotiate rather than something the contract delivers. Which clauses to have in place from the start is covered in software development contract clauses that protect the client. We cover how these dependencies form and how to guard against them in golden handcuffs in IT: how to avoid vendor lock-in.
For financial-sector firms in the EU there is also a regulatory requirement. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applicable since 17 January 2025, requires financial entities to have exit strategies for ICT services that support critical or important functions (Article 28(8)), and contracts for such services must include exit strategies with a mandatory adequate transition period (Article 30(3)(f)). If you are a bank, insurer or payment institution, replacing the vendor of a critical system is therefore a process that should be written down before you need it.
Notice terms are the third area: notice period, minimum commitments, penalties and how work in progress is settled. Calculate what a contractual exit costs, because that figure belongs in the takeover budget next to the new vendor’s price. The broader discipline here is vendor risk management.
What does a 30-day takeover plan look like, week by week?
The plan below assumes that the outgoing vendor cooperates at least minimally and that the system runs in production, albeit with problems. It is a framework for planning your own takeover, not a ready-made schedule for every project: a large system with many integrations, or a vendor who refuses to cooperate, will stretch every stage.
Week 1: access and inventory. The new team gets read-only access to repositories, documentation and monitoring. An inventory takes shape: repositories, services, environments, databases, integrations with external systems and scheduled jobs. The first control question is whether the new team can build the application from the code in the repository. If it cannot, that is the first, very important finding of the takeover. In parallel, you schedule knowledge-transfer sessions with the outgoing team.
Week 2: audit and knowledge transfer. The new team reviews the code, architecture, dependencies, security and deployment process, while the outgoing team runs sessions on what the code does not show: why things were built the way they were, which modules are fragile, which workarounds are known and which production incidents have happened. Every session ends with a written note in the repository, not just a recording. By the end of the week you have a first list of risks ranked by business impact.
Week 3: the first release under the new team’s control. The new team takes over the pipeline and ships a first release, ideally a small, safe fix, with the outgoing team present. This is the moment of truth: if the release works and can be repeated, the takeover has a foundation. In parallel, the missing pieces get rebuilt: instructions for standing up an environment, a deployment procedure, a backup restore procedure and minimal monitoring.
Week 4: handover of responsibility. The new team takes over on-call duty and ticket handling, and the outgoing vendor moves to a few hours a week of consulting or ends the engagement. The old team’s access is revoked and secrets are rotated. A plan for the following weeks is written: what gets stabilised first, which development work resumes and when, and which risks remain open.
After 30 days the system is not fixed yet. You have something more important: control over it, knowledge of what you took over and a plan based on facts. For what the rescue looks like after the handover, including the first 72 hours on a system in crisis, see our emergency stabilisation playbook for a failing IT project.
How do you run a knowledge transfer when the outgoing team has no motivation?
Knowledge transfer is the hardest part of any takeover, because it depends on people who have just lost a client. Their motivation is naturally low, and the knowledge you need lives mostly in their heads. Fortunately, part of this can be planned for.
First, pay for the knowledge transfer separately and explicitly. An engagement such as “four weeks, two people at half time, billed hourly, with a list of topics” is an understandable final contract for the vendor rather than a favour. The cost of those hours is small compared with the cost of reconstructing knowledge from code.
Second, structure the sessions. The new team prepares questions based on its code review instead of asking for “an overview of the system”. The most valuable topics are business rules embedded in code rather than documentation, known problems and their workarounds, the history of production incidents, integrations with external systems and the contacts on the other side, tasks done by hand (reports, data fixes, restarts) and the things the outgoing team “never had time to do”.
Third, write everything down where the new team will work: in the repository, in the wiki, in ticket descriptions. Recordings are a useful supplement, but nobody will watch twelve hours of video at 2 a.m. looking for the answer to one question.
Fourth, prepare for the scenario in which there is no transfer at all. The vendor may refuse, disappear or send people who do not know the system. Then the new team reconstructs knowledge from code, commit history, logs, tickets and conversations with business users. It is doable, but it takes longer and needs experienced engineers who can read someone else’s code with no author to ask. Budget for this scenario as a risk even if the vendor promises full cooperation.
What drives the cost of switching software vendors?
The cost of a takeover is not a single number. It is made up of several items, some visible in the new vendor’s proposal and some not. The table below sets out the factors that move the budget most and how to check them before you decide.
| Cost driver | What pushes it up | What brings it down | How to check before deciding |
|---|---|---|---|
| Overlap of two teams | No exit clause, vendor bills the handover at premium rates | Paid, planned knowledge transfer with a topic list | Read the contract, calculate the notice period and minimum commitments |
| State of the code and technical debt | No tests, duplicated logic, outdated dependencies | Tests on critical paths, readable architecture | Independent code audit before signing with the new vendor |
| Documentation and reproducible environments | Hand-configured environments, no deployment procedure | Infrastructure as code, documented pipeline | Ask whether anyone outside the team has built the app from the repository |
| Access and account ownership | Cloud, domains and tools in the vendor’s accounts | Everything in company accounts | Account inventory before announcing the decision |
| Rights to the code | Unclear assignment, rights tied to disputed invoices | Written assignment covering the uses you need | Legal review of the contract |
| Number of integrations | Many external systems, undocumented interfaces | Documented APIs, partner test environments | Integration list with owners on both sides |
| State of production | Weekly incidents, no monitoring | Stable production, alerting in place | Incident history for the last three months |
| Slower pace in the first weeks | Large, unknown system, no knowledge transfer | Small scope, good documentation | Budget a period with no new features |
The most underestimated item is the last one. For the first few weeks the new team is learning the system and will not ship features at the pace the board remembers from the best months of the previous engagement. If the roadmap assumes full speed from day one, the takeover budget will part ways with reality in the first month.
The second most overlooked item is the cost of leaving the current contract. Notice periods and minimum commitments can mean paying both vendors for a month or two. That is not an argument against switching, just a line that has to be in the spreadsheet.
How do you estimate the takeover budget before you get a proposal?
Before the new vendor sends a price, you can build your own estimate, accurate enough for a board discussion. The calculation below illustrates the method, not a price list: the figures depend on the size of the system, and the basis is our 2026 benchmark, in which a senior backend developer from Poland costs about €335–485 per day.
Start with the overlap period: two senior engineers from the new team for four weeks is about 40 person-days, or roughly €13,400–19,400 at those rates. Add the outgoing team’s time for knowledge transfer at their rates, and whatever the contract’s termination terms cost. Add the audit: at ARDURA Consulting the Code Health Audit starts from €4,500 and takes 1–2 weeks, and Technical Due Diligence, which adds team, scalability and open-source licence assessment, starts from €8,500 and takes 2–3 weeks.
Then reserve an amount for stabilisation if the system is struggling in production. According to the pricing on our Software Rescue page, the stabilisation phase costs €15,000–40,000 and takes 2–4 weeks, and a full recovery €40,000–150,000. The spread is wide because it depends on the size of the system and the scale of the problems, which is why a detailed estimate only comes after the audit. If an incoming vendor quotes stabilisation without looking at the code, they are pricing risk blind, and the cost of that uncertainty reaches you anyway, in the rate or in change requests.
Finally, add the cost of the slowdown. A simple approach: assume that in the first month after the handover the new team delivers clearly fewer features than at its target rhythm, and work out what that means for business deadlines. It will not appear on an invoice, but it is a real cost the board should know about before deciding.
A spreadsheet like this has one more benefit: it lets you compare the cost of switching with the cost of staying. Staying with a vendor who delivers half the plan and keeps causing regressions also costs money; it just spreads the bill across the coming months.
What should you do with the roadmap and business users during the takeover?
A takeover happens on a running business. Sales is waiting for a feature promised to a customer, support is logging bugs and the board is asking when normal pace will return. If you do not sort out these expectations before the start, each of these voices will try to grab the new team’s priorities in the first week.
The simplest rule: during the handover, freeze large functional changes, but do not freeze critical fixes or security updates. A new team asked to build a large feature in an unfamiliar system in its first week will either break it or deliver it at the expense of the audit and knowledge transfer, the very work that decides whether the takeover succeeds. Freezing everything, fixes included, means users pay for the vendor switch with bugs nobody repairs.
List the commitments with hard deadlines in the next two months: customer contracts, regulatory requirements, marketing campaigns that depend on features. For each one, decide up front whether the outgoing vendor delivers it during the notice period, the new team delivers it after the takeover, or the date moves. This list is one of the first documents the incoming vendor should see, because it changes the order of their work.
Set up one intake channel and one person who sets priorities. During the overlap it is easy to end up with the same bug reported to both teams, each fixing it in its own way, and both fixes reaching production at the same time. “One ticket, one owner, one branch” sounds trivial, but it saves several unpleasant days.
Finally, tell key business users what is changing and what to expect. They do not need contract details, but they should know that new features will arrive more slowly for a few weeks and that critical bugs will be handled as before. Surprised users quickly become the loudest critics of a switch, even when it is going to plan.
Should you take over the existing code or rewrite the system from scratch?
This question comes up in every takeover, and usually too early. A new team seeing someone else’s code for the first time has a natural tendency to conclude “this needs a rewrite”. Sometimes it is right. More often it is a reaction to unfamiliar code rather than a conclusion from analysis.
Rewriting from scratch means funding two systems for many months: the old one, which has to keep running, and the new one, which has to catch up with the old one’s functionality, including business rules nobody remembers but the code has implemented for years. Our Software Rescue page puts starting from scratch at typically 3–5 times the cost of a rescue. That is why the rewrite decision is best made on the basis of an audit, module by module, rather than for the whole system at once.
Good decision criteria are: can the code be tested, and can regression tests be put around the critical paths; does the architecture allow parts of the system to be replaced independently; does the technology have a future and can you hire people to work with it; and are the business rules known anywhere outside the code. If the answers are mostly yes, stabilisation and incremental rebuilding almost always beat a rewrite.
An intermediate pattern that works well in takeovers is incremental replacement: the new team stabilises what works and rebuilds the worst modules one at a time, routing traffic to each new part only once it passes its tests. It is the same pattern used in legacy modernisation, and we cover it in more detail in legacy system modernisation: cost and a staged plan without stopping the business.
Which questions should you ask the new vendor before signing?
The incoming vendor will tell you they will do it better. Your job is to check whether they have a takeover method, not just a team available. These questions separate one from the other quickly.
What does your first month in a taken-over project look like? A good answer describes the steps: access, inventory, audit, knowledge transfer, first release, taking over on-call. A bad answer is “we will start working on the backlog straight away”.
Will you price stabilisation before seeing the code? A vendor who quotes a fix without an audit is either guessing or planning to recover the difference through scope changes. A sensible answer is a fixed price for the audit and an estimate for further work after it.
Who exactly will work on the takeover, and what experience do they have with other people’s code? A takeover is work for senior engineers who can read code without its author. Ask about the actual team, not the headcount of the company.
What happens if a key person leaves the project? The answer should cover a replacement guarantee and a replacement time, written into the contract. When ARDURA supplies specialists, every engagement starts with a two-week satisfaction guarantee with a free replacement, and if a specialist leaves during the engagement we guarantee a replacement within 5 business days.
How will you make sure we do not end up here again with you? The best answer: code and accounts in your name from day one, documentation as part of the definition of done, IP assigned continuously and an exit clause in the contract. A vendor who proposes terms that make it easy to leave them usually does not intend to give you a reason to. For a fuller scoring framework, see our IT outsourcing vendor evaluation scorecard.
What are the red flags during a takeover?
Some problems only surface during the handover. It helps to know in advance which signals need immediate action rather than a line in the weekly report.
The code in the repository does not match what runs in production. Sometimes fixes were deployed by hand or from local copies. If the new team cannot build the version that is running from the repository, you have a code integrity problem that has to be solved before any further release.
The vendor delays handing over admin access. A few days is logistics; a few weeks is a strategy. Every day that control of production stays with the outgoing vendor is a risk you do not control.
The outgoing team changes during the knowledge transfer. If the people turning up to sessions do not know the system, the transfer is a formality. Insist on specific people, or change the plan and book the new team’s time for independent reconstruction.
The new vendor proposes a full rewrite after one week. That recommendation is possible, but it should come from an audit with a rationale for each module, not from a first impression. Ask for evidence and for a stabilisation alternative.
Nobody on your side owns the takeover. A handover needs decisions: what is frozen, which risks are accepted, when to move to the next stage. If nobody makes those decisions within days rather than weeks, the takeover will drift regardless of how good both vendors are.
How does ARDURA Consulting take over a project from another vendor?
We run takeovers from other vendors as part of Software Rescue, and we always start with an audit, because without one every statement about cost and timeline is a guess. The process on the service page has four phases.
The first is the Code Health Audit: a review of code, architecture, infrastructure and processes that ends with a technical debt report, a risk assessment and a remediation plan. It has a fixed price from €4,500 and takes 1–2 weeks; if you also need an assessment of the team, scalability and risks for the board or investors, Technical Due Diligence starts from €8,500 and takes 2–3 weeks. We describe exactly what the audit delivers in AI code audit in two weeks.
The second phase is stabilisation, lasting 2–4 weeks: fixing critical bugs, patching security holes and setting up monitoring. The third is technical debt reduction: systematic refactoring of the worst code, automated tests and documentation. The fourth, optional, is long-term maintenance under an SLA.
In a vendor transition we handle code and documentation takeover with a full audit, knowledge transfer from the outgoing team, infrastructure migration where needed and team scaling with our own developers to keep the pace of work. In critical situations we can start within 48 hours. If the audit shows that your team can handle the work and only needs more hands, it is more sensible to add senior engineers through staff augmentation than to buy a full rescue service. The report and action plan are yours, whoever you choose to carry them out.
What should you remember before deciding to switch vendors?
Switching vendors mid-project is not a disaster if it is an operation rather than a reaction. The difference comes down to a few things you can prepare in advance.
First, make sure the problem lies with the vendor or the system, not with your own decision-making; otherwise the next vendor inherits the same conditions. Second, secure access, code, data backups and documentation before you announce the decision. Third, have a lawyer check the IP clauses, when rights transfer and the exit terms, and if you are in the EU financial sector, your DORA obligations too. Fourth, plan the takeover in four steps: access and inventory, audit and knowledge transfer, first release under new control, transfer of responsibility. Fifth, budget every item, including the overlap, the exit cost and the slower pace in the first weeks.
And most importantly: do not decide “take over” or “rewrite” without an independent assessment of the code. An audit costs a fraction of a wrong call in either direction.
If you are considering a vendor switch, see how Software Rescue works or book a call. We will tell you where to start in your situation, whether you need an audit and what the first month of a takeover could look like.