Risks of changing your software vendor: 10 pitfalls worth knowing before you terminate the contract

In this article I discuss 10 risks that come with changing your software vendor. The first five are the obvious risks – the ones every CTO and Head of Product expects when they sit down to make the decision. The next five are the non-obvious ones – the ones that surprise you only in the middle of the process.

In short

• Changing software vendors is a separate project with its own budget, risks and schedule. Treating it as a simple administrative operation is the most common mistake.
• The five obvious risks (loss of knowledge, drop in pace, exit costs, lack of access, poor documentation) are well covered in contracts. The five non-obvious ones (opportunism of the departing vendor, the “let’s rewrite everything” syndrome, a window for blame-shifting, security gaps during the handover of permissions, shared components) usually are not.
• A temporary velocity drop of 20–35% over 4–8 weeks after the takeover is the normal price of change. A 50% drop lasting half a year is a sign that the takeover process was poorly planned.
• You reduce the most risk before you terminate the contract, not after. An audit of access, IP and documentation carried out before your current vendor learns about the decision gives you a few weeks’ head start.
• The longer the cooperation with the previous vendor lasted, the higher the probability that the non-obvious risks outweigh the obvious ones.

Why the decision to change vendors usually comes too late

Contrary to appearances, boards rarely make the decision to change vendors hastily. Quite the opposite. Most companies are well aware of how costly and risky such an operation is, and it is precisely this awareness that makes them give the current vendor more chances for too long. As a result, the decision is made only when the state of the project is already much worse than it was when the first serious warning signs appeared.

The paradox is that the longer you wait, the more most of the risks described in this article grow.

Obvious risks of changing your software vendor

1. Loss of system knowledge along with the departing team

In every custom software project that lasts longer than a year, knowledge gradually accumulates that cannot be read from the code itself. These are architectural decisions made as compromises, integrations that look different today than they once did, or business logic that is hard to write down because it has changed many times. This knowledge is held by specific engineers on the vendor’s side – and when they leave the project, it disappears with them.

Research on turnover in engineering teams describes this problem as “architectural knowledge vaporization“. When a tech lead leaves a project without first passing on the rationale for their decisions, the team loses understanding of trade-offs that aren’t visible in the code itself. The new team knows “what” was done, but doesn’t know “why”. The effect is that for a long time you can only safely introduce minor changes – until that “why” is rediscovered.

What to do about it.

Accept that you won’t recover part of the architectural knowledge – the “why” behind many decisions exists only in the heads of the people who made them, and reconstructing it after the fact is usually the work of the new team, not the departing one. Three things realistically improve the situation.

First: a concrete list of questions for the departing vendor instead of a request for “documentation” – 30 precise questions stand a chance of getting answered, an open-ended “describe the architecture” usually yields nothing.

Second: short, recorded walkthrough sessions of key modules – it’s easier to negotiate 2 hours of screen-share with the person who wrote a given piece of the system than 200 pages of documentation produced after the fact.

Third: as soon as the new team takes over the code, have them start writing characterization tests that lock in the system’s current behavior (even with bugs). You won’t recover the “why”, but you’ll secure the “what” – and that’s enough to safely refactor later.

2. Measuring the first weeks of takeover by the number of features

The board – frustrated by the previous vendor’s derailed roadmap – expects quick proof that the change is working. The simplest proof that comes to mind is new features in production. This is a metric that systematically misleads in the first 4–8 weeks after the takeover.

In a well-run takeover, the new vendor delivers something more valuable than another feature in this time: regained control and information on which further decisions can be based. A code audit report with a debt valuation, a working CI/CD, and so on. If the board measures this by the number of tickets closed per sprint, the first weeks look like regression – “we’re paying more and getting less done” – and trust burns out before the new relationship has a chance to prove its value.

What to do about it. Don’t sell the board on a “stabilization window” – after experiences with the previous vendor patience is already gone, and a 4–8-week pause without visible output is often simply a “no go”. Instead, demand from the new vendor a plan with measurable output week by week: regained access, audit report, working CI/CD, baseline characterization tests and a commitment to the first concrete business increments. The board can accept measurable week-by-week progress. If the new vendor cannot propose such a plan, they themselves are only just starting to learn the project – and then 4 weeks turn into 4 months.

3. Hidden costs of separation: contractual penalties, fees for handover support, double invoices

It is rare for parting with the current vendor to be cost-free. Project Management Institute materials point to typical fees associated with ending cooperation: penalties for early contract termination (the closer to the start of the contract, the higher they are), fees for so-called “transition assistance” (i.e. support during project handover by the previous vendor), as well as the notice period – usually 90 days – during which you pay for the full scope of services, although their real value usually drops.

On top of that comes the time when both vendors operate in parallel. Most often such an overlap period lasts 4–8 weeks, and during this time the company pays for both partners’ services simultaneously. This is an expense that is usually not included in the same spreadsheet as potential savings — which is why these numbers never really meet.

