Why Office Unbound · Microsoft 365
An open-source alternative
to Microsoft 365.
A side-by-side account of how Microsoft 365 works today and how Office Unbound is being designed to work — what differs by architecture, what is a functional target, and what has actually been verified.
Project status Office Unbound is in Phase 1, architecture and evaluation. Every Office Unbound entry on this page is a design target; none has been verified in a release.
Start with what Microsoft 365 does well
A comparison that pretends otherwise is not worth reading.
Microsoft 365 is one of the most complete business platforms ever built. Exchange Online, SharePoint, OneDrive and Teams share one directory in Entra ID. Word, Excel and PowerPoint are the reference implementations of the file formats most businesses exchange every day. Microsoft Purview, Defender and Intune give large organizations retention, eDiscovery, data-loss prevention, threat protection and device management under one licensing roof. Thousands of third-party applications integrate through Microsoft Graph, and a large partner channel sells, configures and supports it.
Microsoft also runs the infrastructure. Datacenters, storage, patching, capacity and most of the security operations around the service are Microsoft’s problem, not the customer’s. For an organization with no appetite for running servers, that is not a side benefit — it is the product.
Office Unbound is being built for organizations that want a different arrangement: the same broad categories of tool, on infrastructure they or their provider choose, from software they can inspect, updated on a schedule they control. That is a real difference, but it is a difference in architecture and ownership. It is not a claim that Office Unbound will match Microsoft 365 feature for feature, and today it matches none, because nothing has shipped.
How to read this comparison
Three different kinds of statement, kept apart deliberately.
- Architectural distinction
- A difference in how the platform is built, licensed or operated — open source, customer-chosen hosting, customer-controlled updates. These follow from design decisions rather than from feature work, so they are listed separately. They describe the design; they become true of a product only when that product ships.
- Target functionality
- What Office Unbound is being designed to do, marked Planned or Under evaluation exactly as it is on the product pages. A target is an intention with a place on the roadmap, not a capability.
- Verified functionality
- Behavior demonstrated in a released, tested Office Unbound build. There is no such build yet, so the right-hand column reads Not verified on every row. That column will change row by row as evidence exists, and not before.
The Microsoft 365 column describes the service in general terms. Exact features vary by plan, region and add-on licensing; check Microsoft’s own documentation for your subscription.
Table 1
Where the architecture differs
These are the reasons Office Unbound exists. They concern who runs the platform, who can read its code and who decides when it changes.
On narrow screens, the tables on this page scroll sideways.
| Dimension | Microsoft 365 today | Office Unbound target | Office Unbound today |
|---|---|---|---|
| Hosting models | Microsoft’s multi-tenant cloud. Data-residency options exist for some regions and plans. On-premises server products are sold separately and are not Microsoft 365. | Design goal Customer-hosted or MSP-hosted on infrastructure the operator chooses; managed hosting only as a possible future option. | Not verified No installable release. |
| Customer infrastructure control | None below the tenant configuration. Network design, storage and hardware are Microsoft’s. | Design goal The operator controls hardware, network policy, storage layout and data location. Initial target: Linux VMs on Proxmox VE. | Not verified Deployment design in Phase 1. |
| Software licensing | Per-user subscription plans and add-ons, set and changed by Microsoft. Service stops working if the subscription lapses. | Design goal Open-source software license; costs move to infrastructure, operations and optional services. No Office Unbound license has been selected yet. | Not verified License not selected. |
| Source code availability | Proprietary. Customers rely on Microsoft’s documentation, audits and contractual assurances. | Design goal Public source for Office Unbound’s own components, built on open-source upstream projects whose source is already public. | Not verified Repository not published. |
| Update policies | Service updates arrive on Microsoft’s schedule, announced in the Message center; release rings and app update channels give some control over timing. | Design goal Customer- or MSP-approved updates with staging, maintenance windows and an emergency-patch path. | Not verified Update process being designed. |
| MSP customization | Partners resell and administer through Microsoft’s partner programs and delegated admin; the service itself is the same for every customer. | Design goal MSPs choose architecture, service plans, update policy and integrations per customer, with multi-tenant provisioning APIs. | Not verified Planned for Phase 6. |
| Support responsibility | Microsoft operates the service; partners or internal IT handle configuration and user support. | Design goal The operator — internal IT or an MSP — owns operations and first-line support. Support offerings for the software itself are not yet defined. | Not verified No support offering exists. |
| Deployment complexity | Low: sign up, verify a domain, assign licenses. | Design goal Higher by nature: servers, storage, DNS, certificates, backups. Repeatable deployment tooling is planned to reduce, not remove, that work. | Not verified No deployment tooling yet. |
| Ongoing operations | Mostly Microsoft’s: patching, capacity, availability, datacenter security. | Design goal The operator’s: monitoring, patching, backup, capacity and incident response, with central tooling planned to support them. | Not verified Operational tooling planned. |
| Data portability | Export is available — eDiscovery exports, PST, file download, Graph APIs — but in Microsoft’s formats and shapes. | Design goal Open standards and documented exports, portable configuration, and the ability to change operator without changing platform. | Not verified Export design in Phase 1. |
Table 2
What each platform is meant to do
Functional targets, with their roadmap status. Read the Microsoft 365 column as mature and in production; read the Office Unbound column as intentions under design.
- 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
| Dimension | Microsoft 365 today | Office Unbound target | Office Unbound today |
|---|---|---|---|
| Mail and calendar | Exchange Online with Outlook desktop, web and mobile; shared mailboxes, delegation, resource booking. | Planned Mailboxes, shared mailboxes, calendars, contacts and resources behind an Outlook-style webmail. Outlook desktop compatibility Under evaluation | Not verified Mail servers under evaluation. |
| Office applications | Word, Excel and PowerPoint on desktop, web and mobile — the reference implementation of the Office formats, including VBA macros. | Under evaluation Browser-based editing on an established open-source suite (Collabora Online or ONLYOFFICE candidates). Not full format fidelity. | Not verified Editors under evaluation. |
| File synchronization | OneDrive and SharePoint with a mature sync client, Files On-Demand and Known Folder Move. | Planned Personal and shared storage with a branded desktop client for Windows, macOS and Linux, selective sync and offline access. | Not verified Nextcloud leading candidate. |
| Team chat | Teams chat, channels, apps, guest access and deep integration with SharePoint and Office. | Planned Chat, channels and team workspaces on the open Matrix standard. Not full Teams parity. | Not verified Matrix and Element under evaluation. |
| Video meetings | Teams meetings, webinars and town halls, recording, transcription, room systems. | Planned Video meetings, screen sharing and calendar invitations; capacity depends on the operator’s infrastructure. | Not verified LiveKit and MatrixRTC under evaluation. |
| Telephony | Teams Phone, with Microsoft calling plans or carrier connections where offered. | Planned SIP-based business calling with extensions, queues and voicemail; carrier service separate. | Not verified Hardening phase; FreeSWITCH candidate. |
| Identity and administration | Entra ID with conditional access, hybrid identity with on-premises Active Directory, and the Microsoft 365 admin center. | Planned SSO, MFA and directory on OIDC, SAML and LDAP; one console for every service. Not Entra ID parity. | Not verified Keycloak under evaluation. |
| Security controls | Extensive: Defender, Purview, conditional access, sensitivity labels, depending on plan. | Planned Authentication policy, mail filtering, tenant isolation, audit logs, retention; plus inspectable source and SBOMs. | Not verified Security architecture in Phase 1. |
| Third-party integrations | A very large ecosystem through Graph, Teams apps, add-ins and Power Platform. | Planned Open management APIs and standard protocols; the ecosystem has to be built and will be far smaller. | Not verified API design in Phase 1. |
| Migration support | Microsoft and third-party tools for moving into Microsoft 365. | Planned Assessment engine, then guided migration out of Microsoft 365: mailboxes, OneDrive, SharePoint, Teams inventory, identities. | Not verified Discovery architecture in Phase 1. |
| Feature maturity | Many years of production use at very large scale. | Builds on mature upstream projects, but the integrated platform will be new, and new platforms have rough edges. | Not verified Pre-release. |
“Not verified” means no release exists to test against — not that a test failed.
Practical limitations
Where an organization leaving Microsoft 365 will notice the difference, whatever Office Unbound eventually ships.
Proprietary integrations
Power Automate flows, Power Apps, Teams apps, Outlook add-ins, Dynamics connectors and line-of-business software written against Microsoft Graph do not move to another platform. They have to be rebuilt, replaced or retired, and the assessment should find them before anyone commits to a date.
Advanced office features
VBA macros, Power Query, Power Pivot, complex Excel models, tracked changes in heavily formatted Word templates and some PowerPoint animations are not reproduced exactly by open-source editors. Files will open; some will not behave identically.
Historical collaboration data
Teams chat and channel history, meeting recordings, Planner boards, Loop components and Whiteboard content are only partly exportable through Microsoft’s APIs, and have no exact destination equivalent. Some of it will be archived rather than migrated.
Compliance tooling
Purview’s eDiscovery, retention labels, data-loss prevention and insider-risk tooling are mature. Office Unbound plans retention, audit trails and legal-hold workflows, but not equivalents for all of these, and it will hold no certifications of its own.
Desktop Outlook
Many users live in Outlook for Windows. Whether it can connect to the selected mail server well enough for daily use depends on Exchange-protocol support that is still under evaluation. Standards-based clients are the safer assumption today.
AI and assistant features
Microsoft is building AI assistance into its applications. Office Unbound’s roadmap does not include an equivalent, and this page does not pretend it does.
Office Unbound is not claiming Microsoft 365 compatibility, parity with any Microsoft service, or that moving will cost less. It is claiming a different architecture, and it will publish what has been verified as each component reaches testing.
When the trade makes sense
Microsoft 365 remains the right choice for many organizations. The case for an alternative is strongest where the architectural rows in Table 1 matter more than the functional gaps in Table 2.
- Data location, network design or hardware must be under the organization’s or its provider’s direct control.
- An MSP wants to build its own service rather than resell a subscription it cannot shape.
- The organization wants to read, scan or have someone review the code it runs.
- Updates need to be staged and approved rather than received.
- The core workloads are mail, calendars, files, documents and chat — not Power Platform or deep Teams app integration.
When it probably does not
Be honest with yourself about these before spending time on an evaluation.
- No one — internally or at a provider — is available to operate servers, backups and updates.
- The business depends on Excel macros, Power Automate or Teams apps that cannot be replaced.
- Compliance obligations are met today with Purview features that have no planned equivalent.
- Users need desktop Outlook against Exchange-grade server behavior, and cannot wait for that to be tested.
- The goal is a guaranteed lower bill. Office Unbound does not promise one; see cost and licensing.
Leaving Microsoft 365 in practice
Most of the work in leaving any platform is in the move, not the destination. Office Unbound plans a migration assessment that connects to a Microsoft 365 tenant with authorized, least-privilege access and reports what exists — users, groups, mailboxes, OneDrive and SharePoint content, Teams inventory — and what will transfer cleanly, partly or not at all, before any data moves.
Identities need particular care. Passwords and existing MFA registrations cannot be copied out of Entra ID through ordinary migration APIs, so users will enroll again. Mail cutover means DNS changes, and a period of coexistence where both systems are live. The migration pages describe how that is intended to work, step by step, including what a rollback can and cannot undo.
Migrate from Microsoft 365
Migration Assessment & Readiness Engine
Evaluating a move away from Microsoft 365?
Tell us which workloads you depend on and what would block you. It decides what gets built and tested first.