BATNA — Best Alternative to a Negotiated Agreement — is the single most powerful concept in enterprise software negotiation. Without a genuine, credible alternative to signing with your incumbent vendor, every tactic, every benchmark, every psychological counter-technique is weakened. This guide shows how to build a real BATNA for any enterprise software renewal.
This article is part of our IT Contract Negotiation Strategy pillar guide. BATNA is the foundational concept — read this first, then explore the specific tactics, timing strategies, and contract clause guidance in the wider cluster.
BATNA — the Best Alternative to a Negotiated Agreement — is a concept from Roger Fisher and William Ury's negotiation framework developed at Harvard and popularised in the foundational text "Getting to Yes." In a software negotiation context, your BATNA is the best outcome you can achieve if the current negotiation fails completely — if you cannot agree with your existing vendor and must pursue an alternative path.
Your BATNA might be: migrating to a competitor platform; deploying an open-source alternative; extending your current contract while renegotiating; outsourcing the function to a service provider; or simply deciding to defer the upgrade and stay on legacy systems. Each of these is a real BATNA only if you have genuinely evaluated it and are prepared to execute it if the negotiation fails.
The key word is genuine. A BATNA you are not prepared to execute is not a BATNA — it is a bluff. And experienced vendor negotiators, who have been on the other side of hundreds of enterprise negotiations, are extremely good at detecting bluffs. The commercial value of BATNA comes from its credibility — and credibility comes from the work you have done to genuinely evaluate and prepare the alternative.
Organisations with a genuine, credible BATNA typically achieve 20–35% better commercial outcomes than those without one — even when both organisations have the same information and the same negotiation tactics. The structural leverage of a real walk-away position transforms every other tactic's effectiveness.
Without a BATNA, you are negotiating from a position of pure dependence. The vendor knows it. Your team knows it. And the negotiation reflects it — not necessarily because the vendor is deliberately exploitative, but because the structure of the situation rewards them for being patient and costs them nothing for being firm.
Consider the logic from the vendor's perspective. If they know you have no credible alternative to renewing with them, what incentive do they have to offer meaningful commercial concessions? The risk of losing the deal — and its revenue — is near zero. The only scenario in which they offer better terms is if you generate genuine uncertainty about whether the deal will close on their desired timeline at their desired price.
BATNA creates that uncertainty. Even in software markets with high switching costs and deep integration, a credibly communicated BATNA shifts the vendor's risk calculation and activates commercial flexibility that is simply not available to buyers who lack it. This is why the work of building BATNA — time-consuming, resource-intensive, and sometimes requiring genuine investment in technical evaluation — consistently produces the highest return of any negotiation preparation activity.
The most powerful form of BATNA is a credible, technically evaluated competitor product that could genuinely replace the incumbent. The power of this BATNA depends entirely on technical credibility — if your IT team has run a real RFP, engaged the alternative vendor, and can speak to the feasibility of migration, this BATNA is extremely powerful. If it is merely name-dropped without evidence of genuine evaluation, experienced vendor negotiators will dismiss it.
For on-premises software, cloud migration or managed service alternatives represent a powerful BATNA even when direct product substitution is not feasible. The threat of migrating from Oracle on-premises to AWS RDS PostgreSQL, or from SAP on-premises to a cloud ERP service, is a genuine alternative that materially changes the vendor's commercial calculation — particularly where the cloud migration eliminates the vendor's recurring licence and maintenance revenue entirely.
This BATNA requires investment in cloud architecture assessment and migration cost modelling, but the data produced — a credible total cost of ownership analysis for the migration alternative — is both a negotiation lever and a genuine strategic decision support tool. See our guide on Oracle cloud migration leverage and Azure migration incentive programmes for specific examples of how hyperscalers support migration economics.
For vendors with significant annual maintenance and support fees — particularly Oracle and SAP — third-party support providers (TPS) represent a powerful partial BATNA. Moving from Oracle's standard 22% annual support to third-party providers like Rimini Street or Spinnaker at 50% of vendor cost is a real option for many enterprises, and the threat of making this move is a powerful lever for reducing vendor support fees even if you ultimately stay on vendor support.
This BATNA is credible because it has been executed successfully by thousands of enterprises. Vendors are aware of it and respond commercially. See our guides on third-party Oracle support and reducing SAP maintenance costs for the full strategic picture.
A time BATNA — the ability to extend your current contract at current pricing while you continue to evaluate alternatives — is often undervalued. If your current agreement includes provisions for month-to-month extension or annual renewal at current terms, you have the ability to remove the artificial deadline from the vendor's playbook entirely. This is not a migration BATNA, but it is a genuine walk-away from the vendor's preferred negotiation timeline, which is itself a form of leverage.
Negotiating time extension rights into your current contract is therefore a BATNA preparation activity for your next renewal. When you are in your current negotiation, securing these rights for the following cycle is as valuable as the immediate commercial terms you are discussing.
Need help building a credible BATNA before your next renewal?
Building a genuine BATNA requires structured investment, not just intention. The following six-step process is the framework used by effective enterprise IT negotiation teams and their advisors.
Before you can identify alternatives, you need a clear picture of what you are trying to replace. Document every integration, customisation, workflow, and business process that depends on the current vendor's product. This dependency map serves two purposes: it identifies the genuine switching barriers you must address in alternative evaluation, and it often reveals that some dependencies are more superficial than assumed — legacy integrations that could be replaced with modern APIs, for example.
Working from your dependency map, identify which vendor categories have credible alternatives. This requires honest technical assessment, not wishful thinking. Engage alternative vendors — not just for their marketing, but for their reference customers, their implementation timelines for comparable environments, and their total cost of ownership at your scale and complexity.
For your most credible BATNA alternative, commission a genuine technical feasibility assessment. This should be conducted by technical staff who would actually perform the migration — not consultants who have an interest in selling a particular outcome. The assessment should produce a realistic migration timeline, resource requirement, risk profile, and total cost of ownership. This document becomes the foundation of your BATNA credibility.
Compare the fully-loaded cost of your current vendor path — including licence increases, maintenance, and contractually embedded escalations — against the total cost of your best alternative, including migration costs, productivity impact, training, and the new platform's ongoing costs. A credible TCO comparison that shows the alternative is financially viable in a 3–5 year horizon is the most powerful commercial document in any BATNA-based negotiation.
A BATNA that is not internally authorised is not a BATNA. Ensure that your executive sponsor and key stakeholders have genuinely reviewed the BATNA option and are aligned — at least in principle — on proceeding with it if the vendor negotiations do not achieve commercial targets. If the business would not actually walk away at any price, the vendor will eventually detect this and the BATNA loses its power.
See the section below on communicating BATNA effectively. The work done in steps 1–5 is the foundation — how you communicate it determines whether the vendor takes it seriously.
Communicating BATNA credibly in vendor negotiations is an art. The most effective approach is to demonstrate rather than assert — to show the vendor evidence of genuine alternative evaluation rather than simply stating that you have alternatives.
| Vendor | Strongest BATNA Options | BATNA Strength | Key Preparation Needed |
|---|---|---|---|
| Oracle DB | PostgreSQL, SQL Server, AWS Aurora | Strong | Schema migration assessment, performance testing |
| Oracle ERP | SAP S/4HANA, Dynamics 365 F&O | Moderate | Customisation inventory, integration mapping |
| SAP ECC/S4 | Oracle ERP, Infor, Dynamics 365 | Moderate | ABAP customisation review, data migration scoping |
| Salesforce CRM | Dynamics 365 Sales, HubSpot | Strong (for CRM) | Data model mapping, integration audit |
| VMware/vSphere | Nutanix AHV, Hyper-V, cloud migration | Strong | VM inventory, workload profiling |
| Microsoft 365 | Google Workspace (limited), self-hosted (very limited) | Weak | Focus on right-sizing, not migration |
| Oracle Java | OpenJDK, Amazon Corretto, Eclipse Temurin | Strong | JDK compatibility testing, deployment inventory |
| Oracle Support | Rimini Street, Spinnaker Support | Strong | Version compatibility check, TPS scope review |
The most common challenge enterprises face is that their incumbent software is deeply embedded — with years of customisation, integration, and process dependency built on top. In these situations, the migration BATNA is expensive, time-consuming, and risky. Does this mean BATNA is not available?
Not entirely. Even in deeply embedded scenarios, a partial BATNA can generate significant commercial leverage. Three approaches are particularly effective:
Rather than threatening to replace the entire platform, identify specific components that could credibly be moved. For Oracle, this might mean migrating non-critical databases to PostgreSQL while keeping strategic workloads on Oracle. For SAP, it might mean migrating Concur or SuccessFactors to alternatives while maintaining core ERP. The vendor does not want any revenue erosion — even partial migration threats activate commercial flexibility.
Even when product migration is not credible, moving from vendor support to third-party support is almost always a credible and financially validated BATNA. For Oracle and SAP customers, this is one of the most reliably powerful levers available and requires relatively modest preparation investment.
Communicating that you are prepared to begin a migration evaluation that might take 18–24 months to complete is itself a commercial lever, even without committing to the migration. Vendors who are booking annual maintenance revenue understand that the risk of that revenue stream ending in 18–24 months has present value — and that present value motivates commercial concessions today.
Facing high switching costs with your current vendor?
The best IT negotiation consultants have evaluated alternatives for hundreds of enterprise environments — and know exactly what credible BATNA looks like for your vendor and situation.