The best time to plan your exit from a software vendor is before you sign the initial contract. Exit planning is not pessimism — it is the foundation of negotiation leverage and the primary mechanism for preventing vendor lock-in from compounding over time.
When Broadcom acquired VMware in 2023 and subsequently imposed price increases of 200–340% on customers with no viable migration alternative, the consequences were not accidental. They were the predictable result of customers who had signed deep, multi-year commitments without data portability clauses, without testing alternative infrastructure, and without a documented exit strategy. The customers who navigated the Broadcom repricing most effectively had one thing in common: they had already modelled the cost and complexity of migration before the crisis hit.
Exit strategy planning is a core component of the Enterprise Vendor Management Framework and directly supports your negotiation leverage at every stage of the vendor relationship. A vendor who knows you cannot leave is a vendor who will charge you accordingly. This guide explains how to build an exit strategy for every major software relationship — before you sign the first contract, and maintained as a live document throughout the relationship.
An exit strategy is a documented plan — maintained and updated annually — that describes how your organisation would migrate away from a given vendor within a realistic timeframe. It does not mean you intend to migrate. It means you have thought through the steps, estimated the costs, identified the prerequisites, and ensured the contractual rights are in place to make exit feasible.
A complete exit strategy document for any major vendor should cover six areas: the technical migration path, the data extraction and portability requirements, the contractual rights to execute exit (including termination for convenience rights and post-termination data access), the estimated total cost of migration, the realistic timeline, and the alternative vendor or solution being considered. Organisations that maintain this document for all tier-1 vendors consistently negotiate better terms at renewal — not because they wave the document in the vendor's face, but because the vendor senses a customer who understands their real options.
Software vendors create lock-in through five primary mechanisms, and understanding which applies to each of your relationships determines the difficulty and cost of exit.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
| Lock-In Type | Description | Severity | Primary Examples |
|---|---|---|---|
| Data Lock-In | Data stored in proprietary formats or inaccessible without vendor cooperation | HIGH | Salesforce, Oracle DB, SAP HANA |
| Integration Lock-In | Deep API and workflow integration makes replacement technically complex | HIGH | ServiceNow, Workday, SAP ERP |
| Skills Lock-In | Internal staff expertise is vendor-specific; alternatives require retraining | MEDIUM | Oracle DBA, SAP Basis, Salesforce Admin |
| Contractual Lock-In | Multi-year commitments, termination fees, or no termination for convenience rights | MEDIUM | Oracle ELA, VMware Enterprise, Microsoft EA |
| Process Lock-In | Business processes have been designed around the vendor's specific workflow model | MEDIUM | SAP S/4HANA, Salesforce CPQ, Workday |
| Commercial Lock-In | Pricing model creates dependency — e.g., ELA with annual true-up creates perpetual renewal pressure | LOWER | Oracle ELA, Microsoft EA, Salesforce EA |
The most dangerous lock-in situations combine multiple types simultaneously — typically data lock-in, integration lock-in, and contractual lock-in together. This is the profile that enabled Broadcom/VMware to impose its 2024 repricing without significant immediate customer defection. The same dynamic exists for Oracle customers who have not invested in infrastructure portability and for SAP customers deeply embedded in S/4HANA workflows.
Oracle ELAs and SAP RISE contracts both create multi-layer lock-in. An Oracle ELA typically lacks termination for convenience rights, restricts data portability through proprietary format dependencies, and is supported by a support structure that creates skills lock-in. Planning exit from these relationships before signing is essential — not optional. See our Oracle negotiation guide and SAP RISE review.
Exit planning difficulty and required lead time varies significantly by vendor category. The following framework provides a starting point for exit planning across the major enterprise software categories covered on this site.
ERP exit is the most complex and expensive category — typically 3–7 year migrations requiring board-level commitment. The goal of exit planning here is not to plan for migration in the next renewal cycle, but to: (a) ensure the current contract includes data export rights, (b) avoid technology choices that compound lock-in, (c) maintain an updated cost model of what exit would require, and (d) ensure enough contractual flexibility to extend the current relationship while a migration is planned and executed. For SAP S/4HANA, exit planning should be a standing agenda item at every strategic review.
Cloud exit planning focuses primarily on architecture decisions that preserve portability: containerisation over proprietary managed services where possible, infrastructure-as-code that is not provider-specific, and data storage in formats that can be exported without transformation. For Microsoft MACC and AWS EDP commitments, the exit plan should model the cost of commitment break versus the cost of migration and address the scenario of committed spend exceeding actual usage.
Salesforce data is exportable via standard APIs, but the volume of data and the complexity of custom objects can make extraction time-consuming. The exit plan should include a tested data export process, a target platform (Dynamics, HubSpot, or a purpose-built alternative), and an estimate of customisation rebuild costs. For organisations deeply embedded in Salesforce's platform (custom objects, Flow automation, Apex code), the rebuild cost is typically the primary exit barrier — not the data extraction itself. See our Salesforce vs Dynamics comparison.
The VMware situation has made virtualisation exit planning a board-level priority for many enterprises. The primary alternatives — Nutanix AHV, Microsoft Hyper-V, Proxmox, and OpenShift Virtualisation — each have different migration complexity profiles. Our VMware alternatives comparison provides a detailed analysis. Exit planning requires a full inventory of VMs, an assessment of which workloads can migrate most easily, and a phased migration plan that begins with non-critical workloads.
Exit planning must be supported by contractual provisions negotiated into the initial agreement. Once signed, these rights become very difficult to add retroactively — vendors have little incentive to reduce their lock-in during the relationship. The following provisions are the most important to include.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
The right to terminate without cause, with reasonable notice (30–90 days for SaaS, 90–180 days for complex enterprise software), is the single most important exit provision. Many vendors push back on this — particularly for multi-year commitments — but it is negotiable in most cases, especially in exchange for commitment certainty on your part. See our guide to termination for convenience clauses for model language.
The contract should specify: the formats in which your data will be made available on export, the timeline for providing export data following notice of termination, whether the vendor will provide migration assistance or API access for transition, and the period during which data remains accessible after contract end. For cloud-hosted SaaS, standard export formats (CSV, JSON, XML) are the minimum; for complex platforms, API-based migration access is often necessary. See our data portability negotiation guide.
Negotiate a read-only access period of 90–180 days following contract termination. This provides the runway needed to complete data extraction and migration without artificial time pressure created by the vendor cutting access on the last day of the contract.
For on-premise software or hybrid deployments where business continuity depends on the vendor's software, source code escrow ensures continuity if the vendor becomes insolvent, is acquired, or discontinues the product. Our software escrow guide covers the design and negotiation of effective escrow arrangements.
Negotiating a new enterprise software contract?
Data portability — your right to extract, own, and migrate your data — is the technical foundation of vendor exit. Without it, contractual exit rights are largely theoretical. The following principles should guide data portability planning for any major vendor relationship.
Test your export before you need it. Many organisations discover data export limitations only when they actually try to leave. Build annual data export tests into your vendor management calendar — not full migrations, but sample exports of key data entities in the formats specified by your contract. This surfaces format issues, volume limitations, and API rate restrictions before they become crisis-level problems.
Understand what your data looks like in transit. For complex platforms like SAP or Salesforce, the raw data export may require significant transformation before it can be imported into an alternative system. Factor transformation cost and complexity into your migration cost model.
Secure your data independently of vendor infrastructure. For critical data sets, maintain a regular export to your own storage (cloud or on-premise) independent of the vendor's backup infrastructure. This ensures you have a recent copy of your data even if the vendor restricts access following a contract dispute.
Every exit strategy should include a realistic exit cost model. This is not intended to discourage exit — it is intended to ensure you have an accurate picture of the real cost of staying versus leaving. The components of exit cost for most enterprise software relationships include:
For major ERP migrations, total exit costs frequently range from 1.5x to 3x the annual contract value. For SaaS platforms with lower integration complexity, exit costs may be 0.25x to 0.75x annual contract value. These benchmarks vary significantly based on the depth of customisation in the current environment.
The relationship between exit planning and negotiation leverage is direct and well-documented. Vendors invest significant resources in understanding their customers' switching costs — and price accordingly. A customer who has a documented exit strategy, has tested their data export capability, and is actively evaluating alternatives will consistently receive better pricing than an equivalent customer who has none of these things in place.
You do not need to share your exit strategy document with the vendor to benefit from it. The leverage comes from the posture it creates: informed, prepared questions about portability at contract renewal; mention of alternative platform evaluations that are credibly backed by internal knowledge; willingness to request a proof of concept from a competitor. Vendors read these signals. The customer who has done the work to understand their exit options negotiates from a fundamentally different position than the customer who has not.
For vendor-specific negotiation strategies informed by exit planning, see our guides on Oracle, SAP, Microsoft, Salesforce, and VMware/Broadcom. For firms specialising in multi-vendor negotiation and exit strategy, see our multi-vendor negotiation firm rankings.
Our advisors build vendor exit strategies and negotiate the contractual protections you need — before you sign. Over 500 enterprise engagements across Oracle, SAP, Microsoft, Salesforce, and cloud.