Migration · Google Workspace
Move beyond Google Workspace.
Keep the work you’ve built.
Office Unbound is being designed to support migration from Google Workspace, helping organizations transition business email, calendars, contacts, cloud files, users, and supported collaboration content.
Project status Google Workspace migration is planned for Phase 5 of the roadmap and is not available. This page describes the design intent and its known limits.
Leaving Google Workspace
Formerly G Suite, and before that Google Apps.
Google renamed G Suite to Google Workspace in 2020, and many organizations still use both names. Whatever it is called, it is a platform built from the browser outwards. That shapes what a migration out of it involves. A Microsoft tenant is full of files that already exist in standard formats; a Google tenant is full of documents that only exist as Google Docs, Sheets and Slides, and have to be converted to leave at all. Gmail organizes mail with labels rather than folders. Drive ties every file to an owner, except in Shared Drives, where the organization owns it.
Google provides capable export tools — Takeout for individuals, the data export tool for administrators, and Vault for retention and discovery. They produce archives suitable for keeping. They do not produce a working destination: mailboxes with folders people recognize, files in the right shared spaces with the right people able to open them, calendars that still know who was invited. That is the gap the planned Office Unbound tooling is meant to close, working through Google’s APIs for Gmail, Calendar, Contacts, Drive and the Admin SDK.
Where Google’s model and the destination differ
Most of the work in a Google Workspace migration is translation. These are the differences the assessment is designed to surface, each with the decision it implies.
| In Google Workspace | How it works there | At the destination | Decision needed |
|---|---|---|---|
| Gmail labels | A message can carry several labels at once; “folders” are a display of labels. | Folders, where a message lives in one place. | How multi-label messages are placed. |
| Docs, Sheets, Slides | Native formats with no file outside Google. | Standard OpenDocument or Office Open XML files. | Target format per type; what to do with files that convert poorly. |
| My Drive ownership | Each file has one owner, and is visible to whoever it is shared with. | Personal storage plus shared access. | Where files owned by departed users go. |
| Shared Drives | Owned by the organization, with drive-level membership roles. | Shared team or department storage. | How Google’s roles map to destination permissions. |
| Link sharing | “Anyone with the link” and domain-wide link access. | Share links under the destination’s own policy. | Which public links are re-created, and which retire. |
| Organizational units | A hierarchy used mainly to apply policy. | Groups, roles and policies. | Which OUs carry meaning worth keeping. |
| Groups | One object for a mailing list, a permission set and a forum. | Separate distribution lists and security groups. | Which role each group plays. |
What is planned to move
Each item with its status. Nothing here is available. Items under evaluation depend on what Google’s APIs permit and on testing that has not been done yet.
- Available Available and verified in a release
- In development Being built now
- Planned In the roadmap, not yet started
- Under evaluation Being assessed; not yet selected
| Capability | What it means | Status |
|---|---|---|
| Messages and mailbox history | The full mailbox, with original dates, read state and starring. | Planned |
| Attachments | Attachments carried with their messages. | Planned |
| Labels | Labels discovered and translated by the rule the administrator chooses. | Planned |
| Folder-style mapping | A folder structure built from labels, with multi-label messages handled as decided. | Planned |
| Sent messages | Sent mail placed in the destination’s Sent folder. | Planned |
| Contacts | Gmail contacts moved with the Contacts workload below. | Planned |
| Supported mail settings | Signatures, send-as addresses, forwarding and filters where an equivalent exists. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| Events | Individual events with times, time zones, locations and descriptions. | Planned |
| Recurring appointments | Recurrence rules and exceptions to them. | Planned |
| Invitations | Attendees and their responses, where the destination can record them. | Planned |
| Shared calendars | Secondary and shared calendars, not only each user’s primary one. | Planned |
| Calendar metadata | Colors, descriptions and reminders where supported. | Planned |
| Sharing permissions | Who can see and edit each calendar, where supported. | Planned |
| Personal contacts | Each user’s contacts with their fields. | Planned |
| Contact groups | Contact labels and groups. | Planned |
| Shared directory data | Directory and domain-shared contacts, where accessible. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| My Drive files | Each user’s files moved to their personal destination storage. | Planned |
| Folder structures | Folder hierarchy preserved, including files that appear in more than one folder. | Planned |
| Shared Drives | Organization-owned drives moved to shared destination storage. | Planned |
| Sharing permissions | Internal sharing with users and groups translated to destination permissions. | Planned |
| File ownership mapping | Owners mapped to destination accounts; files of departed users assigned as decided. | Planned |
| Metadata | Names, descriptions, created and modified times where the destination can record them. | Planned |
| Version history | Earlier revisions of uploaded files, where exportable and feasible. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| Document export | Google Docs exported for conversion. | Planned |
| Spreadsheet export | Google Sheets exported for conversion. | Planned |
| Presentation export | Google Slides exported for conversion. | Planned |
| Conversion to destination formats | OpenDocument or Office Open XML, as the administrator chooses. | Planned |
| Format validation | Converted files checked to open and render in the destination editor. | Planned |
| Compatibility reporting | Files with features that did not convert, listed individually. | Planned |
| Capability | What it means | Status |
|---|---|---|
| Space and conversation inventory | Chat spaces and their membership, where supported. | Under evaluation |
| Shared files | Files shared in Chat, which live in Drive, moved with Drive content. | Planned |
| Exportable messages and metadata | Chat message history, where Google permits export. | Under evaluation |
| Meeting information | Meet recordings and related files stored in Drive, where accessible. | Under evaluation |
Labels into folders
The single most common surprise in a Gmail migration.
Gmail labels do not map perfectly to folders, and no tool can make them. A message labeled both “Clients/Acme” and “Invoices” is one message in Gmail, appearing in two places. In a folder-based mailbox it has to be either in one folder, or copied into both. Either answer is defensible; neither is invisible to the people who use the mailbox.
The planned tooling makes this a decision taken before transfer, with the assessment showing how many messages carry more than one user label so the effect is visible in advance. The options being designed are:
- Copy into each folder. Every label becomes a folder and the message appears in all of them. Nothing appears lost, but the mailbox grows and deleting one copy does not delete the others.
- Place by priority. The administrator ranks labels; each message lands in the folder of its highest-ranked label, and the rest are recorded as tags or categories where the destination supports them.
- System labels only. Inbox, Sent, Drafts and Archive become their folder equivalents and user labels become tags, for organizations that rely on search rather than structure.
Gmail’s own system labels need handling too. “All Mail” is not a folder of extra messages but a view of everything, and must not be copied as one. Archived messages — those with no label at all — need a home, typically an Archive folder.
Docs, Sheets and Slides conversion
Native Google files have no existence outside Google. To migrate them they are exported through Google’s API into a standard format — Word, Excel and PowerPoint formats or their OpenDocument equivalents — and that exported file is what arrives. Conversion is a translation between two applications’ ideas of a document, and like any translation it is good for ordinary material and uneven at the edges.
Simple documents, ordinary spreadsheets and straightforward slide decks generally convert well. The planned tooling validates every converted file by opening it in the destination’s editing service and records what it can detect did not survive, so the compatibility report names files rather than offering a percentage. Owners of files that convert poorly can then check them or keep a reference copy.
Google’s export endpoints also have their own size limits for converted files, so very large native documents and spreadsheets may need special handling or manual export. The assessment is intended to flag them in advance.
- Google-specific spreadsheet functions such as IMPORTRANGE, GOOGLEFINANCE and QUERY, which other applications do not implement
- Apps Script automation and add-ons
- Comments, suggestions and their threads, depending on format
- Revision history of native documents, which does not export as files
- Linked charts, embedded Forms and smart chips
- Fonts and layout details without exact equivalents
- Real-time collaboration history and who-edited-what
The destination editors are covered on Documents & office applications, including its own compatibility limits.
Chat and Meet
Content that is planned to be inventoried, and moved only where Google allows.
Files shared in Google Chat are stored in Drive, and Meet recordings are saved to the organizer’s Drive, so both are planned to move as Drive content. What is uncertain is the conversation itself. Programmatic access to Chat message history is narrower than access to mail or files, depends on how the organization has configured Chat and retention, and requires permissions that Google treats with care. Whether a complete export of an organization’s Chat history can be obtained through supported APIs, and in a shape the destination can import, has not been established.
The realistic plan for most organizations is to inventory spaces and membership, move the files, retain an export of Chat history where it can be obtained for reference or compliance, and begin new conversations on the destination chat service.
Office Unbound does not promise complete Google Chat history, Meet recordings in their meeting context, or Google’s proprietary integrations. Chat and Meet migration is shown as under evaluation and will be described more specifically only once tested.
Users, groups and sign-in
The identity side of the migration starts in Google’s directory and ends with every user signed in to the destination with their own credentials and second factor.
- User discovery
- All users, suspended users and their workloads, from the Admin SDK directory. Planned
- Groups
- Google Groups with membership and the role each plays — mailing list, permission set or both. Planned
- Organizational units
- The OU hierarchy, mapped to groups or policy where it carries meaning. Planned
- Aliases
- User and group aliases, and secondary domains, re-created as destination addresses. Planned
- Supported metadata
- Names, titles, departments, managers and phone numbers where present. Planned
- Destination account mapping
- Each Google account matched to a destination account, with collisions flagged. Planned
- Enrollment and authentication planning
- A schedule for users to set credentials and enroll MFA, matched to migration waves. Planned
Google passwords and MFA secrets cannot simply be copied. Google does not export password hashes or the seeds behind authenticator apps and security keys, so users set new credentials and re-enroll their second factors at the destination. Organizations that already use an external identity provider for Google sign-in may be able to reuse it, subject to how that provider is integrated with Office Unbound’s identity service.
The planned process
Fourteen steps. Source API permissions, export limitations, file conversion and verification are part of the process, not footnotes to it.
Authorize source access
A super administrator authorizes the specific API scopes requested, typically through domain-wide delegation to a service account, and can revoke them at any time.
Discover Workspace data
Domains, users, groups, OUs and which services are enabled.
Inventory users and workloads
Mailbox sizes and counts, labels, calendars, contacts, My Drive and Shared Drive volumes, native file counts by type.
Map destination accounts
Users, aliases, groups and Shared Drive memberships matched to the destination.
Identify unsupported content
Files that will not convert cleanly, oversized exports, Apps Script, Chat history and anything without a destination.
Validation and preflight
Destination accounts, quotas, label rules and conversion formats confirmed before any data moves.
Pilot
A small group moved first, with their converted documents checked by the people who use them.
Transfer selected data
Workloads moved in batches within Google’s per-user and per-project API quotas.
Verify integrity
Message and file counts, sizes, checksums for uploaded files where Google provides them, and validation of converted files.
Final synchronization
Changes since the bulk transfer picked up through Google’s change tracking, where feasible.
Cut over mail and services
MX and related DNS records changed on a planned schedule, with TTLs lowered in advance.
Migration reports
What moved, what converted with losses, what did not move, per user and per workload.
Document remaining tasks
Files needing review, links to re-share, settings to re-create, each with an owner.
Confirm completion
Completion confirmed and approved before the Google Workspace subscription is reduced or closed.
Permissions
Read access to Gmail, Calendar, Contacts, Drive and the directory is requested per workload. Write access is needed only at the destination, which Office Unbound controls.
Export limits
Google applies quotas per user and per project, throttles bursts, and limits the size of converted exports. Schedules and estimates are built around those limits rather than around network speed alone.
Conversion
Native files are converted in transit and validated on arrival; the original stays in Google until decommissioning, so a poor conversion can be redone or exported by hand.
Verification
Uploaded files can be compared by checksum where Google reports one; converted files cannot, because the destination file is new, so they are checked by opening and sampling instead.
Google’s API quotas and throttling apply throughout, and Workspace accounts generally need to stay active and licensed while their data is being read. The full migration process
Assessment first
Know your Workspace before you leave it.
Every Google Workspace migration is planned to begin with the Migration Assessment & Readiness Engine. For a Google source it is designed to answer questions specific to Google’s model:
How tangled are the labels?
How many messages carry several user labels, and how much each label-mapping option would change mailbox size and layout.
How many native files?
Docs, Sheets and Slides counted by type, with files using features that are known not to convert flagged individually.
Who owns what?
Files owned by suspended or departed users, and content shared from outside the organization.
What is public?
Files shared by link with anyone, so a decision can be made before links stop working.
Running on Google Workspace?
Register for migration updates and tell us what you rely on most — Gmail, Drive, Shared Drives or native documents. It shapes what is tested first.