Your ability to access and move data is essential for a wide range of data-intensive use cases, from business process automation to AI and analytics of all kinds. The more context — and less siloing — the better, as greater visibility into the bigger picture equips both people and machines to make better decisions.
Human employees hold tacit knowledge and context that may not be well documented or accessible to AI. As organizations increasingly rely on AI to guide or automate decision-making, data siloes pose greater problems.
In other words, data and the ability to access and move it have never been more valuable. At the same time, continued advancements in AI, especially software engineering co-piloting, have made the outlook for SaaS providers increasingly precarious, with SaaS stocks losing nearly $1 trillion in valuation in the first month of 2026. With AI's multiplicative effect on software engineering productivity, many business applications stand to become commoditized.
To ride the AI wave rather than get crushed by it, incumbent SaaS providers have very strong incentives to lock customers in, turning customers' ability to access their own data into revenue streams while they still can. Often, this means vendors obligating customers to use their proprietary analytics and AI solutions, creating “walled gardens.”
However, these enforced siloes are not only costly for customers but also degrade the efficacy and practicality of analytics and AI.
[CTA_MODULE]
How do data ownership and rights work in practice?
Data protection and other digital regulations around the world, such as the EU Data Act, increasingly provide customers of SaaS applications, including people and companies, with rights to the data they generate, such as data portability and control over data processing. These regulations also impose obligations and limitations on SaaS vendors. By contrast, contracts often speak in terms of data ownership. SaaS vendors typically state that their customers own all aspects of the data they generate (i.e., customer data) while the SaaS vendor owns other data related to the products being used.
However, even when regulations describe data rights, and contracts clearly define ownership, customers are not guaranteed control over their own data. Data control is the operational reality of how easily that data can be accessed, moved, and used. In practice, control is often shaped by platform constraints such as APIs and export limits, access and permission models that favor native tools, pricing structures that discourage movement, and regulatory requirements that affect how usable and observable data really is. SaaS vendors often have minimal incentive to clarify the resulting ambiguity between rights, ownership, and control.
Despite global trends reinforcing customers’ rights to the data they generate, vendors still take considerable latitude to control and limit customers’ access, portability, and permissible use for data that the customers nominally own.
Why SaaS data access restrictions, in particular, pose a problem
The practical consequence of the complexity surrounding data access, portability, and permissible use is that SaaS vendors now include clauses in master service agreements (MSAs) or terms of service that complicate the extraction and usage of data, including when a customer wants to end a contract and take their data to a subsequent vendor — something which, by rights, should be straightforward.
These contractual barriers are further buttressed by technical ones. Every SaaS system is proprietary software with a unique backend. Vendors have full control over what data is exposed programmatically to customers through an API or webhooks, and under what conditions. Specifically, vendors have imposed the following barriers:
Coverage
Customers should be able to fully access and leverage the core data models that underpin their activities and operations in an application. However, since vendors have complete control over how they expose data to their customers, they may gate key records and data models behind special arrangements, manual downloads, or make them unavailable entirely.
That said, complete, unfettered access to data may not always be practical, as multiple parties may have competing interests in and rights to the data. In verticals involving user personal data, such as search and ads, privacy concerns may mean that only aggregated data can be programmatically exposed to customers.
Performance
Even if all records are nominally available, vendors might make them difficult to extract by throttling output or preventing data-extraction software from incrementally detecting and replicating changes.
Egress costs
Vendors may require customers or third parties acting on their behalf to pay for data through licensing, fees, revenue sharing, mandatory participation in paid internal marketplaces, partner enrollment, or other barriers.
In other words, SaaS vendors have strong incentives to extract value from locking up your data and obligating you to access it on their terms. While it is unlikely that these measures will succeed in the long term — during which customers will almost certainly gravitate toward more open platforms — in the shorter term, vendors may reason that the imminent risks of commoditization justify this capture.
What can you do about vendors who lock up your data?
Ideally, vendors would make things as smooth as possible by offering programmatic access to all essential data, enabling high throughput with incremental updates, and imposing minimal egress costs on customers and third parties. In the meantime, you can evaluate and choose your SaaS providers accordingly.
If you’re already a heavy user of a vendor who complicates the extraction of data, technical solutions are often possible, if not particularly accessible through DIY data integration efforts. Fivetran leverages some of these methods to ensure that our customers can access their data.
Longer term, however, only transparency, along with sustained and organized pressure against vendors who engage in such practices, will systemically change things.
[CTA_MODULE]
