How SaaS Vendor Lock-in Actually Works: Seven Structural Layers That Keep European Organisations Stuck

Most organisations think of vendor lock-in as a contractual problem: long-term agreements, steep renewal prices, early termination fees. That is the surface layer. The real lock-in operates through at least seven distinct structural mechanisms, most of which are invisible until someone tries to leave.

Understanding these layers matters because each one requires a different approach to undo. Treating lock-in as a single problem leads to migration plans that fail at the first unexpected obstacle.

Layer 1: Identity and Access Control

The deepest form of lock-in is identity. When your organisation uses Azure Active Directory (now Entra ID) or Google Workspace as its identity provider, that vendor does not just host a service. It controls who can log into everything.

Single sign-on (SSO) connections fan out from the identity provider to every application in your stack. In a typical 25-person organisation, we see 15 to 40 SSO-connected applications: CRM, HR, finance, project management, support ticketing, code repositories, design tools. Every one of those connections is a dependency on the identity provider.

Conditional access policies add another dimension. Rules like “block access from outside the EU” or “require MFA for admin accounts” are written in the identity provider’s policy language. They do not transfer to another system. They have to be rebuilt from scratch.

Device trust is a third dimension. If your laptops are enrolled in Microsoft Intune or Google endpoint management, the identity provider also controls which devices can access your systems. Changing the identity provider means re-enrolling every device.

Why it locks you in: Replacing the identity provider requires touching every application, every policy, and every device in your organisation simultaneously. It is the single hardest migration to execute, and it must be planned months in advance.

Layer 2: Data Gravity

Data gravity is the principle that data accumulates in one place and becomes progressively harder to move as it grows. A startup that puts its first file in Google Drive has no lock-in. An organisation with 500,000 files, years of version history, and thousands of sharing permissions in Google Drive has significant data gravity.

The raw files are usually portable. Export works. But the metadata around those files is not:

• Sharing permissions. Who has access to which folder, with what level of permission. In a SharePoint or Google Drive deployment with nested team folders, guest sharing, and inherited permissions, recreating this structure in another system takes weeks of manual work.
• Version history. Most organisations rely on version history as an informal audit trail. Export tools rarely preserve it.
• Internal links. Documents that reference other documents by their platform-specific URL break when the storage layer changes.
• Comments and annotations. Discussion threads attached to files in Google Docs or SharePoint do not export cleanly to other platforms.

A 2023 study by Gartner found that 68% of organisations that attempted cloud-to-cloud file migrations underestimated the time required by a factor of two or more. The files moved quickly. The metadata took months.

Layer 3: Integration Coupling

Modern SaaS stacks are not isolated tools. They are interconnected systems. A typical mid-market organisation has dozens of integrations between its tools, and most of these integrations pass through the primary cloud vendor.

Consider a common pattern: a new lead enters the CRM (Salesforce or HubSpot), which triggers a notification in Slack or Teams, which creates a task in the project management tool, which updates a shared spreadsheet in Google Sheets or Excel Online. Every link in that chain is an integration point. Many of them depend on the primary vendor’s API or authentication layer.

Microsoft’s Power Automate and Google’s Apps Script are particularly effective lock-in mechanisms because they make it easy to build lightweight automations that become critical business processes. These automations are written in the vendor’s proprietary environment and cannot be ported to another platform without being rebuilt.

The European Commission’s 2024 report on cloud switching costs found that integration rebuild costs accounted for 40 to 60 percent of total migration costs for organisations with more than 20 employees.

Layer 4: Institutional Knowledge

This layer is the most commonly overlooked. When an organisation uses Microsoft 365 for five years, its employees develop deep fluency with Outlook, Teams, SharePoint, and Excel. That fluency is an asset. It is also a form of lock-in.

Switching to a different platform means retraining everyone. Not just a one-hour webinar, but months of reduced productivity as people learn new interfaces, new keyboard shortcuts, new ways of finding things.

The cost is real but hard to quantify. A 2022 analysis by Forrester estimated that productivity loss during a major platform migration costs organisations between 5 and 15 percent of total labour costs for the first three months after the switch.

This does not mean migration is not worth it. It means that institutional knowledge should be factored into the migration plan, not discovered during it.

Layer 5: Contractual Lock-in

The most visible form of lock-in, and the one most organisations focus on first. Enterprise agreements with Microsoft or Google typically include:

• Multi-year commitments. Three-year terms are standard. Early termination clauses exist but rarely favour the customer.
• Volume discounts tied to seat counts. Reducing seat counts mid-term may trigger repricing of remaining seats.
• Bundled pricing. Individual services (Exchange, SharePoint, Teams) are often cheaper when bought as a suite. Removing one component does not reduce the price proportionally.
• Annual price escalators. Built-in price increases of 5 to 10 percent per year are common, compounding over multi-year terms.

The EU Data Act (Regulation 2023/2854), which applies from September 2025, introduces new rules around switching charges. Article 25 requires cloud service providers to reduce switching charges progressively and eliminate them entirely after a three-year transition period. This is a significant regulatory shift, but it primarily addresses direct switching fees, not the structural lock-in described in the layers above.

Layer 6: Compliance and Audit Dependencies

Organisations in regulated industries often build their compliance infrastructure on top of their primary cloud vendor. Audit logs flow through Microsoft Purview or Google Vault. Data loss prevention policies are configured in the vendor’s admin console. Retention policies, legal holds, and eDiscovery capabilities are vendor-specific.

Migrating away from the vendor means rebuilding these compliance controls in the new environment, and demonstrating to auditors that the new controls are equivalent to what was in place before. For organisations subject to NIS2, DORA, or sector-specific regulations, this is not optional.

The irony is that compliance tooling, which exists to manage risk, becomes itself a source of vendor dependency risk.

Layer 7: Ecosystem Network Effects

The final layer is the hardest to escape because it operates outside your organisation’s boundaries. When your clients, partners, and suppliers all use the same platform, leaving that platform creates friction in external relationships.

A law firm whose clients expect to collaborate in Microsoft Teams faces a real cost in switching to Element or Nextcloud Talk: its clients may not follow. A fintech company whose banking partners require SharePoint-based document exchange cannot unilaterally move to a different platform.

This is the layer that often determines what stays and what moves. External ecosystem dependencies are frequently the reason organisations choose to maintain certain vendor relationships even after completing an internal dependency audit.

What This Means for Migration Planning

Each of these seven layers requires a different approach:

1. Identity requires early, careful planning. It is the foundation that everything else sits on. Many organisations benefit from running a parallel identity provider (such as Keycloak or Authentik) alongside their existing provider before cutting over.
2. Data gravity requires tooling for metadata preservation, not just file transfer. Budget twice the time you expect.
3. Integration coupling requires a complete inventory before any migration begins. Every Power Automate flow, every Apps Script, every webhook needs to be documented and assigned to an alternative.
4. Institutional knowledge requires a training plan built into the migration timeline, not tacked on at the end.
5. Contractual lock-in requires reviewing terms 6 to 12 months before renewal, not during.
6. Compliance dependencies require rebuilding controls in the target environment and validating them with your compliance team before migration.
7. Ecosystem effects require honest assessment of which external relationships are flexible and which are not.

The organisations that migrate successfully are the ones that understand all seven layers before they start. The ones that fail are the ones that treated lock-in as a single problem and discovered the other layers mid-migration.

Sovereign Shift audits all seven lock-in layers for European organisations and delivers a scored roadmap for reducing each one. Learn about our dependency audit →