What to do about it. Review the contract for exit costs even before the decision to change vendors – this is one of the facts on which that decision should be based, not its consequence. Check with a lawyer the difference between “termination for cause” (vendor’s fault – usually without penalties) and “termination for convenience” (your own decision – with penalties). If you have evidence of SLA non-compliance (uptime indicators, list of regressions, missed deadlines), the exit cost may turn out to be significantly lower than you implicitly assume – which actually changes the answer to the question “can I even afford to change vendors”.

4. Incomplete access to code, repositories and infrastructure

In theory, you own the code because that’s what the contract says. In practice, in many companies it is the current vendor that is the administrator of the GitHub or GitLab organization. They are the one with access to the AWS account, the payment gateway, the monitoring tools.

This phenomenon is referred to as vendor lock-in and most often it is not the result of bad will, but of convenience. The client does not want to manage access on their own, so they hand off this responsibility to the vendor. After a few years it turns out that regaining full control is at least two weeks of work and difficult conversations – before the new vendor can even start working.

What to do about it. Before you terminate the contract, discreetly check all access. Make sure that the GitHub or GitLab organization is set up under your name, not the previous vendor’s. Verify whether the AWS, Azure or GCP accounts are actually registered to your company. Check who owns the domains, SSL certificates, App Store and Google Play accounts. Also determine who controls the keys to the payment gateway, analytics tools and email-sending systems. If you notice gaps, start gradually filling them in even before making the official decision to change. You’ll find more on the IT project takeover process in a separate article.

5. Insufficient or outdated documentation

Documentation in custom software projects has the disadvantage that it ages faster than the code itself. An architecture diagram created during the fifth sprint represents, two years later, a system that looks completely different by now.

The situation is not yet problematic as long as people who know the system are working on the project. The trouble appears the moment they leave and new team members need to be onboarded. Outdated documentation is more harmful than no documentation, because it gives a false sense of certainty. The new team bases its actions on a document describing the past state of the system and only encounters discrepancies during the work itself.

What to do about it. Before you terminate the contract, ask the vendor to update the most important documents: the current architecture diagram, descriptions of how the key system features work (e.g. authorization, payments, notifications), instructions for setting up the development environment, and a list of dependencies and the library versions in use. Treat this as part of ongoing cooperation, not as an “extra service”. Be aware that documentation prepared under the pressure of separation may not be as thorough as that prepared on an ongoing basis – but it’s still better than none. The new team will probably have to verify and supplement it anyway by analyzing the source code.

Non-obvious risks of changing your software vendor

6. Opportunistic behavior of the departing vendor

This risk almost never appears in analyses, because it is hard to openly state that the people on the other side of the contract may not act fully fair. Unfortunately, research shows that this is more the rule than the exception. Smite and Moe in their study describe that the departing vendor almost always goes through a phase of negative emotions – shock, frustration, fears about their future – and this often results in opportunistic behavior during knowledge handover.

Opportunism rarely takes the form of open sabotage. It manifests itself in a less obvious way. The handover of knowledge is shortened because “the key people are sick”. Documentation is produced, but contains mostly general information, omitting the truly important parts. Replies to the new team’s email questions arrive with significant delays. Selected components are labeled as “proprietary” and are not shared. Each of these behaviors can be easily explained, every single decision may seem logical. Yet in total this leads to a project delay of even several months.

This risk is greater the more personally attached the departing team was to the product. Engineers who built the system for five years treat the termination as a personal failure, even if the decision was formally made by their employer. Hence the reluctance to “teach the competition”.

What to do about it. Carry out the separation with class and in a professional manner, without unnecessarily emphasizing your own advantage. Communicate the change of vendor in a way that does not make the engineers feel humiliated. In the contract with the previous vendor, set precise and measurable conditions for the project handover — define the number of hours of onboarding sessions, the maximum response time for the new team’s questions, and a detailed list of documents and materials to be handed over. Make sure that payment for the transition period depends on the actual handover of these materials, not just on the passage of time. A good practice is also to add a clause allowing you to verify whether the handover was actually carried out as agreed.

7. The “better rewrite everything from scratch” trap with the new vendor

This is one of the most common patterns when taking over IT projects. The new vendor, after receiving the code, quickly proposes rewriting it from scratch. The arguments cited are technical: outdated technology, low architectural quality, lack of tests or growing technical debt. Although each of these reasons may be justified, the decision for a complete rewrite is not always actually the best solution.

Why not always? For two reasons. First, rewriting the code from scratch gives the vendor a significantly higher margin than gradual refactoring, so it is naturally more profitable. Second, a rewrite means many months in which the product gains no new business value, and during this time the risk of regression bugs significantly increases. Joel Spolsky once stated that rewriting a system from scratch is “the single worst strategic mistake that any software company can make”. This view is still widely cited, because it still fits most situations in the industry today.

