Enterprise switching costs: the 9x effect and the switching cost ladder

How much better does a product have to be to win an enterprise deal? It depends on how much the buyer is being asked to give up.

Anyone who has sold into enterprise has watched this happen. The buyer tells you that what they have is worse than what you're selling. Ours is clunky. Everyone complains about it. We'd love to move off it.

But then they renew with the incumbent.

Why? Because people resist a new system even when they can see it's better. Habit, sunk costs and the effort of transition build into inertia, and that inertia colors how they see the alternative. The longer someone has used the old system the less impressive the new one looks. 

The deals that look strong (and then don't close) are usually the ones asking for the most. Rip out three tools. Move four years of data. Retrain a couple hundred people and run both systems for a quarter. The argument gets won in initial sales meetings and lost in the quiet stretch afterward, when somebody sits down and works out what switching actually looks like.

The winning deals tend to be smaller asks. Not smaller contracts, but smaller disruptions. One tool, timed to its renewal. Or something that sits alongside what's already there and doesn't make anyone change how they work.

So whatever a buyer is being asked to tear out sets how much better the product has to be. Ask for very little, and being somewhat better is plenty. Ask them to replace five tools with a platform and you need close to an order of magnitude, which is a bar most products will never clear.

That's not an original observation. It does come with a number, though.

The 9x effect: when a new product has to be nine times better

The 9x effect comes from John Gourville, who wrote it up for Harvard Business Review in 2006. Two biases run at the same time and multiply. Sellers overvalue what they’re selling by roughly 3x, because they've been living inside it and can see what it will become. 

Buyers overvalue what they're already using by roughly 3x, for the ordinary reason that people get attached to what they have. Neither party thinks they're being unreasonable. 

But the two biases point the same way and stack. You're overrating yours threefold while they're overrating theirs threefold, so the same product looks nine times worse from their chair than it does from yours.

There's a simple reason for that, which Kahneman and Tversky worked out decades ago: losing something hurts about twice as much as gaining the same thing feels good. A migration is a loss the buyer can picture. It has a date on it and a list of people who are going to be annoyed. The improvement is a promise. One of those feels real in a way the other doesn't.

Samuelson and Zeckhauser named the other half in 1988: status quo bias, where an incumbent product gets a premium purely for being the incumbent, before anyone assesses whether it's any good. 

The switching cost ladder: how the bar moves with the size of the ask

The 9x isn't a fixed requirement. It moves with what you're asking the buyer to give up, and I call that relationship the switching cost ladder: how much better a product has to be at each level of disruption, from a new budget line at the bottom to a full platform replacement at the top. 

Which rung you're selling on is your call.

The five rungs, from cheapest to most expensive:

1. Nothing to remove, new budget line. A modest improvement clears this. The competition is a spreadsheet and somebody's patience.
2. Sits alongside what they have. Small ask, small bar, and nobody has to give anything up.
3. Replaces one tool at its renewal date. Meaningful improvement needed, and the renewal date does half the work because the contract overlap goes to zero.
4. Replaces one tool mid-contract. They're paying twice now, so the product has to be well clear of good.
5. Replaces five tools with a platform. This is where 9x lives, and where most platform pitches quietly die.

Cost isn't the only thing climbing the ladder. A first-time purchase can waste the budget. A replacement can waste the budget and break something that was working (well enough), and afterwards everyone can compare the new thing to the old thing. That comparison is a verdict on whoever chose it. It's why “nobody ever got fired for buying IBM.” A new project that fails was worth a try. A replacement that fails is something you broke.

It also explains why enthusiasm doesn't predict closing at the top of the ladder. The people admitting that the incumbent is clunky are usually the ones who'd benefit. The person who'd carry the blame is usually somebody else, and they're quieter.

Many teams are standing on rung five and reading the loss as a product problem. It usually isn't. The bar was set by what they asked the buyer to do.

Building a platform and selling a platform are separate decisions. Workday was a full HR and finance suite from the start, and it almost always sells HR first, with financials arriving years later. The platform was the destination. The HR product was the door.

That choice gets made deal by deal. Which product leads, whether the first contract covers one team or the whole company, whether you sit alongside the incumbent or replace it, whether you wait for a renewal date. A team can spend two years building toward “nine times better” when the faster move was to enter on rung three and let consolidation follow.

What made the ask heavier for enterprise software buyers in 2026

The psychology hasn't changed since Gourville wrote it up. What's changed is the friction around the purchase.

More people have to agree, and they don't always get along. Gartner surveyed 632 B2B buyers in late 2024 and found buying groups running from 5 to 16 people across as many as four functions. 

74% of those teams showed what Gartner calls “unhealthy conflict” during the decision: conflicting objectives, disagreement on the course of action, or being overruled by someone outside the group. Groups that did reach consensus were 2.5 times more likely to call the deal high quality. 

The point: Most losses happen in a room the vendor was never in.

Even after a vendor wins there's a queue. Security review adds 2 to 6 weeks to most enterprise cycles. The whole procurement and legal stack runs 4 to 10 weeks. Nearly all of this happens after the deal was decided on substance.

Budget is less predictable too, which matters because a replacement is exactly the kind of spend that slips when money gets uncertain. AI and consumption pricing have made bills harder to forecast, and IT leaders are cutting planned projects to absorb overruns they didn't see coming. A buyer facing an unpredictable bill doesn't kill the migration. They move it to next year, and then they move it again.

There's also a reason to wait that most vendors treat as an objection. If a category might look meaningfully different in 12 months, holding still has real value. A migration is irreversible, the future is unusually murky, and "let's revisit next year" is often the right call rather than an excuse.

Example: the SAP deadline almost nobody can meet

SAP has spent a decade proving that a better product and a hard deadline don't move an enterprise on their own.

SAP makes the software that runs finance and operations for many of the world's largest companies. It launched a new version, S/4HANA, in 2015 and told customers the old one was going away. Mainstream support ends on 31 December 2027, with a 2% premium buying extended support through 2030.

No vendor has ever had a better hand. A decade of notice, a fixed date, a penalty for missing it, newer modules available nowhere else, and a product its own users like, with survey respondents broadly positive and not one live customer rating the platform extremely negatively.

It wasn't enough. 39% of SAP's 35,000 legacy customers still hadn't moved as of late 2024, and nearly 60% of the projects that are running are late and over budget. What holds them isn't the licence fee. It's years of custom code nobody wants to unpick, processes built around the old system, consultants booked months out because everyone hit the wall at once, and no appetite for breaking finance and manufacturing to get somewhere marginally better.

SAP's answer has been to make the destination more attractive, gating new AI features behind a cloud commitment. Bigger promise, same ask.

You can see the other lever in the deals that do land. Airbus held out for years on a blocker that had nothing to do with the product: data too sensitive to leave European control, which no feature release solves. It signed in July once SAP built an end-to-end sovereign cloud model for it. The product didn't get better. Leaving became possible.

Five ways to lower the switching cost instead of improving the product

The instinct after losing these deals is to raise the promise. Ship more, get better, come back stronger. Sometimes that's right, and it's also the slowest and most expensive lever available.

Lowering the ask is faster, with one caveat. Some switching costs are expensive and some are impossible. Migration work and contract overlap have a price you can pay down. A compliance rule or a data residency requirement doesn't, and you either build for it or you don't win. That's what held up the SAP deal above.

Below are five ways to lower switching costs, ordered by how early in a deal you can use them.

Coexist before you replace. When the buyer already has something that works, entering alongside it removes the switching cost entirely. In The Power of Pull, Rob Snyder tells the story of Campground, a nonprofit software company whose buyers kept nodding along and never purchasing. Sold as an all-in-one replacement for their program management system, buyers heard painful migration. Sold as a donor reporting fix that plugged into what they already had, the same software closed a deal in a month and the price went from $5,000 to $25,000. Nothing about the product changed.

Price under the governance threshold. Most enterprises have a spending limit below which a purchase skips the heavy reviews. Stay under it and the change board, the architecture team and the formal risk assessment never get involved. It varies by company, and your champion will tell you what it is if you ask. A first purchase under that line isn't a discount, it's a shorter approval path with fewer people in it. The second purchase then costs almost nothing to approve, because you're already an approved vendor.

Work backward from renewal dates. The overlap between two contracts is usually the biggest line in the switching cost, and it goes to zero on exactly one date. Enterprise agreements often auto-renew 30 to 90 days out, so the real decision window opens six to nine months before the date on the paper. Most vendors learn about a renewal after it has happened. Ask for the date in discovery, put it in the CRM, and work the calendar instead of the quarter.

Buy down the migration. Credit the remaining term on the incumbent contract. Do the data migration with your own engineers. Run both systems in parallel at your cost. This looks like a margin problem and it's really just paying off the specific thing blocking the deal, which is cheaper than two years of roadmap aimed at the same gap. The test is whether it costs less than building your way to the same result.

Let consolidation happen after you're in. HubSpot sold inbound marketing tools for seven years before it launched a sales product, and roughly a decade before customer service. Salesforce sold sales force automation long before it sold a platform. In both cases the platform was the destination and one product was the door. Nobody rips out five tools for a stranger, though plenty of companies retire the fourth one 18 months after they started trusting a vendor.

Both levers, and the one nobody pulls

In short, two things decide whether an enterprise deal closes. How much better the product is, and how much the buyer has to give up to get it. Both can be changed. The first one gets almost all the attention.

SAP has spent a decade on the product. A better platform, a hard deadline, a penalty for missing it, and now AI features you only get by committing to the move. 39% of its customers still hadn't gone at the last count. Airbus moved when SAP built the sovereign cloud that made moving possible, not when the product got better. SAP has more leverage than any vendor reading this will ever have, and it still had to lower the ask.

So when a buyer says the incumbent is clunky and renews anyway, they've already conceded the product comparison. More often than teams assume, what's blocking the deal is the size of the ask.