The previous wave of SaaS consolidation was driven by feature competition. Better-featured products absorbed the users of inferior ones. All-in-one platforms absorbed point solutions by offering adequate versions of specialized tools inside a single contract and login. This dynamic is well-understood and its pattern is recognizable: the platform with the largest distribution advantage adds features, the specialized tool loses its differentiation, and the market consolidates around the platform. Feature competition is a game of scope, and the players with the most resources to expand scope typically win.
The next wave of SaaS consolidation will not be determined primarily by feature competition. It will be determined by data gravity — the force that accumulates as operationally critical data concentrates in one system and makes movement away from that system increasingly costly. Data gravity is different from feature lock-in because it operates through the accumulation of something that cannot be easily replicated: the history, context, and operational record that a platform holds after years of being the system where an organization’s critical work happens. A competitor with better features can attract a trial. A competitor cannot easily attract a migration when the customer’s operational history, workflow dependencies, and active data are embedded in the incumbent platform.
What data gravity means for SaaS platforms
Data gravity, in this context, means that a platform becomes harder to replace in proportion to how much of the organization’s operationally critical data it holds. Operationally critical data is data that the organization needs to access regularly to run its operations — customer records, transaction history, support history, product usage records, employee data, financial records. The more of this data a platform holds, the more the platform becomes load-bearing infrastructure rather than a tool the organization chooses to use. Load-bearing infrastructure is not evaluated the same way a tool is evaluated. It is evaluated against the cost of replacement, which includes not just migration cost but the operational risk of moving data that the organization depends on for daily decisions.
This creates a differentiation dynamic that operates independently of features. A platform that holds a customer’s five-year CRM history, including deal notes, relationship context, and activity logs, has a data gravity advantage that a newer platform with better UX cannot immediately close. The newer platform can be better. It cannot easily be the system of record for data that was generated in the old platform. The migration cost is not just technical — it is organizational. Teams that have worked with the old platform’s data for years have developed processes, reports, and institutional knowledge built on top of it. Moving the data moves the record. It does not move the processes, the interpretations, or the institutional knowledge that was built on top of it.
Which platforms are accumulating data gravity and which are not
Not all SaaS products accumulate data gravity at the same rate. The rate depends on two variables: how operationally critical the data is, and how uniquely it is structured in the platform. A product that holds data in standard formats that export cleanly and import into alternatives has low data gravity because the switching cost is primarily technical — a solvable problem given enough time and resources. A product that holds data in proprietary structures, that generates relationship and context data that cannot be recreated from a raw export, or that is the source of truth for decisions that would be lost in a migration, has high data gravity because the switching cost is organizational as well as technical.
The products accumulating the highest data gravity today are not always the ones with the most impressive feature sets. They are the ones that are closest to the operations that matter most to the organization. A financial management platform that holds the complete audit trail of every transaction is load-bearing in a way that a marketing analytics tool is not, because the financial records have regulatory, contractual, and operational dependencies that extend outside the software. A customer success platform that holds the complete history of every customer interaction, in context, over multiple years is load-bearing in a way that a project management tool is not, because the customer history is the foundation of the relationships the organization depends on for revenue.
The products that are failing to accumulate data gravity are the ones positioned at the edges of the workflow — the tools that produce outputs that are downloaded and filed, that hold data that is regularly exported to a different system, or that operate as interfaces to data that lives elsewhere. These products are useful. They are not accumulating the kind of structural position that survives a platform consolidation cycle.
What this means for founders building SaaS products today
The implication for founders is that the question of data strategy is not a feature question — it is a positioning question that determines whether the product is building toward a platform position or toward an integration position. Both are viable business models. Only one survives a data-gravity-driven consolidation event intact.
-
Identify whether your product is the system of record for any operationally critical data, and design toward that position if it is not. A system of record is the authoritative source for a specific type of data that the organization uses to make decisions. If your product is not the system of record for anything — if it reads from other systems and produces outputs that live elsewhere — it is an integration candidate. Identify one data type that your product could own as the system of record for your target customer, and build toward that ownership.
-
Design your data model to accumulate context that cannot be recreated from a raw export. Relationship data, historical context, decision trails, and annotated records — the kind of data that is built up through usage over time and that would be lost in a migration even if the raw records were preserved — is the data that creates gravity. A product that stores only what happened, without storing why and who and what was decided as a result, is storing replaceable data.
-
Make migration into your platform easy and migration out transparent but substantial. Easy migration in lowers the cost of switching to your product. Transparent migration out — showing customers what they would lose if they left — clarifies the data gravity that has accumulated. The goal is not to trap customers but to make the cost of leaving visible so that customers who stay do so with an accurate understanding of what the product is providing them.
-
Evaluate the consolidation risk to your product’s current position. Identify the two or three platform players in your market who have the distribution advantage and the data gravity to absorb your product’s functionality. Assess whether your product’s data gravity exceeds theirs for your target customer segment. If it does not, identify what your product would need to become the system of record for to build a defensible data position.
-
Track whether your customers’ usage is deepening their data dependency or remaining shallow. A customer whose data volume, relationship context, and historical record in your platform is growing over time is a customer whose switching cost is increasing. A customer whose usage is flat, who regularly exports their data to other systems, or who uses your platform as a pass-through rather than a store of record is not accumulating data gravity. The depth of data dependency in your customer base is the leading indicator of how your product will fare in the next consolidation cycle.
What survives the data gravity consolidation
The SaaS products that will survive the next consolidation cycle are not the ones that competed on features and won. Features can be replicated. The products that will survive are the ones that became operationally load-bearing for their customers — that accumulated years of critical data, that built the processes and reports and institutional workflows that depend on that data, and that make the cost of migration a serious organizational decision rather than a weekend engineering project.
This does not mean that feature quality does not matter. Features are what attract customers to the platform in the first place. But features are the entry requirement, not the retention mechanism. The retention mechanism for a platform that will survive consolidation is the data gravity that accumulates through years of being the place where critical work happens. Founders who understand this build differently from the start — they optimize for depth of data accumulation alongside breadth of features, they design their data model to hold context rather than just records, and they treat the system of record position as a strategic goal rather than an incidental outcome. The features make the product worth trying. The data gravity makes it worth keeping.
