Office Unbound

Resources · Roadmap

Development roadmap

Seven phases, ordered by what depends on what. Each says what it is meant to produce. There are no dates, because there is no evidence yet to put dates on.

Project status Phase 1, architecture and evaluation, is the current phase. Every later phase is planned and has not started.

How to read this roadmap

An order of work, not a schedule.

Office Unbound is assembled from established open-source components with a custom layer of identity, interface, administration and migration services on top. The order of the phases follows from that. The components have to be chosen before they can be integrated. Identity and mail come before chat and meetings because everything else signs in through identity, and mail is what an organization notices first. And migration tooling needs a working destination before it can move anything into it.

The phases describe dependencies, not strict sequence. Work on a later phase can start while an earlier one is still finishing when the two don’t block each other. The clearest case is migration. Its discovery architecture is defined in Phase 1, and prototypes of the assessment engine may be built well before Phase 5 formally begins, because an organization that wants to leave Microsoft 365 or Google Workspace first needs to know what it would be moving.

Why there are no dates

A date published before the components are selected and the integration is designed would be a guess, and people plan around guesses as if they were commitments. Dates will be added to a phase once there is enough built work to estimate from. Until then, the project updates page records what has actually happened, with the date it happened.

The phases

What each phase covers and what it is meant to produce. The current phase is marked; every other phase is planned.

  1. Phase 1

    Architecture and evaluation

    Current phase

    Choosing the components, confirming their licenses allow what the platform needs, and designing how they fit together under one identity and one administration layer. This phase produces the decisions every other phase builds on, so it is being done before any code is written for them.

    • Technology selection for each workload
    • Licensing evaluation of every candidate component
    • Security architecture and tenant-isolation model
    • Core platform requirements
    • Integration design between components
    • Migration discovery architecture
    • Source API requirements for Microsoft 365 and Google Workspace
    • Permission models for least-privilege source access
    • Migration compatibility matrix
    • Assessment methodology
    • Assessment report specifications
  2. Phase 2

    Core services

    Planned

    The services an organization cannot work without, integrated under one sign-in. At the end of this phase a small organization should, in principle, be able to run its mail, calendars, files and documents on the platform. Feature depth will still be limited at that point.

    • Identity: single sign-on, MFA, users and groups
    • Email and shared mailboxes
    • Calendars and contacts
    • File storage and sharing
    • Browser-based document editing
    • Administrative foundations: the first version of the console and management API
  3. Phase 3

    Collaboration

    Planned

    The Teams-style layer: persistent chat and channels on an open messaging standard, meetings and notifications, joined to the files and calendars from Phase 2 so a team has one place to work.

    • Direct and group messaging
    • Channels and threaded discussion
    • Video meetings and screen sharing
    • Notifications across services
    • Integrated team workspaces
  4. Phase 4

    Client experience

    Planned

    The point at which the platform looks like one product rather than several: a single interface, a branded desktop client for file sync, mobile access and a first-run experience that does not need an administrator standing behind the user.

    • Unified Office Unbound interface
    • Desktop clients for Windows, macOS and Linux
    • Mobile access
    • Offline synchronization of local files
    • Guided onboarding and account enrollment
  5. Phase 5A

    Migration Assessment Engine

    Planned

    A guided tool that connects to an existing Microsoft 365 or Google Workspace environment with authorized, least-privilege access and works out what a migration would involve before anything is moved. Know what you’re moving before you move it.

    • Organization inventory — users, groups, domains, mailboxes, calendars, contacts, storage and supported collaboration workloads
    • Data analysis — mailbox sizes, message counts, file counts, total storage, shared content, large files and estimated transfer volumes
    • Compatibility analysis — supported, partially supported and unsupported features, file formats, permissions and integrations
    • Identity mapping — users, groups, aliases and permissions mapped to the proposed Office Unbound environment
    • Migration estimates — transfer time, bandwidth, storage, infrastructure and potential costs, with assumptions and uncertainty stated
    • Risk assessment — potential data loss, unsupported workloads, API limits, required licensing, access issues and operational dependencies
    • Readiness scoring — a migration-readiness summary with actionable recommendations and blocking issues
    • Migration planning — recommended phases, coexistence options, cutover requirements, DNS changes, verification and recovery strategies
    • Exportable reports — PDF and CSV reports for IT staff, management and MSP customers
    • Approval gates — explicit administrator approval before an assessment can proceed to migration
  6. Phase 5B

    Migration execution

    Planned

    The connectors and orchestration that act on an approved assessment: moving mail, calendars, contacts and files in stages, checking the result and reporting what remains.

    • Microsoft 365 connectors: Exchange Online, OneDrive, SharePoint
    • Google Workspace connectors: Gmail, Calendar, Drive, Docs
    • User discovery and account mapping
    • Mail and calendar migration
    • File migration
    • Content conversion, including native Google formats
    • Supported collaboration data where source APIs allow
    • Incremental transfers
    • Job scheduling and retries
    • Progress monitoring
    • Data validation workflows
    • Staged cutover and recovery procedures
    • Completion and migration reporting
  7. Phase 6

    MSP and enterprise

    Planned

    Everything needed to run the platform for many organizations from one place, and to fit into the systems MSPs and enterprise IT already use. The tenant-isolation model is designed in Phase 1. This phase builds the multi-tenant tooling on top of it.

    • Multi-tenant management
    • Delegated, per-customer administration
    • Management and provisioning APIs
    • clientst0r integration
    • Security and maintenance policies
    • Audit reporting
    • Backup orchestration
  8. Phase 7

    Hardening and expansion

    Planned

    Testing and extending the platform so it holds up for larger and more demanding deployments, and adding the workloads that depend on a stable base, telephony in particular.

    • Security testing, including independent review
    • Performance testing
    • High availability
    • Recovery testing
    • Business telephony
    • Advanced governance
    • Enterprise scalability
    • Broader application compatibility

