Migration
Changing platforms shouldn’t
mean starting over.
Office Unbound is being designed with migration as a core administrative feature: a guided, staged way to move users, mail, calendars, contacts, files and supported collaboration content out of Microsoft 365 or Google Workspace, with the limits stated before anything moves.
Project status Migration tooling is planned for Phase 5 of the roadmap and does not exist yet. The discovery architecture it depends on is being defined in Phase 1, the current phase.
Why migration is part of the product
An alternative nobody can move to is not an alternative.
Almost every organization that could run Office Unbound already runs something else. Years of mail, calendars full of recurring meetings, shared folders that whole departments depend on, permissions nobody remembers granting — that history is the business, and it lives in Microsoft 365 or Google Workspace. A platform that asks people to leave it behind, or to rebuild it by hand, will only ever be used by organizations starting from nothing.
So migration is not being treated as a services engagement bolted on afterwards, or as a set of scripts handed to the customer’s IT team. It is being designed as a feature of the administration console, with its own roadmap phase, its own data model and the same standard of auditability as the rest of the platform. The administrator who will run the new system is the person who runs the move into it, from the same place.
Microsoft and Google both provide export tools of their own, and they are good at what they are built for: compliance exports, eDiscovery, account takeout. What they are not built for is landing that data, correctly mapped and verified, in a different platform. That gap is where Office Unbound’s migration work sits.
The migration control center
The planned administrative workspace for a migration project, from connecting the source to signing off the result. Every line is planned; none exists 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 |
|---|---|---|
| Source platform selection | Choose Microsoft 365 or Google Workspace as the source; the rest of the workflow adapts to what that platform exposes. | Planned |
| Organization connection | Connect to the source tenant through the provider’s own administrative consent flow, with the narrowest permissions the job needs. | Planned |
| Tenant inventory | A catalog of users, groups, domains, mailboxes, drives, libraries and supported collaboration workloads. | Planned |
| User account mapping | Match each source identity to a destination account, including aliases, shared mailboxes and group memberships. | Planned |
| Workload selection | Decide per user or per group which workloads move, and in which wave. | Planned |
| Compatibility assessment | Supported, partially supported and unsupported items, identified before transfer rather than discovered during it. | Planned |
| Migration scheduling | Batches and transfer windows planned around business hours and source-side limits. | Planned |
| Progress tracking | Running totals of items, volume and errors for the project as a whole. | Planned |
| Per-user and per-service status | Where each person’s mailbox, files and calendar stand, separately. | Planned |
| Data integrity checks | Counts, sizes and, where the source provides them, checksums compared between source and destination. | Planned |
| Error reporting | Each failed item recorded with its reason, not folded into a summary number. | Planned |
| Retry of failed items | Re-run what failed without repeating what succeeded. | Planned |
| Administrative notifications | Alerts when a batch finishes, stalls or exceeds an error threshold the administrator sets. | Planned |
| Cutover planning | DNS, MX and client reconfiguration steps prepared and checked before the switch. | Planned |
| Migration audit trails | Who connected what, approved what and ran what, recorded for the life of the project. | Planned |
| Final completion reports | What moved, what did not, what was verified and what remains, in a form that can be signed off. | Planned |
No blind bulk copying
The philosophy behind every part of the migration design.
A migration that copies everything and hopes for the best moves the problems along with the data.
The easy way to build a migration tool is to point it at a source, copy whatever comes back, and report a percentage. It produces a satisfying progress bar and an unpleasant month afterwards, when people find calendar invitations without attendees, folders without their sharing, and documents that opened differently than they did last week. Office Unbound’s approach is to make the IT team understand the migration before they start it. Before data moves, the tooling is intended to answer these questions:
- What can migrate
- Content with a clear equivalent at the destination: messages and folders, calendar events, contacts, ordinary files and folder structures.
- What requires conversion
- Content that has to change form to arrive — native Google Docs, Sheets and Slides; Gmail labels that become folders; permissions expressed differently on each side.
- What cannot be migrated
- Content the source APIs do not expose or the destination has no place for — passwords and MFA secrets, many third-party app integrations, proprietary workflow data.
- What needs manual intervention
- Items that need a person’s judgment: ambiguous identity matches, files over a size the destination accepts, sharing links to people outside the organization.
- How long a transfer might take
- An estimate built from measured volumes and stated assumptions, with its uncertainty shown, not a single confident number.
- What happens during coexistence
- How mail is routed and how calendars behave while some people have moved and others have not.
- What requires downtime
- Which steps, if any, need users to stop working in the source system, and for how long that window has to be planned.
- What requires DNS changes
- MX, autodiscovery, SPF, DKIM and DMARC records that have to change at cutover, and the TTL planning that should precede them.
- What needs verification
- Which checks will be run, what they compare and what a person still has to confirm.
- What risks remain before cutover
- Open issues listed in plain terms, so the decision to switch is made knowingly.
No migration between two different platforms is lossless, and Office Unbound will not describe its tooling that way. The two sources model mail, files, permissions and collaboration differently from each other and from any destination. The goal is that every difference is known in advance, handled by a stated rule or a recorded decision, and reported afterwards.
Migration Assessment & Readiness Engine
Know what you’re moving before you move it.
Office Unbound’s planned migration assessment tools will help organizations inventory their existing Microsoft 365 or Google Workspace environment, identify compatibility concerns, estimate migration requirements, and build a practical transition plan before transferring data.
The assessment is a separate, earlier stage of the roadmap from the transfer tooling. It connects with read-oriented, least-privilege access, produces reports that IT staff, management and MSP customers can each use, and ends at an explicit approval gate: nothing moves until an administrator has read the findings and agreed to proceed.
It is also useful on its own. An organization that only wants to know how complicated leaving would be — and decides to stay — will still have an accurate inventory of its own tenant.
Organization inventory
Users, groups, domains, mailboxes, storage, workloads.
Data analysis
Sizes, counts, large files, transfer volumes.
Compatibility analysis
Supported, partial and unsupported items.
Identity mapping
Users, groups, aliases, permissions.
Estimates
Time, bandwidth, storage, infrastructure — with assumptions.
Risks, readiness, plan
Blocking issues, recommendations, phases, cutover.
Reports and approval
PDF and CSV output; explicit sign-off before migration.
Planned for Phase 5A. Not available.
Two source platforms, two different problems
Microsoft 365 and Google Workspace cover similar ground but store it differently, so each has its own migration design and its own page.
From Microsoft 365
Exchange Online mailboxes, shared mailboxes and calendars; OneDrive and SharePoint document libraries with their folder structures and sharing; Teams inventory and the files behind each channel; users and groups from Entra ID. The hard parts are permissions that span SharePoint and Teams, and Teams message history, which depends on what Microsoft’s APIs allow.
- Exchange Online, OneDrive, SharePoint, Teams, Entra ID
- Teams chat and channel history under evaluation
- A 16-step planned workflow
From Google Workspace
Gmail, Google Calendar and Contacts; My Drive and Shared Drives; and the native Docs, Sheets and Slides files that have to be converted to a standard format to leave Google at all. The hard parts are Gmail labels, which do not behave like folders, and the fidelity of converted documents.
- Gmail, Calendar, Contacts, Drive, Docs editors
- Google Chat and Meet content under evaluation
- A 14-step planned process
Migration for managed service providers
Many businesses will move with the help of an MSP, often several at once.
An MSP moving its customer base to a new platform is running a portfolio of migrations, not one. Each customer has its own tenant, its own authorization, its own schedule and its own idea of what “done” means. The migration control center is being designed so a provider can manage those projects side by side without any of them seeing the others.
- Multiple customer projects in one console
- Status visibility across all projects
- Predefined project templates
- Scheduling across customers and technicians
- Workload mapping per customer
- Administrative approvals at each gate
- Customer communication and notices
- Auditability per project and technician
- Customer-facing validation reports
- Integration with MSP workflows and tools
Each customer’s source credentials, inventory and transferred data are intended to stay inside that customer’s tenant boundary. A technician’s access to a migration project is to follow the same delegated-administration rules as the rest of the platform, and the planned management API is intended to report migration status to MSP platforms such as clientst0r. All of this is planned.
How a migration is intended to run
The same staged shape applies to both sources. Each stage has a defined output and, where a mistake would be expensive, an approval before the next one starts.
Two principles run through all of it. Source access is kept until the result is verified and decommissioning is agreed, so there is always somewhere to go back to. And the cutover is planned as its own step — DNS changes, TTLs, mail routing and user communication — rather than happening as a side effect of the last batch finishing.
Assessment
Planning and mapping
Pilot
Staged transfer
Delta synchronization
Cutover
Verification
Coexistence, where needed
Decommissioning
Planning a move off Microsoft 365 or Google Workspace?
Tell us which platform you run and which workloads matter most. It shapes which connectors and checks are designed and tested first.