There's a story companies tell themselves when they put a data contract out to bid, and it goes something like this: We have a vendor. The vendor is expensive, or the coverage has gaps, or the renewal is coming up, and so we are going to survey the market, score the alternatives on a rubric, and pick the best one. It's a procurement story. It's rational, orderly, defensible in front of a CFO.

I want to suggest that this story is almost never the real story. And the gap between the story and the reality is where most of these evaluations quietly fail — for the buyer and for every challenger who bids on them.

Here's the thing I keep coming back to: an incumbent data vendor is not a product a company uses. It is infrastructure a company has built on. Those are profoundly different things, and we don't have good language for the difference, so we keep using the vocabulary of shopping — features, coverage, price per record — to describe what is actually a question about institutions.

Your vendor's taxonomy is load-bearing

Think about what actually happens over five or seven years of a data relationship. The vendor's entity IDs seep into your warehouse. Their industry taxonomy becomes the way your sales team talks about territories. Their field names are hardcoded into ETL jobs written by an engineer who left in 2023. Your exception-handling routines are calibrated not to data quality in the abstract but to this vendor's specific quirks — the way their firmographics lag after a merger, the particular pattern of their false positives. Someone in finance has a spreadsheet pulling one field nobody remembers, and it feeds a board report.

None of this shows up in the RFP scoring rubric. All of it shows up in the migration.

And here is the uncomfortable implication. When a challenger shows up with objectively better data — fresher, deeper, more globally complete — the first thing that better data does is break things. Every discrepancy between the old feed and the new one gets adjudicated, and the adjudication has a built-in bias: the incumbent's numbers are the baseline everyone has normalized to. Different reads as wrong, even when different is more accurate. That's not a data problem. That's an epistemology problem, and epistemology problems don't get solved by feature matrices.

Nobody gets fired for renewing

Now layer the human incentives on top. The person running the evaluation faces a deeply asymmetric bet. Renew the incumbent, and if things stay mediocre, well, things were already mediocre — no one's career ends over continuity. Sponsor a switch, and if the migration is rocky, there is a name attached to that decision, and it's theirs. Behavioral economists have spent decades documenting that we weigh losses roughly twice as heavily as equivalent gains. Procurement processes are loss aversion with a scoring rubric stapled to it.

This is why so many RFPs in the data space are, functionally, renewal negotiations wearing a costume. The buyer may not even fully realize it. The process generates competitive quotes, the incumbent sharpens its pencil at the eleventh hour, and everyone gets to feel diligent. The challengers, in this version, were never really candidates. They were leverage.

I don't say that cynically. I say it because both sides are better off naming it. A buyer who genuinely wants change needs to know that the process they've designed may be structurally rigged toward the status quo — starting with the requirements document itself, which, after years with one vendor, tends to read suspiciously like that vendor's spec sheet. You cannot imagine the workflow any other way, so you write the RFP in the incumbent's image, and then you're puzzled when the incumbent scores best against it.

The two prices

Every data contract in a displacement scenario has two prices, and only one of them is on the proposal.

The incumbent understands this arithmetic perfectly, which is why they can afford to discount late in the process. Their discounted status quo competes against your full price plus the entire hidden column. Any challenger who doesn't do this math out loud — transparently, in the proposal, with a plan for shrinking or absorbing each line — is asking the buyer to do it privately, where it always resolves in favor of doing nothing.

So what does real change look like?

If the diagnosis is that vendor displacement is a change-management problem disguised as a procurement problem, the prescription follows pretty directly, and it applies to both sides of the table.

For buyers: the single best predictor of whether your evaluation produces change is not the rubric. It's whether a named executive owns the migration. Not the selection — the migration. If nobody inside the building is accountable for making the transition succeed, you are running a price-discovery exercise, and you should at least be honest with yourself about that. Write requirements around outcomes, not around the shape of the tool you already have. And demand exit provisions from whoever you choose next, because the lock-in you're straining against today was installed one reasonable-seeming integration at a time.

For challengers: stop selling better data. Sell de-risked change. That means a migration playbook with names and dates on it. It means confronting the concordance problem honestly — here are our match rates, here is what won't map, here is how exceptions get handled — because the buyer's technical team already knows the mapping will be imperfect and will trust you more for saying so. It means absorbing switching costs where you can: parallel-run subsidies, included services, backfilled history. And it means the counterintuitive move of making yourself easy to leave. An exit clause is a trust signal no incumbent can cheaply match, precisely because their business model depends on the opposite.

The deeper point is one that extends well past data vendors. Organizations don't resist better tools. They resist the reorganization of themselves that better tools require. Anyone who has watched a company cling to a system everyone claims to hate understands this. The system isn't the product. The system is the accumulated set of habits, workarounds, expertise hierarchies, and quiet dependencies that grew around the product. You are never replacing a vendor. You are asking an institution to renovate itself while everyone keeps working inside it.

The companies that get this right — on either side of the RFP — are the ones that stop asking "which vendor is better?" and start asking the harder question: "who owns the change, and what will it actually cost to make?" Answer that honestly, and the vendor decision mostly makes itself.