A mid-sized logistics company I know of spent three years building their operations on a workflow automation tool. The vendor was acquired. The acquirer had no interest in the product. The logistics company had eighteen months to migrate, roughly 200,000 lines of process logic encoded in a proprietary scripting language, and a team that had never thought much about portability because why would they? The software had worked great.
The migration cost more than the original implementation. Twice over.
This is the conversation the software industry keeps avoiding. We have correctly internalized that software has near-zero marginal cost to distribute. One more user downloading your app costs you almost nothing. That insight reshaped how products get built, priced, and sold. What we have not internalized, with anywhere near the same clarity, is that software can carry enormous exit costs, and those costs are almost entirely invisible until you try to leave.
Why Zero Marginal Cost Became the Whole Story
The zero marginal cost idea has genuine explanatory power. It explains why software companies can scale so fast, why SaaS multiples looked reasonable during the growth years, why VC money chased software over hardware. Chris Anderson’s The Long Tail and later thinking around digital economics made this a mainstream framework. Shipping software is cheap. Hosting it keeps getting cheaper. The economics are genuinely different from manufacturing.
But this framing got applied too broadly. It described distribution costs and then quietly implied that all costs trend toward zero. The idea migrated from “cheap to ship” to “cheap to adopt, operate, and exit.” That last part was never true, and the industry largely pretended it was.
Vendors had every incentive to encourage this belief. If switching feels painless, adoption feels lower-risk. Lower perceived risk means shorter sales cycles. The actual switching cost is a problem for future-you, and future-you is not in the room when the contract gets signed.
The Layers Where Exit Costs Actually Live
Exit costs in software are not usually a single big fee. They accumulate across several distinct layers, and most buyers never think to audit all of them before committing.
The first layer is data portability. Your data lives in the vendor’s schema, often in formats that require transformation before they mean anything to another system. Even vendors with “export to CSV” features frequently omit relational structure, metadata, historical states, or audit logs. You get a flat file where you had a relational database. The data is technically yours; using it costs a rebuild.
The second layer is encoded process logic. This is the one that burned the logistics company. Every time your team configures an automation, writes a custom workflow, or builds a report template, they are writing business logic in someone else’s proprietary language. That logic represents real organizational knowledge. When you leave, you do not take it with you. You retranslate it, and translation always loses something.
The third layer is integration surface area. Modern software stacks are deeply interconnected. The average mid-market company runs dozens of SaaS tools, many integrated with each other. Replacing one tool means auditing every connection that tool has to everything else, and rebuilding them. The more central the tool, the worse this is.
The fourth layer, and the most underestimated, is institutional memory and learned behavior. Your team has spent months or years learning to work around the quirks of a specific tool. That knowledge is not transferable. A migration resets the clock on productivity in ways that rarely show up in migration cost estimates.
The Lock-in Spectrum Is Wider Than You Think
There is a tendency to frame lock-in as a binary, either you are locked in or you are not. In practice it is a spectrum, and where you sit on it depends on choices made early that felt completely inconsequential at the time.
On the low-lock-in end you have tools that operate on open standards, export to portable formats, and do not accumulate business logic in proprietary systems. A well-configured database with a clean schema is relatively portable. A monitoring tool that emits standard Prometheus metrics is easier to replace than one that requires its own agent and query language.
On the high-lock-in end you have platforms. Platforms are specifically designed to accumulate surface area. Every integration you add, every workflow you configure, every custom object you create is a ratchet click in the vendor’s favor. Salesforce has been extraordinarily good at this. So has ServiceNow. So, increasingly, is every SaaS company that realized building a platform was more defensible than building a product. The economics of this are not accidental.
Cloud infrastructure sits in a complicated middle zone. Raw compute is relatively portable; the managed services built on top of it are not. Migrating off AWS Lambda is straightforward compared to migrating off AWS Kinesis and DynamoDB and SQS when all three are deeply integrated with each other and your team has built significant tooling around their specific behaviors. Amazon, Google, and Microsoft understand this. Their managed service catalogs are not built for portability.
The Accounting Trick That Hides This From CFOs
Here is the part that frustrates me most. Even in companies with sophisticated finance teams, exit costs almost never appear in the original software procurement analysis. There are structural reasons for this.
First, exit costs are contingent. They only materialize if you leave, and at procurement time everyone expects the tool to work out. Booking a contingent liability for a software decision that has not gone wrong yet is not how procurement budgeting works.
Second, exit costs are diffuse. They spread across engineering time, productivity losses, integration rebuild work, and training cycles. None of these look like “migration cost” on a budget line. They look like normal operating expenses that happen to spike for a year or two.
Third, the people who feel the cost are rarely the people who made the original decision. The VP who signed the contract for a platform tool is usually not the one who leads the eventual migration. The organizational memory of why the tool was chosen often outlasts the memory of what alternatives were evaluated. As measuring software cost accurately is already hard, adding the dimension of contingent future exit costs makes it nearly impossible.
The result is systematic underpricing of vendor risk at procurement time, and systematic overpaying at exit time.
How Good Teams Price This In
The companies I have seen navigate this well share a few habits.
They ask the exit question before signing. Not as a hostile negotiation tactic but as a genuine diligence item: what does migration look like in three years if this does not work out? A vendor that cannot answer this question clearly is telling you something.
They treat portability as a design constraint, not an afterthought. This means preferring open data formats, documenting integrations, and being genuinely skeptical about accumulating business logic in proprietary scripting environments. It means building abstractions in their own codebase that isolate vendor-specific behavior, so that swapping the vendor means changing the abstraction, not rewriting the system.
They negotiate exit terms explicitly. Data export guarantees, transition periods, format specifications. Most vendors will agree to reasonable terms if you ask during procurement, when they want your business. Asking after a notice of acquisition is not a negotiation; it is begging.
They run periodic portability audits. Not because they expect to migrate, but because the exercise surfaces dependencies that have quietly accumulated. A team that has never tried to describe what a migration would require tends to underestimate it by an order of magnitude.
The Startup Risk Nobody Talks About Enough
For enterprise buyers, exit costs are expensive but survivable. For startups building on top of other software, they can be terminal.
The specific failure mode looks like this: an early-stage company builds core functionality on top of a third-party platform, often because it is fast and cheap to start. The platform changes pricing, deprecates an API, gets acquired, or simply evolves in a direction that breaks compatibility. The startup now faces a forced migration at a moment when they can least afford the distraction. Engineering cycles that should be going toward product-market fit go toward rebuilding infrastructure.
This is not a hypothetical. Parse shutting down forced a generation of mobile developers to rebuild backend infrastructure. Heroku degrading its free tier pushed many early-stage teams into unplanned infrastructure work. The common thread is that the zero-cost entry was real, and the exit was not.
Building on top of other companies’ platforms is not inherently wrong. The leverage is real. But the risk calculus has to include what happens when that platform moves against you, and it needs to be factored in at the architecture stage, not the crisis stage.
What This Means
The zero marginal cost of software distribution was always about distribution, not about the full economics of adoption and exit. The gap between those things has quietly cost the industry enormous amounts of money and organizational disruption.
A more honest accounting treats high-lock-in tools as capital commitments, not operating expenses. It asks the exit question at procurement. It designs systems with portability as a first-class concern. And it recognizes that the vendor who makes it easiest to leave is often the one you can trust most to make staying worthwhile.
The cheapest software to adopt is not always the cheapest software to use. And it is almost never the cheapest software to leave.
