Why Office Unbound · Ownership & independence
Owning your data means
being able to leave with it.
Office Unbound is being designed so that a customer can export everything, move to a different operator or host it themselves, and arrive with their mail, files, configuration and users intact — with migration work, but without starting over.
Project status Portability is a design objective for every component under evaluation. None of the export or operator-migration tooling described here exists yet.
Legal ownership and practical ownership
Every major cloud provider’s terms say the customer owns its data, and they mean it. Microsoft and Google both provide export tools, and an organization can retrieve its mail and files. Legal ownership is not the issue.
Practical ownership is a different question. Where is the data physically stored, and who decides? Can you get it out in a form another system can use directly, or only in the provider’s formats? Does your configuration — users, groups, policies, sharing structures, mail routing — come with it, or only the content? Can you keep operating if the provider changes its terms, or if your relationship with the reseller who manages it ends? If the honest answer to those is “it depends on the provider,” then the data is owned but the platform is not.
Office Unbound aims to make each of those answers depend on the customer instead. That is what this site means by ownership.
Portability goals
Customer portability is one of the platform’s major design goals. These are its parts.
- 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 |
|---|---|---|
| Data export | Complete export of an organization’s mail, calendars, contacts, files, documents and chat history, in documented, standard formats where they exist. | Planned |
| Portable configuration | Users, groups, roles, policies, domains, shared-mailbox and sharing structures exportable in a documented form that another Office Unbound installation can import. | Planned |
| Independent hosting options | The same software runs customer-hosted or with any MSP, so leaving an operator does not mean leaving the platform. | Planned |
| Documentation | Published documentation of data locations, formats, export procedures and backup contents, so an organization does not depend on one operator’s knowledge. | Planned |
| Migration between operators | A supported procedure for moving a tenant from one operator to another, or from an MSP to self-hosting and back. | Planned |
| Open standards | Standard protocols and formats between clients and services, so data and client software are not tied to one implementation. | Planned |
| No proprietary data traps | No customer data held only in an undocumented internal format with no export path. | Planned |
Open standards by workload
The protocols and formats that make portability possible. Exact support depends on which upstream components are selected, so this is the intended baseline rather than a verified list.
| Data | Access protocols | Export formats | Notes on moving the data |
|---|---|---|---|
| IMAP, SMTP | Standard MIME messages (EML, mbox) | Folder structure and flags travel over IMAP; server-side rules need conversion. | |
| Calendars | CalDAV | iCalendar | Recurrences and attendees are standard; some sharing and delegation settings are server-specific. |
| Contacts | CardDAV | vCard | Widely supported by phones and desktop clients. |
| Documents | WebDAV and the files API | OpenDocument, Office Open XML, PDF | Stored as ordinary files; nothing to convert on the way out. |
| Files | WebDAV, sync client | Original files with folder structure | Sharing links and permissions need mapping on import. |
| Chat | Matrix client-server API | Matrix events (JSON) | An open, published specification; display in another product depends on that product. |
| Identity | OIDC, SAML, LDAP | Directory export | Passwords and MFA secrets cannot be exported usefully; users re-enroll. |
| Meetings and calls | WebRTC, SIP | Recordings as standard media files, where enabled | Live calls are not data to move; numbers move through carrier porting. |
Standards make portability possible; they do not make it automatic. Every move still needs mapping, verification and a cutover plan.
Changing operator
The planned procedure for moving a tenant — from one MSP to another, from an MSP to self-hosting, or the reverse.
Prepare the destination
The new operator deploys Office Unbound at a compatible version and provisions an empty tenant.
Export configuration
Users, groups, roles, policies, domains and sharing structures are exported in the documented configuration format and imported at the destination.
Copy content
Mail, calendars, contacts, files and chat history are transferred, in stages for large tenants, with counts and checksums compared afterwards.
Synchronize and cut over
Changes since the bulk copy are synchronized, DNS for mail and service names is moved, and clients reconnect. Users re-enroll MFA if the identity service changes.
Verify and decommission
Content and access are checked with real users, and the old tenant is retained until the customer confirms the move and agrees it can be removed.
Moving between operators is designed to be a well-defined project, not an instant switch. Large tenants take time to copy; DNS changes take time to propagate; there will usually be a short period of reduced service at cutover, and some settings will need checking by hand. The difference from leaving a proprietary platform is that the destination runs the same software, so nothing needs to be converted into a different product’s model.
What portability protects against
The situations where the ability to leave matters most are the ones nobody plans for.
Terms change
A provider changes pricing, bundles or conditions. With a portable platform the response can be a negotiation or a move, not a forced acceptance.
An operator fails
An MSP is acquired, closes or stops performing. The customer’s platform, data and configuration can go to another operator.
Requirements change
A new regulation or contract requires data in a particular place or on dedicated infrastructure. The tenant can move without changing software.
The project changes
If Office Unbound itself changed direction, open-source code and documented formats mean the existing platform keeps running and others can maintain it.
Arriving from Microsoft 365 or Google Workspace
Portability works in both directions, and the first direction most organizations will need is in. Moving from Microsoft 365 or Google Workspace is a larger project than moving between Office Unbound operators, because data has to be converted between different products’ models — labels to folders, native Google documents to files, SharePoint permissions to a different sharing model. The planned migration tooling, and the assessment that precedes it, exist to make that conversion visible and verifiable.
Does portability matter to your organization?
Tell us what you would need to be able to take with you. It helps decide which export formats and procedures are designed first.