Interoperability and the Right to Exit SaaS Platforms

In this article:

• What Is Interoperability and Why Does It Make Competition Possible
• The Technical Anatomy of Lock-In
• The Meaningful Export Problem
• Historical Cases Where Mandated Interoperability Worked
• What Policy Fight Are EFF and FSFE Running on Interoperability
• The DMA's Enforcement Gap
• AI as a New Interoperability Battleground
• Why Should Businesses Follow the Interoperability Policy Fight
• A Practical Vendor Audit Framework
• Frequently Asked Questions
• What is interoperability in software and why does it matter?
• What is the Digital Markets Act and how does it address interoperability?
• Do any SaaS platforms currently support meaningful interoperability?
• How does AI change the interoperability problem?
• Is there anything a business can do without waiting for regulation?
• References

Interoperability is the technical and legal condition that makes genuine market competition possible. Without it, switching costs accumulate until the platform can raise prices without consequence. The Electronic Frontier Foundation and the Free Software Foundation Europe have been fighting for interoperability mandates at the regulatory level. Businesses have a direct stake in that fight and most do not know it.

Interoperability means that data generated on one platform can be used on a competing platform without loss of functionality. It means that the switching cost is the effort of learning a new interface, not the loss of years of accumulated data. It means that platforms must compete on product quality because users can actually leave.

The absence of interoperability is not a technical inevitability. It is a business decision. Platforms that could support open data export standards choose not to because interoperability reduces lock-in. Lock-in is the mechanism that enables price increases without competitive consequences.

Saying that lock-in is engineered is accurate but abstract. The mechanism deserves examination because it makes the policy argument concrete and gives practitioners a way to evaluate their own exposure.

Lock-in is built through four primary technical approaches, often layered:

A platform may offer an export that technically contains your data but renders it unusable elsewhere. Notion exports its block-based content as a nested JSON structure that no other tool natively understands. Salesforce exports object records as flat CSVs, severing the relational links between accounts, contacts, opportunities, and activities that give the data its operational value. The export exists. The data does not travel.

Platforms commonly expose APIs for building integrations - but throttle them in ways that make full data extraction prohibitively slow or expensive. A rate limit of 100 requests per minute sounds generous for operational use but becomes a multi-week extraction project when applied to a database of a million records. This is not accidental. The rate limit that serves normal use perfectly is calibrated to make exit painful.

The most damaging lock-in is often invisible until you try to leave. A CRM export gives you contacts. It does not give you the call history, email threads, activity log, and pipeline stage transitions that make those contacts operationally meaningful. A project management export gives you tasks. It does not give you the comment history, version history, or time-tracking data attached to them. What you get is a skeleton. What you built over years was what linked all those silos.

Some platforms store data in formats with no published specification. Without documentation, the only entity that can reliably read the data is the platform that wrote it. This creates asymmetric dependency: the platform can always read your data; you can read it only on their terms.

Each of these approaches is individually deniable. Together, they compound into a fortress. And the platforms that deploy them understand exactly what they are doing.

Platforms that offer exports calibrated to cover data they are comfortable losing, while retaining data most valuable for lock-in, are operating a deliberate strategy. The categories that get withheld or degraded on export deserve their own treatment.

In platforms where value comes from connections - who follows whom, who is assigned to what, which accounts are linked to which contacts - the relational map is the actual product. Exporting nodes without edges gives you a list. The network is what you built. LinkedIn exports your connections as a CSV of names and email addresses, stripping the connection metadata, endorsements, and interaction history that made those connections meaningful in context.

Analytics platforms, marketing tools, and email platforms accumulate years of behavioral signal: open rates by segment, click patterns, conversion paths, audience cohort performance. This data is what makes a mature tool more valuable than a new one. It rarely exports cleanly. When it does, it exports in aggregate form - useful for reporting, useless for seeding a replacement system with the same intelligence.

This is an emerging category that will become the central lock-in mechanism within the next few years. Platforms that train models on your data - for classification, recommendation, or generation - are creating derivative assets that belong to you in principle and to them in practice. You cannot export a fine-tuned model. You cannot export the vector embeddings that encode your content's semantic relationships. When you leave, you leave the trained intelligence behind.

For regulated industries, the operational history of who did what and when is not optional. Platforms that store audit logs in proprietary formats, or retain them only in the platform interface rather than exporting them in a structured portable format, create compliance risk on exit that has nothing to do with the platform's primary function. The compliance dependency survives the product relationship.

A useful test: ask your most critical vendor for a full data export before you need one. The completeness of what you receive, and the friction involved in getting it, tells you more about your actual lock-in than any contract clause will.

The argument against interoperability mandates is that they will reduce investment incentives - that platforms will stop building if they cannot maintain proprietary advantage. The historical record does not support this.

