Migration · Microsoft 365
Leave Microsoft 365.
Bring your business with you.
Office Unbound is being designed with a guided migration system intended to simplify moving users, email, calendars, contacts, files, and supported collaboration data from Microsoft 365 into the Office Unbound ecosystem.
Project status This is a product-development goal. The Microsoft 365 migration tooling is planned for Phase 5 and is not available; nothing on this page can be used yet.
What a tenant is made of
Microsoft 365 — formerly Office 365 — is several services that share an identity.
A Microsoft 365 tenant looks like one product to its users and like five to anyone moving out of it. Mail, calendars and contacts live in Exchange Online. Personal files live in OneDrive, which is SharePoint underneath. Team and department files live in SharePoint document libraries, and every Microsoft Team has a SharePoint site behind it holding its channel files. Conversations live in Teams. All of it hangs off identities and groups in Entra ID, formerly Azure Active Directory.
Each of these has its own data model, its own permission model and its own API behavior, and a migration has to treat them separately while keeping the relationships between them: the Microsoft 365 group that is at once a mailing list, a Team, a SharePoint site and a set of permissions. The planned Office Unbound tooling is designed around Microsoft Graph, Microsoft’s current API for these services. Microsoft has announced the retirement of Exchange Web Services in Exchange Online, so the design does not depend on it.
It is worth being fair about the source. Microsoft 365 is a mature platform with export, eDiscovery and retention tools of its own, and a large ecosystem built around it. Organizations that leave it usually do so for reasons of control, cost structure or dependency, not because it failed to work. The migration is meant to respect that by moving what it can accurately and saying clearly what it cannot.
Scope, workload by workload
What the tooling is being designed to move, with the status of each item. “Where supported” means the result depends on what Microsoft’s APIs expose and what the destination can represent; the assessment is intended to say which applies to a given tenant.
- 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 |
|---|---|---|
| Mailboxes | User mailboxes, including folders and their hierarchy. | Planned |
| Messages and attachments | Messages with their original dates, read state, flags and attachments. | Planned |
| Contacts | Personal contacts and contact folders. | Planned |
| Calendar events | Events including recurrences, exceptions to recurrences, attendees and reminders. | Planned |
| Shared mailboxes | Shared mailboxes with their members and permissions mapped to the destination. | Planned |
| Mailbox delegation | Send-as, send-on-behalf and full-access delegation, where supported. | Planned |
| Aliases and forwarding | Additional addresses and forwarding configuration discovered and re-created at the destination. | Planned |
| Distribution lists | Distribution groups and their membership, rebuilt as destination groups. | Planned |
| Calendar permissions | Who can see and edit whose calendar, where supported. | Planned |
| Online archive mailboxes | Archive mailboxes, depending on how far current Microsoft APIs expose them. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| User files | Each user’s OneDrive files moved to their personal destination storage. | Planned |
| Folder structures | Folder hierarchy preserved as it is in the source. | Planned |
| Supported metadata | Created and modified times and authorship, where the destination can record them. | Planned |
| Permissions mapping | Sharing with internal users and groups translated to destination permissions. | Planned |
| Shared content | Files others have shared, reconciled so they are owned once and shared rather than copied. | Planned |
| Version history | Earlier versions of files, where feasible within source access and destination storage. | Under evaluation |
| Large files | Chunked, resumable handling for files too large for a single request. | Planned |
| Capability | What it means | Status |
|---|---|---|
| Document libraries | Libraries moved to shared destination storage for the team or department that owns them. | Planned |
| Site-associated files | Files belonging to team sites and communication sites, including those behind each Team. | Planned |
| Folder structures | Library folder hierarchy preserved. | Planned |
| Sharing permissions | Supported sharing, including broken inheritance, translated or reported. | Planned |
| Shared document content | Office documents and other files in the library. | Planned |
| Metadata | Standard metadata and, where the destination can hold it, custom library columns. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| Team and channel inventory | Every team, its channels and channel types, cataloged for planning. | Planned |
| Team membership | Owners and members mapped to destination workspaces and groups. | Planned |
| Files in teams | Channel files, which are stored in SharePoint, moved with the SharePoint content. | Planned |
| Associated SharePoint content | Site content belonging to the team beyond the channel folders. | Planned |
| Chat and channel messages | Message history where Microsoft’s APIs and the granted permissions allow export. | Under evaluation |
| Meeting-related information | Meeting details and associated files, where export and destination compatibility permit. | Under evaluation |
| Capability | What it means | Status |
|---|---|---|
| User discovery | All users, with their licensing state and the workloads they use. | Planned |
| Group discovery | Security groups, Microsoft 365 groups and distribution groups, with membership. | Planned |
| Identity mapping | Each source identity matched to a destination account, with conflicts flagged. | Planned |
| Mailbox and domain assignments | Which addresses and domains belong to which account. | Planned |
| Organizational structure | Departments, managers and other directory attributes where present. | Planned |
| Account metadata | Display names, titles, phone numbers and other supported attributes. | Planned |
Teams: what to expect
The part of Microsoft 365 that is hardest to leave, and the part we are most careful about.
A Microsoft Team is several things at once. Its files are the most portable part: channel files are ordinary documents in a SharePoint library, and they are planned to move with the rest of the SharePoint content. Its structure — teams, channels, owners, members — can be read and re-created as destination workspaces with the same people in them.
Its conversation history is a different matter. Microsoft exposes Teams messages through Graph, but access to message content in bulk is treated as a protected capability: some of the relevant APIs require separate approval from Microsoft, and some carry licensing or metered-usage requirements of their own. Whether a complete, faithful export of an organization’s chat and channel history can be obtained, and at what cost, depends on Microsoft’s terms at the time and on the tenant. That is why the line above is marked under evaluation rather than planned.
Even where messages can be exported, some of what makes them meaningful does not travel. Reactions, edits, adaptive cards, app messages, loop components and links into other Microsoft services may arrive as plain text, a placeholder, or not at all. Meeting recordings that Teams has stored as files in OneDrive or SharePoint can move as files; their place in a meeting thread, transcripts and chat context are another question.
Office Unbound does not promise that full Teams history, Teams app integrations, meeting recordings in their original context, or proprietary Microsoft data will migrate. Teams migration is compatibility-dependent. A realistic plan for many organizations is to move files and structure, export the conversation history Microsoft allows for retention or reference, and start new conversations on the destination platform.
Passwords and MFA
Passwords and existing MFA secrets cannot generally be transferred through ordinary migration APIs. Entra ID does not hand out users’ password hashes or the seeds behind their authenticator apps, and it should not: that is part of what makes the source secure.
Every migration therefore includes an identity step for people, not just for data. Users will need to set a password on the destination — or authenticate through a single sign-on arrangement the organization chooses — and enroll their MFA methods again. The migration plan is intended to treat this as a scheduled, communicated activity with instructions and support, placed so that nobody is locked out of mail on the morning of cutover.
- Destination accounts created from the identity mapping, ahead of cutover.
- Enrollment invitations sent in waves, matched to the migration batches.
- MFA enrollment required before first sign-in to migrated data.
- Devices and mail clients reconfigured using documented steps.
- Enrollment progress shown per user in the control center.
Identity services are covered on the identity and administration page.
The planned workflow
Sixteen steps from first connection to agreed decommissioning. Each produces something the next one depends on.
Connect the tenant
A Microsoft 365 administrator authorizes access through Microsoft’s consent process, seeing each permission requested.
Discover users and services
Users, groups, domains and which services are in use.
Inventory content
Mailboxes, OneDrive accounts, SharePoint sites and libraries, Teams, groups and other supported content.
Assess compatibility and limitations
What is supported, partial or unsupported, item by item.
Map users and destination accounts
Identities, aliases, shared mailboxes and groups matched to destination accounts.
Select workloads
Which workloads move, for whom, and in which order.
Estimate volume and requirements
Data volumes, storage and infrastructure needed, with assumptions stated.
Run preflight checks
Domains verified, accounts created, quotas set, permissions confirmed, before any data moves.
Pilot migration
A small group of real users moved first and checked with them.
Staged data transfers
Workloads moved in batches, scheduled around business hours and source throttling.
Synchronize remaining changes
Mail and files changed since the bulk transfer brought across, where supported.
Plan DNS and service cutover
MX, autodiscovery and authentication records prepared, TTLs lowered in advance, the switch scheduled.
Validate migrated content
Counts, sizes, checksums where available, sampling and user acceptance.
Produce migration reports
What moved, what did not, and what was verified, per user and per workload.
Document unresolved items
Everything that still needs a person, with an owner.
Preserve source access
The Microsoft 365 tenant stays accessible until validation succeeds and decommissioning is agreed.
Architectural goals
The properties the migration tooling is being designed to have. Design objectives, not tested behavior.
| Goal | What it means in practice |
|---|---|
| Guided wizard | A sequence an experienced administrator can follow without a consultant, with each decision explained where it is made. |
| Administrative authentication | Access granted by a source administrator through Microsoft’s own consent, never by collecting users’ passwords. |
| Least-privilege API permissions | Only the Graph permissions the selected workloads need, read-only wherever reading is enough. |
| Encrypted credential and token handling | Secrets encrypted at rest, scoped to one project, never shown in logs or reports. |
| Progress reporting | Live totals per batch, per user and per workload. |
| Incremental migration | Change tracking used where the source supports it, so later passes move only what changed. |
| Retry | Transient failures and throttling responses retried with back-off; persistent failures recorded rather than retried forever. |
| Error reporting | Each failed item listed with its reason and the action needed. |
| Data verification | Source and destination compared after each stage, not only at the end. |
| Audit logging | Connections, approvals, runs and changes recorded with who and when. |
| Staged migration | Waves of users and workloads instead of one all-at-once move. |
| Coexistence support | Mail routing and directory continuity while some users have moved, where feasible. |
| Cutover assistance | Prepared DNS records, checks and a cutover checklist. |
| Recovery and rollback planning | A documented path back for each stage, and its limits — see below. |
Underneath all of these sit the constraints any migration tool has to respect: the data types involved, the source’s API limits and throttling, how the destination behaves, the provider’s licensing — source accounts generally need to stay licensed while their data is being read — and the authentication requirements at both ends.
A rollback plan is not an undo button. Before cutover, going back mostly means stopping and continuing to use Microsoft 365, which is why source access is preserved. After cutover, some changes cannot be reversed by any tool: mail that external senders delivered to the new system, messages users sent from it, DNS answers already cached elsewhere, and phones reconfigured to the new server. Office Unbound will not present rollback as automatically reversing every externally visible change; it will document what each recovery path does and does not restore.
Before anything moves
Assess the tenant first.
Every Microsoft 365 migration is planned to start with the Migration Assessment & Readiness Engine: an inventory of Exchange Online, OneDrive, SharePoint, Teams and Entra ID, a compatibility analysis against the destination, an identity mapping, estimates with their assumptions, and a readiness summary that ends at an approval gate.
For a Microsoft 365 tenant, the assessment is intended to surface the things that most often go wrong:
- Shared mailboxes and delegates that must move together
- SharePoint libraries with broken permission inheritance
- External sharing links that cannot be re-created as they are
- Microsoft 365 groups doing several jobs at once
- Applications and devices sending mail through the tenant
- Files with paths or names the destination will reject
- How much Teams history the granted permissions can reach
Planning to leave Microsoft 365?
See how the staged process is designed, or register to hear when Microsoft 365 migration tooling reaches early testing.