Migration starts before Phase 5

Most organizations that could use Office Unbound already run on Microsoft 365 or Google Workspace, and the hardest part of leaving is knowing what you have. So migration is spread across the roadmap rather than left until the end.

In Phase 1 the project defines what the assessment needs to read from each source platform, which API permissions that requires and how results will be reported. Prototypes of discovery and assessment may be built alongside Phases 2 to 4, partly to test those designs against real tenants. Phase 5A turns them into a supported tool, and Phase 5B adds the connectors that move data.

Migration overview

  1. Phase 1 — design

    Discovery architecture, source API requirements, permission models, compatibility matrix, report specifications.

  2. Alongside Phases 2–4 — prototypes

    Possible early assessment prototypes, to check the design against real environments.

  3. Phase 5A — assessment

    Inventory, analysis, risk, readiness, planning, reports and approval gates.

  4. Phase 5B — execution

    Connectors, staged and incremental transfer, validation, cutover and reporting.

How statuses are decided

The same labels appear on every page of this site.

Current phase
The phase the project is working in now. Only one phase carries it at a time.
In development
Work that is actively being done. Today that means Phase 1 itself: architecture, evaluation, licensing review and migration discovery design.
Planned
In the roadmap and intended, but not started. Most product capabilities on this site carry this label.
Under evaluation
Being assessed and not yet selected. Technology candidates carry it, and so do capabilities whose feasibility is genuinely uncertain, such as Outlook desktop compatibility or exporting Teams chat history.
Initial target
Chosen as the first deployment target: Linux virtual machines on Proxmox VE.
Available
Released and verified. Nothing carries this label today, and nothing will until it ships in a release that can be installed and tested.

A capability changes label when the work behind it changes, not when it is announced. A component moves from “under evaluation” to selected only when the evaluation is written up, and that change will be recorded in project updates.

This roadmap will change

The order of phases reflects today’s understanding, and Phase 1 exists to test that understanding. Some outcomes would change the plan. A candidate component might fail evaluation on licensing or on multi-tenant behavior. A source API might turn out to expose less than expected. Early-access registrations might show that a workload matters more than assumed. Any of these could reorder work, split a phase or move an item between phases.

When that happens, this page changes and the reason goes into project updates, so anyone who planned around an earlier version can see what moved and why. Older versions will not be silently rewritten.

What this roadmap does not promise

It is not a commitment to deliver every item listed, or to deliver it in the form described. Items such as Teams chat history migration or Outlook desktop compatibility depend on external APIs and protocols outside the project’s control, and they will be described as they are found to work, partially work or not work.

Want to hear when a phase moves?

Register for early access and tell us which workloads you would test first. We contact registrants when a component they care about reaches early testing, and when the roadmap changes in a way that affects them.

Request early accessProject updates