Before number portability, switching carriers meant losing your phone number - a switching cost significant enough to suppress competition. The US FCC mandated local number portability in 1996. The prediction that carriers would stop investing in networks did not materialize. Instead, competition for customers intensified and network investment continued. The market grew. Removing the artificial switching cost forced carriers to compete on price and service quality.

Email is interoperable by design. SMTP, IMAP, and POP3 are open standards that any client and any server can implement. The result is a communications medium that no single company controls, where switching providers means updating a setting, not losing your message history. The email market has remained competitive across decades in a way that messaging platforms built on proprietary protocols have not. Signal cannot message WhatsApp. iMessage cannot message Telegram. Email can message anything.

The EU's Payment Services Directive 2 (PSD2) and the UK's Open Banking standard required banks to expose customer data through APIs accessible to third parties with customer consent. The predicted disruption to banking stability did not occur. What occurred was a wave of fintech development that built on top of open banking infrastructure - budgeting tools, lending platforms, payment services - that would not have been possible without portable financial data. The mandate created a market.

The web's foundational design choices were interoperability choices. HTML is a documented standard. HTTP is an open protocol. Any browser can render any page. Any server can host any content. The absence of a proprietary lock on the browsing experience enabled the web to grow into the infrastructure of the global economy within a decade. The counterfactual - a web controlled by a single company through proprietary protocols - would have looked more like the walled gardens that now exist within it.

Each of these cases involves a domain where interoperability was not the default behavior of market incumbents and was achieved through external requirement. None of them resulted in reduced investment or innovation. All of them resulted in more competitive markets.

The Electronic Frontier Foundation's work on interoperability includes legal analysis, policy advocacy, and public education about the competitive and rights implications of platform lock-in. The EFF has argued for interoperability mandates as a consumer protection measure and as a prerequisite for a functioning competitive market in digital services.

The Free Software Foundation Europe has pushed for interoperability requirements in European digital regulation, including contributions to the Digital Markets Act framework. The argument in both cases is that voluntary interoperability does not emerge from markets dominated by platforms with strong incentives to maintain lock-in.

The EU's Digital Markets Act came into force in 2022 and began applying to designated gatekeepers in 2023. It is now far enough along to evaluate against its promises. The honest accounting is mixed.

The DMA's interoperability requirements are more specific than most prior regulation. Gatekeepers must provide portability of user data through APIs. Messaging services must open to third-party interoperability. Business users must have access to data generated through gatekeeper platforms. These are meaningful obligations on paper.

App store competition has shifted. Apple was forced to allow alternative app distribution in the EU. Browser choice screens returned. Some data portability APIs have been published that did not exist before. The threat of enforcement has accelerated timelines that would otherwise have stretched years longer.

Meta's data portability implementation has been widely criticized as technically compliant and practically useless - APIs that exist but transfer data in formats incompatible with any competing service. Apple's messaging interoperability requirement triggered years of technical objections, standards negotiations, and partial implementations that stopped short of genuine openness. The enforcement timeline for gatekeeper non-compliance runs to years, during which the lock-in compounds.

The structural challenge is that regulators must evaluate technical implementations they did not design, on timelines that favor incumbents. A platform can claim compliance, require the regulator to investigate and litigate the claim, implement incremental adjustments after adverse rulings, and repeat the cycle. The switching cost continues to accumulate throughout.

Regulatory intervention will eventually improve the interoperability landscape. Businesses that are waiting for it to happen before making infrastructure decisions are making a bet on a timeline they cannot control. The DMA is a forcing function operating over years. The lock-in you are building today is operational today.

The interoperability problem is not getting smaller. It is about to scale in a way that makes every existing lock-in dynamic more acute. AI agents are the mechanism.

An AI agent acting on behalf of a user needs to move data between systems constantly. It needs to read a CRM record, synthesize it with email history, update a project management task, and log the outcome somewhere. Every one of those operations crosses a platform boundary. Every one of those boundaries is a point where interoperability either exists or does not.

When agents operate manually, lock-in is a human problem - painful, but something a person navigates. When agents operate at machine speed and scale, lock-in at any platform boundary becomes a hard constraint on what the agent can do. The agent either stops, approximates, or finds a workaround. None of those outcomes are neutral.

Platforms are increasingly offering AI features that train on your data: custom models for classification, generation tuned to your brand voice, and retrieval systems built on your document corpus. This training creates a derivative asset, a model that encodes what you built, that has no portability standard. When you leave the platform, the model stays. You can recreate the training data from your export. You cannot recreate the trained artifact without rebuilding it from scratch on the new platform, paying to train again.

