I've seen this happen enough times that I've stopped being surprised by it. A team is already using a product, a better option comes along that everyone agrees is better, and they stick with the old thing anyway. The incumbent wins not because it's the best product or service, but because it's the one people already know how to use.
When an org has been using a tool they have built integrations around it. Usually, spreadsheets, workarounds, knowledge of which reports to trust and where to click. The incumbent tool isn't perfect, but they know exactly where the warts are and how to work around them. That knowledge is invisible, it's muscle memory and it's real.
The migration cost isn't the data - it's the collective memory.
"That's not how we work" is rarely laziness. It's an honest assessment of switching cost, and none of it shows up on a vendor comparison sheet.
The cost also compounds. Every month on the old tool is more workaround, more muscle memory, more convention. The longer they wait, the harder switching gets. Most teams are locked into tools they outgrew years ago - they know it's suboptimal, but the cost of leaving exceeds the pain of staying.
Incumbents understand this perfectly. They don't need to be the best product or have the latest features. They need to be good enough that the switching cost exceeds the frustration, and that's a high bar when the cost compounds every quarter.
New tools almost always miss this. They compete on features - we have X, the incumbent doesn't. But feature gaps are easy to close, and features don't capture the switching cost. The moat isn't the feature set. It's the operating system the team has already built around the incumbent.
So how do you actually beat an incumbent? You don't ask people to switch. You give them a bridge.
Don't require a rip-and-replace. Keep things similar to the current product and add the new capabilities alongside the familiar ones. Let people keep their spreadsheets, their email chains, their workarounds - and earn the trust that lets them move away from those crutches over time. The tools that win slide into the operating system people already have. They don't demand a new one.
But giving them a bridge isn't just about the product. It's about showing them how to cross it. The best onboarding in the world won't matter if people don't understand why your tool's approach is better than what they're used to.
This is where training and documentation become part of the product, not an afterthought. You need to help customers understand your software's point of view, why it does things differently and what they get out of making the shift. That's true whether they're switching from an incumbent or signing up for the first time. First-time customers don't have the switching cost, but they still need to understand why your approach wins.
WorkOS is a good example here. They don't just sell an identity platform - they actively guide customers through migrations from Auth0 and other providers. They present the options upfront, give you tools to make the migration easier, and walk you through the process step by step. The migration is part of the product. The same idea applies to documentation, onboarding flows, and even short videos that show someone how a workflow works before they have to try it themselves. Every piece of guidance that reduces the mental cost of switching makes your product more likely to actually get used.
If you're building something new, the onboarding and migration experience is your product, not the feature list. The best feature set with the worst onboarding will lose to the mediocre product people already know. Meet your users where they are, help them understand why your point of view is better, and make it easy for them to get there.
Work habits are harder to change than software. The best teams design for that instead of fighting it.
This series starts with the build vs. buy case at Don't Build What You Can Buy, and wraps up with the resolution at Buy the Platform, Build the Layer.