· 5 min read

The Anatomy of a Microsoft 365 Dependency: What Actually Locks You In

Most organisations think their Microsoft dependency is about email. It is not. The real lock-in sits in identity, integrations, and workflows nobody documented.

Microsoft 365 Vendor Lock-in Identity

When organisations talk about replacing Microsoft 365, the conversation usually starts with email and ends with “it’s too hard.” But the difficulty is rarely about email. The real lock-in lives in layers most teams never think about until they try to leave.

This post maps the actual anatomy of a Microsoft 365 dependency: the layers that make migration hard, the ones that make it easy, and the ones nobody documents until it is too late.

Layer 1: Identity (The Deepest Lock-in)

Azure Active Directory (now Entra ID) is the most consequential Microsoft dependency most organisations have. It is also the most invisible.

When your SSO, MFA, conditional access policies, device management, and application permissions all flow through Entra ID, Microsoft does not just host your email. It controls who can access anything in your organisation.

Consider what happens if Azure AD becomes unavailable:

  • Every SSO-connected application stops working. Not just Microsoft apps, but Salesforce, Slack, Zoom, your CRM, your HR system, your finance tools.
  • MFA stops working. If you use Microsoft Authenticator, your employees cannot log into anything that requires two-factor authentication.
  • Conditional access policies disappear. Device trust, location-based access, risk-based authentication all depend on Entra ID evaluating every request.
  • Service principals and app registrations break. Automated workflows, API integrations, and background processes that authenticate through Azure AD all stop.

This is not a theoretical scenario. Organisations in sanctioned countries have experienced sudden loss of access to Microsoft services. The question for European businesses is not whether this could happen, but what their organisation would do in the first 24 hours.

Migration difficulty: Hard. Replacing Azure AD requires migrating every SSO connection, every conditional access policy, every device trust relationship, and every app registration. European alternatives like Keycloak, Authentik, or Kanidm exist, but the migration is months of work for any organisation with more than 20 SSO-connected applications.

Layer 2: Email (Easier Than You Think)

Exchange Online is the most visible Microsoft 365 component, but it is also one of the most replaceable. Email is a standardised protocol. IMAP/SMTP have been interoperable for decades.

European alternatives with mature feature parity:

  • Proton Mail for Business. End-to-end encrypted, Swiss jurisdiction, growing enterprise feature set.
  • Tutanota (Tuta). German-based, encrypted, focused on privacy.
  • Mailcow. Self-hosted, open source, full Exchange-like functionality.
  • Open-Xchange. European, enterprise-grade, used by major European telcos.

Migration difficulty: Easy to Medium. The email migration itself is straightforward. The complexity comes from:

  • Calendar and resource booking integrations
  • Shared mailboxes and distribution lists
  • Mail flow rules and transport rules
  • Third-party tools that integrate directly with Exchange (ticketing systems, CRMs, marketing automation)

Layer 3: File Storage (The Hidden Integration Web)

OneDrive and SharePoint seem like simple file storage, but they are deeply woven into Microsoft’s collaboration fabric:

  • Co-authoring. Real-time collaboration on documents uses proprietary protocols that do not work outside Microsoft’s ecosystem.
  • SharePoint sites. Many organisations use SharePoint as an intranet, a project management tool, and a document management system simultaneously.
  • Power Automate flows. Automated workflows triggered by SharePoint events (new file uploaded, document approved, list item changed) break when the storage layer moves.
  • Teams file tabs. Every Teams channel has a linked SharePoint folder; moving storage breaks the Teams integration.
  • Permissions model. SharePoint’s permission inheritance, sharing links, and guest access policies are proprietary and do not map cleanly to any alternative.

Migration difficulty: Medium to Hard. The files themselves are easy to move. The integrations, permissions, and workflows built on top of SharePoint are the real challenge.

Layer 4: Collaboration (Teams as the Operating System)

Microsoft Teams has evolved from a chat application into an operating system for work. It is where meetings happen, where channels organise projects, where approvals flow, where third-party apps are embedded, and where institutional knowledge accumulates.

Replacing Teams means replacing:

  • Chat history. Years of searchable conversations, decisions, and context.
  • Channel structure. Organisational patterns that teams have built their workflows around.
  • Meeting infrastructure. Calendar integration, recording, transcription, live captions.
  • App integrations. Every tab, bot, and connector connected to Teams.
  • Guest access. External collaboration with clients and partners.

European alternatives exist (Element/Matrix, Nextcloud Talk, Rocket.Chat), but none currently match Teams’ breadth as a unified workspace. This is often where organisations choose to accept the dependency, at least temporarily.

Migration difficulty: Hard. Not because the alternatives are bad, but because Teams integrates with everything else in the Microsoft ecosystem, creating circular dependencies.

Layer 5: The Integration Layer Nobody Maps

The most dangerous dependencies are the ones nobody documented:

  • Power Automate. Low-code workflows that connect SharePoint, Teams, Outlook, Planner, and third-party services. Most organisations have dozens of these running. Nobody has a complete inventory.
  • Power BI. Dashboards and reports connected to SharePoint lists, Excel files in OneDrive, and Azure SQL databases.
  • Microsoft Graph API. Custom applications that query user data, calendar availability, mail, files, and org charts through Microsoft’s unified API.
  • Intune/Endpoint Manager. Device management, compliance policies, and app deployment tied to Azure AD.
  • Microsoft Defender. Security tooling that depends on Microsoft’s telemetry and threat intelligence.

These integrations create a web of dependencies that is invisible until someone tries to pull one thread.

What a Realistic Exit Looks Like

A full Microsoft 365 exit is possible, but rarely necessary or wise to do all at once. The practical approach:

  1. Map everything first. You cannot plan a migration without a complete picture of what you depend on. This is what a dependency audit provides.
  2. Score each layer. Some layers are easy to replace (email). Others are deeply embedded (identity). Know which is which before making promises.
  3. Start with the highest-risk, easiest-to-move services. Usually email and basic file storage.
  4. Build identity independence. The single most impactful long-term investment is removing your dependency on Azure AD for SSO and MFA.
  5. Accept strategic dependencies. Some Microsoft services may be the best available option for now. The goal is to have a plan for each one, not to eliminate every US tool overnight.

The worst thing an organisation can do is assume the migration is simple because the email part is easy. The second worst thing is to assume it is impossible because the identity part is hard.

The right answer is a dependency map that separates what is easy from what is hard, and a roadmap that respects the difference.

Sovereign Shift produces exactly this: a dependency map that separates what moves easily from what requires careful planning, with a sequenced roadmap for each layer. Learn about our audit →