It happens that during a system takeover an expectation arises to rewrite the entire code from scratch. However, after carrying out an audit it often turns out that a significant part of the code – for example around 70% – can be kept in use. The biggest challenges usually concern several areas, such as technical debt in the integration layer, lack of CI/CD, lack of monitoring, and lack of characterization tests. Only after bringing these elements to the expected level can you substantively decide which parts actually require a complete rewrite.

What to do about it. Before you accept a rewrite plan, demand from the new vendor a concrete justification per module. Have them indicate which elements are suitable for refactoring and which truly need to be rewritten. Require a preliminary audit and a takeover plan that balances paying down debt with delivering new business value.

8. Shifting blame onto the previous vendor as a long-term excuse

This risk usually surfaces only several months after the project takeover and belongs to the harder ones to spot. After a vendor change, every failure, delay or regression bug can be explained as a “legacy from the predecessor”. Sometimes that is indeed the case, but not always.

The problem is that during the first months after the vendor change the client is usually unable to assess when the new team’s explanations stop matching reality. “Old debt” becomes a universal excuse for any delay or error. After half a year you may realize that the new vendor not only failed to solve the old problems, but added their own – yet everything is still being blamed on the “legacy from the predecessor”. The trust that was supposed to be rebuilt with the change of vendor in fact does not grow, and the new team effectively avoids responsibility, still excusing itself with the past.

What to do about it. In the first month after the project takeover, ask the new vendor to prepare and share a list of “inherited debt” — that is, specific things that need to be fixed, with an estimate of the time and cost of fixing each item. Each item should also have a defined deadline. After three months, return to this list and check progress. If new tasks marked as “old debt” keep appearing on it, while the earlier ones still haven’t been resolved — that’s a signal that there is a problem. It is also worth setting measurable indicators that are hard to manipulate, e.g.: the number of incidents in production, the average lead time for changes, or the frequency of regressions.

9. The risk of security gaps during the handover of permissions and keys

During a vendor change, the organization goes through a period in which dozens of permissions, keys and access credentials change owners. The old team still has access to production, because it has to support the handover. The new team already has access, because it has to start working. Some accounts get forgotten, some passwords are never rotated, some former employees of the old vendor still have working SSH keys.

This is the moment when the system’s security is particularly exposed, and it is rare for anyone to prepare for it properly. Analyses of the operational risk of poorly managed vendor changes show that the most serious gaps appear precisely in the permission handover phase.

On top of that there is the regulatory issue. If the old vendor had access to personal data (GDPR), you have an obligation to document the deletion of that data after the cooperation ends. Neglecting this point may cost more than the entire migration.

What to do about it. Start with an inventory of all accounts, keys and access that the old vendor ever received. Indicate a cut-off date after which each of them will be rotated or revoked. Order a mandatory rotation of SSH keys, API tokens, database passwords and payment-gateway keys. Check the commit history for accidental disclosures of access credentials – this is a more frequent problem than it seems. Consult with a lawyer the process of deleting personal data on the side of the departing vendor and require written confirmation.

10. Shared components and libraries that stay with the old vendor

This risk applies particularly to those vendors who run many projects based on their internal framework. “We have our own authentication system, we use it in 30 projects.” At first glance this sounds beneficial – until the moment you decide to change vendors and it turns out that this proprietary module is the intellectual property of the IT company, not yours. Formally, all the code of your product belongs to you. In practice, however – without access to their authorization module – your system simply will not start.

In code-ownership contracts, so-called “reusable” components, which belong to the vendor, are often omitted. In practice, then, it may turn out that a significant part of your system is formally “under license”, but after the cooperation ends the vendor is no longer obliged to extend it. In such a situation, the new team must either rewrite these elements from scratch (which can take from a few weeks to several months) or negotiate with the previous vendor for the possibility of further use – usually on not very favorable terms.

The same applies to open-source libraries with additional modifications, administration tools, proprietary testing frameworks, custom CI/CD plugins. All of this may be yours formally, and practically unusable without cooperation with the predecessor.

What to do about it. Before you submit your termination notice, ask your current vendor for a full list of all reusable components used in your project, along with information about their legal status. Review the intellectual property provisions in the binding contract. If they are worded generally (“the client owns the code”), they may turn out to be insufficient in practice. During the audit performed by the new vendor, also ask for an analysis of dependencies on libraries created by the previous contractor – this is an aspect that often generates the highest costs during a project takeover. Vendor lock-in in IT projects often takes precisely this form: formally it does not exist, but in practice it makes a smooth system takeover impossible.

Summary

Changing software vendors almost always turns out to be much more complicated than can be inferred from the calculations presented in Excel.

The most important thing you can do before terminating the contract is to carry out a discreet audit of the current state of the project. Equally important is choosing a new vendor that, before pricing the takeover, will independently carry out a code audit and present a concrete takeover plan, taking into account both paying down technical debt and further business development.

If you spot more than two or three of the risks listed above in your situation, first commission us for an independent assessment of the situation before you decide to terminate the contract. Making a decision based on a complete picture of the threats is much less costly than correcting it later in the middle of the migration.