The Anatomy of a Google Workspace Dependency: What Keeps You Locked to Google

Google Workspace is often seen as the lighter-weight alternative to Microsoft 365. Fewer products, simpler licensing, less enterprise complexity. Organisations that chose Google early tend to believe they could switch to something else in a few weeks if they needed to.

That belief rarely survives contact with reality. Google Workspace creates dependencies that are structurally different from Microsoft’s, but just as deep. Some are harder to escape because they are less visible.

This post maps the layers of a Google Workspace dependency, from the deepest (identity) to the most subtle (institutional muscle memory), and assesses the migration difficulty of each.

Layer 1: Google Identity (The Foundation of Everything)

Google Workspace is, at its core, an identity provider. Every Google account in your organisation is a node in Google’s directory. That directory controls:

SSO connections to third-party applications. Most SaaS tools offer “Sign in with Google.” Each one is a dependency. A typical 25-person organisation has 10 to 30 third-party applications connected to Google SSO via OAuth 2.0 or SAML.
MFA. If your employees use Google prompts or Google Authenticator for second-factor authentication, the identity layer and the authentication layer are both Google-controlled.
Mobile device management. Google Endpoint Management enrols Android and iOS devices, enforces screen lock policies, and can remotely wipe devices. Leaving Google means re-enrolling every managed device.
OAuth token grants. Employees grant OAuth access to third-party apps through their Google accounts. These grants persist silently. Most organisations have no inventory of which applications hold active OAuth tokens.

The identity layer is the deepest dependency because everything else sits on top of it. An organisation that migrates its email and files but keeps Google as the identity provider has not materially reduced its dependency.

Migration difficulty: Hard. Replacing Google identity requires migrating every SSO connection (SAML and OAuth), every MFA enrolment, every device management policy, and every OAuth token grant. European alternatives include Keycloak, Authentik, and FusionAuth (US-based but self-hostable). Plan 3 to 6 months for a thorough migration.

Layer 2: Gmail (Simpler Than You Think, With Caveats)

Gmail is the most visible Google Workspace component, but email is a standardised protocol. IMAP and SMTP have been interoperable since the 1990s. The email migration itself, transferring messages from Gmail to another provider, is well-understood.

The complications are around Gmail:

Google Groups. Distribution lists, shared inboxes, and access control groups are all managed through Google Groups. They do not export to a standard format. Each group must be recreated manually in the target system.
Labels vs. folders. Gmail uses labels, not folders. A single message can have multiple labels. Most other email systems use folders, where a message lives in exactly one folder. The mapping from labels to folders can result in duplicated messages or lost organisational structure.
Confidential Mode. Messages sent with Gmail’s Confidential Mode have expiration dates and access restrictions enforced by Google. These protections disappear if the recipient’s mail system changes, and the original messages are not portable.
Send-as aliases. If employees send from multiple addresses through Gmail, those configurations must be rebuilt in the target system.
Mail routing rules. Inbound routing, content compliance rules, and attachment policies configured in the Google Admin Console do not export.

Migration difficulty: Easy to Medium. The core email migration takes days. Rebuilding groups, routing rules, and labels takes weeks.

Layer 3: Google Drive (The Collaboration Trap)

Google Drive appears to be a file storage service. It functions as something more: a collaboration platform with its own document formats, permission model, and real-time editing infrastructure.

The central issue is Google Docs, Sheets, and Slides. These are not files in the traditional sense. They are database-backed documents stored in Google’s proprietary format. When you “download” a Google Doc, you get an exported copy in .docx or .pdf format, not the original. The original only exists inside Google’s systems.

This means:

Comments and suggestions are lost on export. The discussion threads embedded in Google Docs, which often contain important decision context, do not survive export to .docx.
Version history is lost. Google Docs maintains a detailed version history with named versions. Exporting strips all of this.
Real-time collaboration stops. Google Docs’ real-time co-editing is a proprietary feature. No open-standard equivalent offers the same experience at the same scale. Nextcloud Office (based on Collabora Online) and ONLYOFFICE offer co-editing, but with different performance characteristics and feature sets.
Cross-document links break. Documents that link to other Google Docs by URL become broken references after migration.
Shared drives permissions are complex. Shared Drives (formerly Team Drives) have their own permission inheritance model. Members can have Manager, Content Manager, Contributor, Commenter, or Viewer access. Recreating this hierarchy in another system requires manual mapping.

Migration difficulty: Medium to Hard. Files can be exported in bulk using Google Takeout or third-party tools like Rclone. But the metadata (comments, versions, permissions, links) does not transfer. Organisations with thousands of Google Docs face significant manual cleanup.

Layer 4: Google Calendar (The Integration Hub)

Google Calendar is simple as a standalone product. It becomes complex as an integration point. In most organisations, Calendar is connected to:

Meeting room booking. Room resources are managed in Google Calendar. Migration requires recreating room resources in the target system and reconfiguring any physical displays or booking kiosks.
Video conferencing. Google Meet links are automatically generated for calendar events. If you move to a different video platform, every recurring meeting needs its links updated.
Third-party scheduling tools. Calendly, SavvyCal, and similar tools pull availability from Google Calendar. Each connection must be remapped.
CRM integrations. Salesforce, HubSpot, and other CRMs sync calendar events for activity tracking. These integrations depend on Google Calendar API access.

Migration difficulty: Medium. Calendar data exports cleanly via iCalendar (.ics) format. The integrations around the calendar are the real work.

Layer 5: Google Meet and Chat (The Communication Layer)

Google Meet is tightly integrated with Gmail and Calendar. Google Chat is tightly integrated with Spaces (Google’s channel-based messaging). Together, they form a communication layer that many organisations use for daily work without thinking of it as a separate dependency.

The lock-in is moderate but real:

Chat history. Conversations in Google Chat and Spaces do not export to a standard format. Google Takeout produces JSON files, but these are not importable into other chat platforms.
Spaces. If your organisation uses Google Spaces for project-based collaboration, migrating the content and structure to another platform (Element, Rocket.Chat, Nextcloud Talk) requires manual effort.
Meet recordings. Recorded meetings are stored in Google Drive. They are portable as video files, but the metadata (attendee list, transcript, timestamps) is Google-specific.

Migration difficulty: Medium. The technical migration is straightforward; the loss of chat history and Spaces context is the main cost.

Layer 6: Apps Script and Automations (The Invisible Dependencies)

Google Apps Script is Google’s answer to Microsoft’s Power Automate: a scripting environment that lets users build automations on top of Google Workspace. Apps Script can:

Send automated emails based on spreadsheet data
Generate documents from templates
Create custom forms and approval workflows
Sync data between Google Sheets and external APIs
Automate repetitive tasks in Google Docs, Sheets, and Slides

The problem is that Apps Script runs inside Google’s environment and depends on Google-specific APIs (SpreadsheetApp, DocumentApp, GmailApp, DriveApp). These scripts cannot be ported to another platform. They must be rewritten from scratch.

In our audits, we consistently find that organisations underestimate their Apps Script footprint. A 25-person company typically has 5 to 20 active Apps Scripts, some created by employees who have since left. Nobody maintains an inventory. Nobody knows which business processes depend on which scripts.

Google Sheets’ custom functions are a related dependency. Functions written in Apps Script extend Sheets’ capabilities in ways that break when the spreadsheet is exported to Excel or another format.

Migration difficulty: Hard. Every Apps Script must be inventoried, understood, and rewritten for the target platform. This is often the most time-consuming part of a Google Workspace migration.

Layer 7: The Google Admin Console (The Control Plane)

The Google Admin Console is where security policies, user provisioning, device management, app access controls, and audit logging are configured. It is the control plane for your entire Google Workspace deployment.

Specific dependencies include:

Security Investigation Tool. For organisations that use Google’s built-in security tooling, migration means replacing these capabilities.
Data Loss Prevention (DLP) rules. DLP policies configured for Gmail and Drive are Google-specific. They must be rebuilt in the target environment.
Audit logs. Google Workspace audit logs (login events, file access, admin changes) are retained in Google’s environment. Export is possible but limited.
App access control. The list of third-party applications that have been granted API access to your Google Workspace domain is maintained in the Admin Console. This list is itself a valuable dependency map.

Migration difficulty: Medium. The control plane must be rebuilt in the target environment. The real value of migration is the opportunity to review and tighten policies that may have drifted over years of organic growth.

Layer 8: Google Marketplace Apps and Third-Party Extensions

Google Workspace Marketplace offers thousands of add-ons that extend Gmail, Drive, Docs, Sheets, and Calendar. Organisations accumulate these extensions over time: a mail merge tool, a project management sidebar, a CRM connector, a document signing integration.

Each marketplace app is a dependency. Some are available on other platforms. Others are Google-specific. All require re-evaluation during migration.

Chrome extensions add another layer. If your organisation uses Chrome as its primary browser (which Google Workspace strongly encourages), employees may have installed extensions that depend on Google services. Password managers that sync through Google, tab management tools that integrate with Google Tasks, and productivity extensions that connect to Google Drive all create subtle dependencies.

Migration difficulty: Medium. Inventory every marketplace app and Chrome extension. Determine which ones are Google-specific and which have platform-independent alternatives.

A Realistic Assessment

Google Workspace migration is possible, and for some layers (email, calendar) it is genuinely straightforward. The difficulty concentrates in three areas:

Identity. The deepest and most consequential dependency. Plan this first, plan it carefully, and do not underestimate the scope.
Google Docs format. The proprietary document format creates data gravity that is hard to escape without accepting metadata loss.
Apps Script. Invisible automations that nobody documented and everyone depends on.

The organisations that migrate successfully are the ones that audit all eight layers before committing to a timeline. The ones that struggle are the ones that assumed Google Workspace was “just email and Drive.”

Sovereign Shift maps all eight layers of your Google Workspace dependency and delivers a scored migration plan. See pricing and scope →