Getting data out is the product's real moat

Why export is always last

Every enterprise software contract is eventually a negotiation about price. Licence fees, maintenance rates, support tiers — all of it sits on the table, and procurement teams have learned to push back. What almost nobody negotiates in advance is the right to leave cleanly, because at signing the customer is not thinking about leaving. By the time they are, it is too late.

The moat is not the software. The moat is the data that has accumulated inside it, in formats, schemas and identifiers that belong to the vendor. This is vendor lock-in in its most durable form: not a contractual penalty for departure, but a structural cost that makes departure expensive enough to defer indefinitely.

Export functions are built last because they generate no revenue. A well-designed import wizard closes deals; a well-designed export wizard opens the door to a competitor. The commercial logic of deprioritising exit capability is not subtle, and it has been consistent across every category of enterprise software since the first relational databases went commercial in the early 1980s.

The schema problem

Edgar F. Codd's relational model, published in 1970, made data portable in theory. Tables, keys and joins are a common grammar; any competent system should be able to read another's output. In practice, every vendor builds on top of that grammar in ways that are emphatically their own. Oracle's date handling differs from SQL Server's. SAP stores transactional data across hundreds of tables whose relationships are documented only in proprietary references. A customer who has run an SAP ERP system for fifteen years has data distributed across a schema that would take months to reverse-engineer fully — and SAP's own migration tooling assumes the destination is also SAP.

This is not accidental. A schema that is easy to export from is a schema that is easy to import into a competitor's system. The complexity accrues genuinely over time — real business logic embedded in real tables — but the vendor has little incentive to simplify it. The result is that the true switching cost is not the new licence; it is the data migration project, which arrives with its own consultants, its own timeline and its own risks.

The Lidl SAP programme, abandoned in 2018 after years of work and reportedly hundreds of millions of euros spent, illustrated a related problem in reverse: the retailer's own business processes were too far from SAP's embedded assumptions to adapt without rebuilding the system from scratch. The data model encoded a particular way of running a business, and changing that model meant changing the business. That is lock-in operating at the level of process, not just storage.

The SaaS variation

Software-as-a-service changed the delivery model but not the extraction problem. When data lives on a vendor's servers rather than a customer's own infrastructure, the practical difficulty of getting it out increases. The customer has no direct access to the database layer; they have whatever API or export function the vendor has chosen to provide.

Salesforce offers data export as a scheduled service; it does not offer schema documentation of the kind that would allow a customer to reconstruct their data relationships in another system without significant effort. Workday's data extraction requires technical expertise that most customers outsource, typically to the same implementation partners who sold the original deployment. The ecosystem of consultants that surrounds every major enterprise platform exists partly because the vendors' own tooling for extraction and migration is never quite finished.

Marc Benioff's original argument for renting software was that it lowered the cost of entry. It did. The cost of exit, which received less attention in 1999, turned out to be structural in a different way — not a capital write-off on decommissioned servers, but a dependency on vendor goodwill and API access that the customer cannot audit or enforce.

The negotiation nobody has

The correct moment to negotiate data portability is at contract signing, when leverage exists. The standard clause to seek is a documented, machine-readable, schema-accompanied full export, executable on demand and without additional fees. It is rarely standard, often resisted and almost never enforced with penalties. The migration cost remains the moat, and the moat remains the product.