Current state of the market
Time for radical change, the momentum is there, the need was already there, but finally the awareness is there. We need to discuss Exit Plans.
In the past months we have seen a lot of tariff increases by the American legislation, we have seen political unrest and recently even email accounts from members of the International Criminal Court were closed by Microsoft in May 2025 on direction of the American legislation. This prompts consideration of sanctions targeting your country, as policy changes can significantly impact businesses rapidly and without warning.
But lets be honest, policy changes through legislation are not the only factors affecting your business. While these policy changes and tariffs now raise the much needed awareness, there are plenty of other disruptions that can have an impact on your business. Suppliers can go bankrupt (example from this year, builder.ai), your Cloud Account can be locked due to cyber attacks causing overcharges, suppliers can decide to raise prices to unacceptable levels or vendors can even decide to stop doing business with you for any reason they see fit.
To give an anecdote: Been in a position where the supplier refused to add capacity to the Cloud quotas to allow to purchase extra services since they were at capacity in the Region and expected to add extra capacity within 3 months, this meant we could not grow our business for this period. The Supplier was one of the largest cloud providers in the world.
A single-vendor strategy often leads to lowest common denominator constraints, compelling reliance on vendor-specific solutions. This reduces solution quality, inflates costs, and restricts flexibility. Vendors may disable essential features or limit integrations. Vendors are known to remove key functionalities and features to ensure their solutions are tightly bound to their platform, even when these solutions are Open Source. For example AWS Cassandra offering does not support the ability to add your onprem datacenters while the Open Source solution allows it, locking your data to their platform. Azure Grafana Admin API is disabled, making it impossible to manage Grafana instances through code and tightly coupling your access management to Azure Entrada.
Additionally, proprietary data formats, restricting third party vendor integrations and high costs complicate vendor migration.
In some scenarios this impact can be monetary by missing sales, impact can be reputational or can lead to fines or even legal actions.
Assessing and Addressing Exit Risk
Although my posts usually focus on technology teams, it’s valuable for all departments, for example procurement, to reflect on how vendor consolidation decisions may impact business continuity. Here are some questions for self-reflection.
Question to Architects:
- If your organisation only has an Azure Unless policy, who are you serving with an Azure Unless policy? As an architect you have to deal with many different stakeholders, from the tech community in your organisation, management to procurement and more. Does your Azure Unless policy serve business continuity or operational convenience?
- Have you documented the business risks and communicated them to stakeholders?
- What mitigation strategies do you have in place to ensure that the business can continue to operate in case of failures and what are acceptable reasons to deviate from these policies?
- What business outcome does your Azure Unless policy achieve?
- How do you measure whether it’s serving strategic objectives versus creating operational dependencies?
Question to Engineers:
- How free are you in making technology decisions?
- Are you allowed to choose the best technology for the job or are you forced to use a specific vendor?
- Does the culture of the company allow you to bring up concerns about vendor lock-in and its implications on business continuity?
- Are you aware of the risks associated with vendor lock-in, such as increased costs, reduced flexibility, and potential disruptions to your operations?
- Are the functionalities available to you best in class or are you forced to settle for subpar solutions?
- How fast can you lift and shift your workloads to another vendor?
- Is your management aware of risks associated to vendor lock-in?
Question to Procurement:
- Are you aware that a vendor lock-in can have a negative impact on the business?
- Do you have a framework to facilitate procurement decisions regardless of the vendor?
- Do you facilitate vendor lock-in unintentionally by driving for single vendors?
In all the years I have been working in Technology this question was rarely asked, cultures often did not encourage or welcome these questions. In my experience the industry does not see vendor management as potential risk, there seems to be enough awareness but it is not a sexy topic. Preparing for this article I went through some frameworks and standards, vendor management is mentioned in some frameworks. Exit planning is not. Our industry describes in debt rotation policies, length, strength and format for our passwords. But it seems to have a blind spot when it comes to Exit Planning.
Do frameworks support Vendor Exit Planning?
ISO 22301 is the international standard for Business Continuity Management Systems (BCMS). It provides a framework for organizations to plan, implement, monitor, review, maintain, and continually improve their business continuity management system. However, ISO 22301 lacks specific directives for vendor exit strategies or vendor lock-in prevention.
ISO 27001 is the international standard for information security management systems (ISMS). It provides a framework for organizations to manage and protect their information assets. While it does not specifically address vendor exit planning, it does require organizations to assess and manage risks associated with third-party suppliers, which can include vendor lock-in.
NIST’s publications like CSF, SP 800-161, SP 800-171, and SP 800-53 guide third-party risk management, vulnerability identification, and security controls but they do not specifically address vendor exit planning or vendor lock-in. They do emphasize the importance of managing third-party risks. However, they do not provide specific guidance on how to plan for vendor exit or how to mitigate the risks associated with vendor lock-in.
Even if I missed segments from these frameworks describing vendor exit planning, my personal experience is that proper vendor exit planning is not a common enough practice in our industry. The lack of these guidelines however does not excempt us from improving upon these practices, they are a baseline, not a ceiling.
Counter arguments
Some may argue that vendor exit planning is not necessary because the risks associated with vendor lock-in are minimal or manageable. They may believe that the benefits of using a single vendor outweigh the risks, or that the costs of implementing an exit plan are too high.
Multi vendor strategies are more expensive, more complex, cause lack in knowledge and can overstretch teams and resources. Multi vendor strategies are a complete nightmare from an integration standpoint, duplicate and increase the costs of licensing, support and maintenance. These concerns aren’t theoretical; organizations regularly struggle with multi-vendor environments, experiencing longer project timelines, higher operational overhead, and increased failure points. Going for a general purpose solution can also cause lowest common denominator issues, which isnt exclusively tied multi vendors since I have seen in practice that this can also become an issue with single vendors limiting offered solutions in favor of their own. Volume discounts can result in seemingly lower operational costs. Not to mention about the security and compliance overhead. In some regulated industries this can be be even more of a headache. These concerns are legitimate and require careful consideration.
In some scenarios a single vendor strategy makes sense. For example in a Startup your aim is to get to market as fast as possible, your MVP needs to get delivered and business models need to be validated. Risk management on vendor lock-in are your lowest priority, you probably do not have the time to consider these risk factors.
Some vendor specific functionalities offer competitive advantages, this is also part of todays reality.
There is however a critical distinction: Exit planning does not mean you require multi vendor strategies. Exit planning clarifies risk tradeoffs. Even within an exit strategy it can be a perfectly valid decision to use a single vendor, what changes with applying this strategy is raising awareness. You shift from a reactive to proactive mindset. Risks are calculated, understood and a choice, not an afterthought.
In your design process you can evalutate the use of general purpose solutions, use open standards. Create Vendor Agnostic solutions whenever possible to be able to exit safely. Can a solution be resolved somewhere else in the stack? Evaluate middleware layers to reduce vendor dependencies. Evaluate open-source alternatives with similar functionality, the open-source community is amazing. Do you really need functionalities that are only available in a specific vendor’s solution?
You will always run into the scenario where you will be tied by technological decisions to a vendor, awareness is the first part of the journey. Second is integrating some of these abilities directly in your application landscape to reduce restriction. At the least evaluate what added value these functionalities bring to your business and if they are worth the risk of vendor lock-in. Perhaps vendors have their own version of these functionalities and migration can be performed faster than you think. You will never know until you ask these questions.
Prepare for the exit
Exit planning requires stakeholder input to establish acceptable vendor lock-in thresholds. Are critical components labeled as business critical and recognized as such within your organisation? What is the impact on components that are not labeled as critical? How do you enable and support exit strategies? For each organisation this decision will be different.
Next up is to evaluate competitive advantages versus the risk of vendor lock-in. What criteria does your organisation use to determine whether vendor lock-in is worth the risk? What level of ownership and control is possible within your organization to restrict the impact of these decisions? Can your engineering team manage and maintain solutions to mitigate these risks? Does your organisation have the experience, expertise, and capacity to maintain a translation layer or alternative solutions? And perhaps most important: What is the cost of not having these exit strategies in place? What is the cost of vendor lock-in? How does this impact your business continuity?
It all starts with the consensus within your organisation, does the organisation understand and accept risks associated with vendor lock-in? Are components labeled as business critical and treated as such? Do the same policies apply to all vendors, components and services?
Integrate exit planning into your design and review process. During this process evaluate the added value of vendor specific functionalities. Are there alternatives? What time would it require to implement functionalities directly in your application stack? Or what if you build a translation layer to abstract these functionalities? Perhaps a vendor offers a storage format which is comparable with other vendors, can a translation layer be built to allow for easy migration? Are there opensource solutions that mitigate some of these risks for you? Importantly: If you have a 50 person engineering team, can they maintain that exit strategy versus a 1000 person engineering team? Not likely, so ensure that the exit strategy is manageable and maintainable by your organisation.
Part of a relationship is making sure that when this relationship ends, you have the process around this exit documented. Ensure your contracts with vendors include exit clauses, but outside these clauses ensure that you are still the owner of the data and have the ability to extract this data at all times. Do not rely solely on contractual clauses. Do not assume that the ability to retrieve the data is guaranteed even if the vendor claims it is, to give a personal anecdote: This vulnerability became clear through direct experience: When I ended a contract with an Accountant, the software they used (Exact Online) had documentation where it stated that it was technically possible to retrieve data and a guide how to. The Demo environment from Exact also displayed this functionality. Great I thought, my data can be extracted at all times. However the documentation didnt clarify that this was only possible if the Accountant allowed this in their environment configuration. What made this scenario bitter sweet was that Exact Online refused to hand over the data, I didn’t have a contract with them, they had a contract with the Accountant. They acknowledged that I was the owner of the data, but refused to hand over this data since I was not their customer. Vendors understand that most organizations will choose the path of least resistance, even when they have legal rights, because they’ve designed the economics to make compliance cheaper than enforcement.
The Accountant used an extortion tactic and was only willing to provide this data if I paid 200 euro for this “exit service”, he knew that a lawyer would set me back thousands. In onboarding with this Accountant we even had a talk where the Accountant told me that I was owner of and at all times responsible for my tax returns. The Dutch law even states that my tax data should be mine… Having a clause in your contract where you can retrieve your data at all times is vital and gives the option to get legal support, but vendors know that these procedures are expensive and time consuming and can use extortion tactics to ensure the cost of their service is lower than the lawyer fee. In this case the Accountant exploited this advantage.
Could I have used the raw data and set everything up again in the new environment? Sure, but vendors know the time and effort it takes to import and enrich/clean raw data again. You can mitigate this scenario entirely by ensuring during your design, review and MVP process to retrieve data as part of your MVP. Another thing to consider is: How easy is it for your organisation to ingest the raw data from scratch again, how long does that take and how acceptable is this for your organisation? And if that isn’t acceptable, how can you extract and migrate the enriched data to another vendor?
Is having an exit strategy expensive?
Planning for an exit strategy can be expensive since it requires upfront investment in time, resources and expertise. It is essentially the downfall of having an exit strategy: It makes these costs to exit directly visible within your organisation. However, lacking an exit strategy conceals these costs. and can be much more expensive in the long run. These costs can include:
- Cost to regenerate data and ingest these in the new environment
- Cost due to downtime
- Cost of hiring external consultants to assist with the exit
- Cost of legal fees to resolve disputes with vendors
- Cost of lost business opportunities due to vendor lock-in
- And many more…
Some of these are easy to calculate, others are more difficult to quantify. Essential part of an exit strategy is to reach a balance where your team has the bandwidth to maintain the exit strategy.
What metrics matter most: Switching costs, time to migrate, business disruption, opportunity cost?
Acceptance
Vendor lock-in can sometimes be strategically justified. Evaluate carefully whether building on proprietary infrastructure aligns with your organisation’s strategic goals. Internal solutions may deliver competitive advantages or operational speed, but always weigh these benefits against the complexity and ongoing resource investment required to maintain them. Your organisation can build their own alternative to AWS infrastructure, but should it?
The critical point is not to avoid vendor lock-in at all costs, but to make deliberate, well-documented choices. Use your team’s capacity efficiently and ensure efforts are focused on delivering business value.
Ask the hard questions when evaluating your tech stack, document these decisions and accept it if vendor lock-in is the best choice. Clear documentation ensures stakeholders understand and accept the associated risks and trade-offs. There is no universal correct answer; what matters is that your decisions are conscious, transparent, and aligned with business objectives. Exit planning should be a shared responsibility: involve engineers, architects, and procurement alike, so that understanding and ownership of the risks are distributed across the entire organisation.
Next steps
In a follow up post I will go over some practical steps to implement exit planning, if you have any questions or suggestions before I write this post. Feel free to reach out to me on linkedin: https://www.linkedin.com/in/rogierdikkes/