The same dynamic applies to vector databases built on your content. An embedding of a document encodes its semantic relationships in a format that is useful for retrieval but meaningless outside the model that created it. Different embedding models produce vectors that are not interoperable. If your platform switches model providers, or if you switch platforms, the index must be rebuilt. The content is portable. The intelligence encoded in the index is not.

AI agents that maintain persistent memory across sessions are building a representation of your preferences, your decisions, and your workflows over time. That memory currently lives in proprietary stores with no export standard. If you change agents or platforms, you start from zero. Every previous interaction - every preference the agent learned, every workflow it optimized - is gone. This is lock-in at the interface layer, not just the data layer.

There are no widely adopted open standards for AI asset portability. No standard for exporting fine-tuned model weights in a format another platform can use. No standard for transferring vector indexes between providers. No standard for agent memory export. The interoperability organizations working on this are early. The platforms deploying AI features at scale have no commercial incentive to wait for standards to emerge.

The window to establish interoperability norms in AI is now, before the lock-in compounds. The same dynamic that played out in SaaS over the past two decades will play out in AI infrastructure in the next five years. The outcome will depend on whether standards and policy move faster than platform entrenchment.

A business paying recurring fees to a platform it cannot leave without losing years of operational history is experiencing the consequences of absent interoperability directly. The regulatory fight for interoperability mandates is the policy-level version of the same argument.

The business does not need to wait for regulatory intervention. But understanding that the policy fight exists, who is making it, and why clarifies what is at stake in the infrastructure decisions made today.

The policy argument matters. The operational reality is more immediate. Here is a framework for evaluating your current SaaS stack for lock-in risk before you need to use it.

Do not wait for an event that forces the issue. Request a full data export from every platform that holds operational history - your CRM, project management tool, communication platform, analytics system. Evaluate what you receive: Is the data complete? Are relational links preserved? Is it in a format a replacement system could ingest? The answer tells you more than any vendor's documentation will.

An API used for building integrations is not the same as an API that supports bulk data extraction. Ask specifically: What is the rate limit for bulk reads? Are all data objects accessible via API, or only a subset? Is the API documented thoroughly enough to build a migration tool without vendor assistance? If the vendor does not have clear answers, treat that as signal.

Most SaaS contracts include language about data ownership and data return on termination. Read it. Specifically look for: time limits on data access after termination, format specifications for returned data, what happens to data derived from yours (including AI-trained models), and indemnification terms around export. If the contract is vague on format and timing, negotiate before you need to invoke those clauses.

Count how many of your critical operational dependencies - data, workflows, integrations - run through platforms that score high-risk on the matrix above. If more than half do, you are not operating on SaaS. You are a tenant in someone else's infrastructure with limited rights of exit. That concentration is a business continuity risk independent of any individual vendor's pricing decisions.

High lock-in scores on critical tools do not require immediate migration. They require a plan. For each high-risk vendor: identify the open-source or competitor alternative that could absorb your data, document what it would take to migrate, and build regular export testing into your operational calendar. Interoperability is easier to negotiate before you are desperate to invoke it.

Interoperability is the technical condition under which data generated on one platform can be used on a competing platform without loss of functionality. Without it, switching costs accumulate until platforms can raise prices without competitive consequence. Interoperability is the structural precondition for market competition in digital services.

The EU Digital Markets Act designates large platforms as gatekeepers and imposes interoperability requirements including data portability obligations that allow users to move their data to competing services. The Free Software Foundation Europe contributed to this framework. What open standards and interoperability look like in tool migration practice.

Open source platforms built on standard protocols support interoperability by default because their codebases are inspectable and their data schemas are documented. Proprietary SaaS platforms vary: some offer meaningful exports, others offer exports that cover data they are comfortable losing while retaining data most valuable for lock-in. The test is to run the export before you need it and evaluate what you actually receive.

AI creates new categories of data assets - fine-tuned models, vector embeddings, agent memory - that have no current portability standards. These assets encode intelligence built on your data but live in vendor infrastructure with no defined path for transfer. As AI features become central to platform value, this new layer of lock-in will compound the existing data portability problem.

Yes. Run data exports on your critical tools today. Evaluate API quality for bulk extraction, not just integration. Read data ownership clauses in your contracts before you need to invoke them. Score your vendor stack on a lock-in matrix and apply a concentration test. Interoperability risk is manageable when you assess it proactively. It becomes a crisis when forced migration is the first test of your data portability.

Electronic Frontier Foundation. eff.org.

Free Software Foundation Europe. fsfe.org.

Doctorow, Cory. The Internet Con: How to Seize the Means of Computation. Verso, 2023.

European Commission. Digital Markets Act (Regulation EU 2022/1925). eur-lex.europa.eu.

FCC. Local Number Portability. CC Docket No. 95-116, 1996.

Open Banking Limited. Open Banking Standard. openbanking.org.uk.