BATNA in Software Negotiations:
Build Your Best Alternative

BATNA — Best Alternative to a Negotiated Agreement — is the concept introduced by Roger Fisher and William Ury in "Getting to Yes" and taught in every serious negotiation programme. The core idea is elegant: your negotiating power in any transaction is determined not by your strength relative to the other party, but by how attractive your best alternative is if the negotiation fails. The better your BATNA, the less you need the deal being offered. The less you need the deal, the more favourable the terms you can demand.

In enterprise software negotiations, this concept has near-universal application — and near-universal misapplication. Most enterprise software customers approach vendor renewals without a credible BATNA. They need the software to run their operations. They have no realistic short-term alternative. They have made this dependency visible to the vendor through years of deep integration and customisation. And then they attempt to negotiate. The outcomes are predictable.

Changing this dynamic is the central challenge of enterprise software procurement strategy. Building a credible BATNA — not just stating that you have alternatives, but actually developing them to the point where the vendor believes you might use them — is the prerequisite for effective negotiation on any major enterprise software deal.

The BATNA Framework Applied to Enterprise Software

The BATNA framework has three components: identifying your alternatives, developing the best one as far as possible, and using it appropriately in the negotiation. In enterprise software contexts, each component requires specific adaptation.

Identifying Your Alternatives

For any major enterprise software platform, the realistic alternatives fall into four categories. Full platform migration to a competing product represents the most powerful BATNA but also the most costly to develop credibly. Partial migration — moving specific workloads or user populations while reducing incumbent commitment — is often more achievable and can still create significant commercial pressure. Third-party maintenance and support substitutes the incumbent's support model with a lower-cost alternative, reducing support fees by 40–60% and creating commercial pressure without platform migration. Finally, internal development of functionality that reduces dependence on specific licensed modules is occasionally feasible for large organisations with strong engineering capabilities.

Not every alternative is viable for every organisation and every platform. A global SAP ERP deployment with 20 years of customisation has fewer realistic alternatives than a Salesforce CRM instance with two years of use. The exercise of identifying alternatives should be honest — an implausible alternative that neither you nor the vendor believes is a genuine option provides no leverage at all.

Developing the Best Alternative

The key distinction is between having an alternative conceptually and having developed it to a point where the vendor has reason to believe you might act on it. The development activities that make a BATNA credible are specific and observable:

• Migration assessments: A formal, vendor-neutral assessment of what migration to an alternative platform would require, cost, and deliver. Should be conducted by a credible third party and result in a documented finding.
• Proof of concept: An actual technical demonstration on the alternative platform, even if limited to a subset of functionality. Vendors can verify through their own intelligence whether a PoC is in progress.
• Competitor engagement: Active commercial discussions with a competing vendor, resulting in a formal proposal. The existence of a named competitor proposal changes the commercial dynamic immediately.
• Third-party maintenance assessment: For legacy enterprise software, a formal assessment from a third-party maintenance provider (Rimini Street, Spinnaker Support) of their ability to support your deployment. This is inexpensive, quick to produce, and highly effective at creating commercial pressure on incumbent support fee negotiations.

Building BATNAs for Major Enterprise Software Vendors

How and When to Use Your BATNA

Timing and framing are as important as the BATNA itself. A BATNA revealed too early allows the vendor to prepare counter-arguments and discount its credibility. A BATNA revealed too late — after you have already signalled desperation or agreed commercial terms — has no impact. The optimal deployment sequence typically follows this pattern:

Early Stage: Build Without Revealing

In the 9–12 months before a renewal, develop your BATNA actively without making it visible to the vendor. Conduct your migration assessment, request competitor proposals, commission your third-party maintenance review. The goal in this stage is to build genuine optionality — so that if the vendor's commercial position is truly unreasonable, you have an executable alternative.

Mid Stage: Signal Selectively

In the 3–6 month window before renewal, begin to make elements of your BATNA visible to the vendor — but selectively and through appropriate channels. A senior IT leader mentioning in a business review meeting that "we're looking more broadly at our platform strategy" is a signal that registers without overcommitting. A formal letter to the vendor noting that "we are currently evaluating our options" alongside a specific commercial counter-proposal creates the context for the BATNA to be taken seriously.

Late Stage: Make It Specific

In the final 60–90 days before expiry, if the vendor's commercial position is still not acceptable, make your BATNA specific and visible. Name the alternative platform or provider. Reference the proposal you have received. Provide a timeline. At this point the vendor is making a binary calculation: does this customer have a credible alternative, and what is the cost of them exercising it versus the cost of conceding commercially? Your goal is to ensure that calculation comes out in your favour.

The Vendor's BATNA and Why It Matters

Fisher and Ury note that negotiation outcomes are determined by the interplay of both parties' BATNAs. Understanding the vendor's position — what happens to them if you don't renew — helps calibrate your approach. Vendors with high customer concentration, poor net revenue retention, or aggressive quarterly revenue targets have weaker BATNAs than those with diversified books, high renewal rates, and fiscal year cushion.

Enterprise software vendors are not monolithic in this regard. A local or regional VAR with 20% of their revenue concentrated in your account has a very different BATNA than a vendor whose global revenue you represent 0.01% of. Understand your strategic value to the specific vendor team you are dealing with. Deals where you represent a significant reference customer, a logo in a target vertical, or a key use case for a new product are deals where the vendor's BATNA is weaker and your leverage is consequently greater.

Advisors and BATNA Development

Building credible BATNAs for complex enterprise software platforms requires expertise that most internal IT teams do not maintain. Migration assessments need technical credibility. Competitor proposals need commercial context to be meaningful. Third-party maintenance options need to be evaluated against specific support risk profiles. External advisors who work across multiple vendors and multiple client contexts can accelerate BATNA development substantially.

The leading independent advisory firms in this space — including Redress Compliance, which has conducted BATNA development and negotiation support across hundreds of enterprise software renewals — can typically build a credible BATNA framework within 4–8 weeks, including a migration assessment, competitor engagement, and third-party maintenance evaluation. For deals where the commercial stakes justify the investment, this support consistently delivers returns that far exceed advisory costs.

For a complete negotiation framework, see our IT Strategy Guide and our related articles on Negotiation Tactics, Building Vendor Leverage, Pushing Back on Price Increases, and Cross-Vendor Contract Strategy. For vendor-specific BATNA options, our software licensing advisory practice covers Oracle, Microsoft, SAP, Salesforce, and all major cloud platforms.

If you are approaching a major renewal and want help developing a credible BATNA and negotiation strategy, contact our team. We have executed this process for organisations from $10M to $500M+ in annual software spend, across every major enterprise software vendor.