Microsoft 365 vs openDesk: which to choose

Microsoft 365 or openDesk: when each option fits

Choose openDesk when a Microsoft 365 renewal, a licensing change, a data residency rule or lock-in concern has started a serious look at self-hosting, and your organization is prepared to run a suite on Kubernetes under its own control. Microsoft 365 fits teams that depend on the desktop Office apps and want Microsoft to host and operate the service. openDesk fits organizations that need a self-hosted, operator-controlled suite, deployed to a CNCF-certified Kubernetes cluster and maintained by the organization or a partner. The decision turns on four questions: how much your staff depends on desktop Office, how much operating capacity your team can commit, whether you have Kubernetes skills in-house or can buy them, and whether the data must stay under your own control. Answer these before comparing feature lists, because they decide the architecture more than any single capability does.

Start with desktop Office dependency. openDesk's web office is Collabora, which is built on Collabora Online and edits .docx, .xlsx and .pptx files in the browser. If your users rely on Outlook desktop, Word macros, add-ins or offline Excel models, list each dependency and test it against the browser editors before you commit. Next, check operating capacity. openDesk expects production-grade external services such as PostgreSQL, Redis, an SMTP relay, object storage and a TURN server, and the openDesk requirements documentation lists the upgrade and version constraints you must plan around. Ask who patches the cluster, the bundled components and the supporting services, and what recovery looks like after a failed upgrade. Confirm with ZenDiS and your integrator whether Enterprise Edition support covers your production topology before you accept an estimate.

Which scenarios favor each option

This table maps common buying scenarios to the option that usually fits better and the condition that drives the choice. Read each row against your own requirements, since the right answer depends on desktop app dependence, regulatory obligations and the operating skills you have in-house. The main takeaway is that openDesk fits organizations that can run Kubernetes and want a full bundled suite, while Microsoft 365 fits teams that depend heavily on desktop Office and Outlook.

Scenario	Better fit	Condition that drives the choice
Heavy desktop Outlook and Office macro use	Microsoft 365	openDesk's web-based office components do not replace desktop Office or Outlook. Confirm which macros and add-ins your users depend on before planning a move.
Public administration or regulated bodies requiring self-hosting	openDesk	openDesk was built for public administration and is run in your own infrastructure. Confirm the approval, hosting and sovereignty rules that apply to your body.
Air-gapped operation with no internet connection	openDesk	openDesk is deployed to Kubernetes and can run offline, but its update and malware scanning workflows must be designed for your network. Confirm the offline update path with ZenDiS and your own team.
Small teams without Kubernetes operations	Microsoft 365	openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later plus production services such as PostgreSQL and object storage. Without staff to run these, a managed Microsoft 365 tenant usually lowers operational load.
Multi-app collaboration needs across files, chat, wiki and video	openDesk	openDesk bundles Nextcloud, Element, XWiki, OpenProject, Jitsi and Collabora under one deployment. Compare this with Microsoft 365 licensing and the workloads your teams actually use.
Strict control over licensing and component upgrades	openDesk	Each bundled component keeps its own license, and openDesk releases follow an annual major and monthly minor cadence. Confirm your upgrade window and whether the Enterprise Edition support model fits your change process.
Dependence on eDiscovery and Purview-based exports	Microsoft 365	Purview eDiscovery exports require an E3 or E5 license, and search export packages expire 14 days after creation. Plan retention and legal hold processes in openDesk separately.
Production use requiring vendor support contracts	Depends on support model	ZenDiS recommends openDesk Enterprise Edition for production, which adds SLA-backed support. Ask ZenDiS and your integrator which support tier and response terms apply before deciding.

How document formats behave across both options

openDesk uses Collabora as its web office, so Word, Excel and PowerPoint documents are opened and edited in the browser rather than in desktop Office. Collabora Online edits ODF and Microsoft formats, including .docx, .xlsx and .pptx, and it is the component that carries most of the document editing workload in an openDesk deployment. Your users will keep working with the same file types, but the editing surface, the rendering engine and the save path all change. Plan for that change explicitly rather than assuming a document will look the same on both sides.

Browser editing differs from desktop Office in ways that matter for regulated documents. Complex layouts, tracked changes with comments, embedded objects, fonts that are not installed on the server, and spreadsheet functions with less common behavior can render or recalculate differently. Macros (VBA) and Office add-ins do not run in the browser editor the way they do in Microsoft 365 Apps, so any document that depends on them needs a separate decision: rewrite the logic, keep that workflow in desktop Office, or retire it. Confirm with ZenDiS or your deployment team exactly which Collabora capabilities are enabled in your openDesk release, and do not assume an add-in or macro will run.

Test format fidelity with your own templates and documents before cutover, not with sample files supplied by a vendor. Build a short test set that includes your board packs, contract templates, financial models, forms with content controls, and any file that is regulated or used for external reporting. For each file, open it, edit it, save it back, and compare the output with the original in desktop Office, then record what changed. Agree with the business owners which differences are acceptable and which block the move, and keep the test results with your migration evidence.

Where the data lives and who controls it

Microsoft 365 runs in Microsoft's cloud under Microsoft's operating model, while openDesk runs in infrastructure you choose and operate. The cards below cover where data sits, who can run and support the stack, how identity and updates are handled, and which compliance evidence is yours to produce.

Microsoft-operated cloud boundary

Microsoft 365 hosts mail, files and chat in Microsoft's datacenters, and the data residency commitments that apply depend on your tenant configuration and contract. Residency requirements are the usual trigger for this review. Ask Microsoft in writing which workloads, storage locations and support access paths apply to your tenant, and record the answers before comparing them with an on-premises openDesk design.

Self-hosted openDesk in your infrastructure

openDesk is deployed to a Kubernetes cluster that you provide in your own cloud accounts, data centers or air-gapped networks. Your team or a delivery partner controls where Nextcloud files, OX groupware and the other bundled components store their data. The trade-off is that your organization owns the cluster, backups, patching of the underlying platform and the external services listed in the requirements. Confirm who holds on-call duty before you commit.

Enterprise Edition support model

ZenDiS recommends openDesk Enterprise Edition for production. It is offered as SaaS or as an on-premises installation, and it adds SLA-backed second and third level support and patches on top of the same open-source core. Choose the model based on who must be accountable for incidents. Ask the vendor which support hours, response commitments and patch delivery apply to your chosen model, and whether the closed-source modules affect your audit scope.

Identity federation with an external provider

In Microsoft 365, identity usually comes from Entra ID, which many organizations already operate. openDesk includes Nubus for portal and identity management, and its documentation covers federating users with an external identity provider. Decide whether your directory remains the source of truth for joiners, movers and leavers, and whether group membership maps cleanly to openDesk roles. Test deprovisioning explicitly, since access removal is where federation gaps usually appear.

Updates and the single minor version rule

Microsoft updates Microsoft 365 for you on its own schedule. With openDesk, your team applies releases. The project plans annual major releases in Q3 and monthly minor releases, supports only the latest minor version, and does not guarantee in-place upgrades between majors. If you fall several minor versions behind, you may need intermediate steps. Set a patch window, staging environment and rollback plan before go-live, and confirm the upgrade path with the vendor.

Compliance evidence and audit ownership

DeployOpen can prepare systems, controls and evidence for a compliance assessment, such as configuration records, access reviews and backup test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Microsoft 365 customers rely on Microsoft's published audit reports for the cloud layer, so ask your auditor which evidence they will accept for a self-hosted stack and plan collection before the assessment window opens.

Operating openDesk: what the platform needs from your team

An evaluation deployment is the cheapest way to see how openDesk behaves in your environment. The published minimum is modest, but it is a test footprint, not a sizing for real users. Plan the hardware and the Kubernetes platform beneath it before anyone asks for a demo.

Compute: At least 12 x64 CPU cores and 32 GB of RAM. ARM hardware is not supported yet, so Apple silicon or ARM server nodes need to be ruled out early.
Storage: More than 10 GB of disk for the evaluation footprint. Production storage is a separate sizing exercise.
Kubernetes: A CNCF-certified cluster at v1.33 or later, with an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, and an RWO volume provisioner.
Tooling: Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later, on the machine that runs the deployment.
Cluster choice: openDesk is tested on kubespray clusters and not on OpenShift. Confirm with ZenDiS or your platform team before reusing an existing OpenShift estate.

Confirm the hardware and cluster requirements against the current requirements document for the release you plan to deploy.

Cost components on each side, one-time and recurring

Microsoft 365 and openDesk are priced and operated in fundamentally different ways, so their costs do not line up line for line. Microsoft 365 is mostly a recurring subscription, while openDesk shifts cost into infrastructure, services and staff, with some one-time effort at the start. The cards below list each component, mark whether it is one-time or recurring, and name what moves it up or down. Request a written quote tied to your scope before comparing totals.

Microsoft 365 per-user subscriptions

Recurring. The main Microsoft 365 cost is the per-user subscription, billed for every licensed account for as long as the tenant stays subscribed. Your cost moves with headcount, the plan tier chosen for each user group, and any add-on licenses bought for specific roles. Shared mailboxes, guest users and service accounts may or may not need full licenses depending on the plan and how they are used, so confirm that mapping with Microsoft or your reseller. Ask for the total for your actual user mix and term, not a list price.

E3 or E5 licensing for eDiscovery export

Recurring, and often overlooked. Exporting mailbox items and SharePoint or OneDrive content through Purview eDiscovery requires an E3 or E5 license on the accounts involved, so an export project can force a plan upgrade for users who would otherwise sit on a lower tier. Check which accounts run the export, whether the licensing applies to the administrator or to the content owners, and whether the upgrade is needed only for the exit window or for ongoing compliance work. Ask the vendor to put these licensing assumptions in writing.

openDesk infrastructure and external services

Recurring. openDesk runs on a CNCF-certified Kubernetes cluster and expects production-grade external services, including PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Compute, storage, backups, load balancing and network egress are billed by your cloud provider or carried by your data center budget. Costs rise with user count, storage growth, high availability requirements and the number of environments (test, staging, production). Confirm sizing with your deployment team before estimating.

openDesk Enterprise Edition subscription

Recurring, optional by policy. ZenDiS recommends the Enterprise Edition for production. It adds closed-source modules, an Enterprise-only registry and license file, SLA-backed second and third level support and patches, and features such as Collabora automatic load scaling and Nextcloud Enterprise security patches. It is sold as SaaS or for on-premises installation. Compare the subscription with the cost of staff who would otherwise provide that support and patching. Ask which tier, which support hours and which SLA apply to your scope.

Internal staff for operations and upgrades

Recurring. Without an Enterprise subscription, or alongside one, your own platform engineers carry openDesk operations: monitoring, backups, certificate and Helm chart management, and upgrades. openDesk plans annual major releases and monthly minor releases, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Each upgrade needs test environments and time for regression checks. Cost rises with the number of environments, the frequency of upgrades and the skills gap on Kubernetes and identity federation.

Migration, deployment and integration services

One-time. Initial deployment, identity federation with your existing identity provider, mailbox and site migration, user onboarding, and integration with directory and single sign-on systems are the largest one-time items. Migration effort rises with mailbox volume, the number of SharePoint sites and OneDrive accounts, custom retention rules and the amount of Teams history you need to keep. Ask for the migration scope, the sequencing plan and which items are fixed-scope versus time-and-materials. Consider whether your cutover window requires parallel running, which adds temporary cost.

Storage, backup and exit retention

Recurring, with a one-time peak. Under Microsoft 365, storage limits and retention policies are part of the subscription, but exporting your data for a move creates temporary storage needs on your side. With openDesk, storage for files, mail and backups is your own cost, and backup retention, offsite copies and disaster recovery testing add recurring spend. Export tools also have their own time limits, so plan for holding exported data until the new platform is verified. Ask your provider how backups are scoped and who pays for restore testing.

What a move from Microsoft 365 to openDesk involves

The sequence below moves a Microsoft 365 tenant onto a self-hosted openDesk stack in stages, so each workload is proven on the target before any data is removed from the source. It produces a tested environment, verified exports and a cutover plan that accounts for the subscription lifecycle.

Confirm workloads and data in scope
Inventory the Exchange Online mailboxes, SharePoint sites, OneDrive accounts, Teams chats and files, and any retention or legal hold obligations that apply to them. Record which users, groups and document types matter most, and which content can be archived rather than migrated. The output is a signed inventory that the security, compliance and business owners have reviewed, with each item marked as migrate, archive or retire.
Build the Kubernetes platform and external services
Prepare a CNCF-certified Kubernetes cluster at v1.33 or later, with an ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile at the versions openDesk requires. Provision the production-grade services openDesk expects outside the cluster, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Your platform or infrastructure team owns this work. It is done when the cluster passes health checks and every external service is reachable from it.
Deploy a pilot with identity federation
Install openDesk in a non-production namespace and connect its identity layer to your existing identity provider using the federation approach described in the openDesk documentation. Confirm that a pilot group can sign in, that group membership maps correctly and that mail delivery, file sync and chat work end to end. The pilot is complete when a test user can complete the full workflow in each component without manual workarounds.
Map Microsoft 365 workloads to openDesk components
Document how Exchange Online maps to the groupware component, OneDrive and SharePoint to the file platform, Teams to the chat and video components, and Office for the web to the browser office editor. List every Microsoft 365 feature the teams depend on, such as shared mailboxes, co-authoring, Power Automate flows or retention policies, and mark which have no direct openDesk equivalent. Confirm each mapping with the owners of those features. The output is a gap register that leadership can accept or resolve before cutover.
Export mailboxes and content through Purview eDiscovery
Use Microsoft Purview eDiscovery to export Exchange mailbox items as PST or .msg files and SharePoint and OneDrive content as native documents, with version history where you need it. Exporting requires a Microsoft 365 E3 or E5 license, so confirm licensing before the project starts. Search export packages expire 14 days after creation, so download and checksum each package promptly and store it in an approved location. The step is complete when every package in the inventory has been downloaded, verified and logged.
Test document formats with real files
Load a representative sample of working documents, spreadsheets and presentations from the exported set into the target editor and compare them with the originals. Check tracked changes, comments, fonts, embedded objects, macros, tables and page layout. Record each failure by file type and decide whether it is fixed, accepted or handled by a manual process. The check is done when the teams that own the sample sign off on the results, and the list of known differences is published to users.
Sequence users and plan the cutover
Group users into waves based on business dependency, starting with a pilot group and ending with the teams that rely most heavily on shared mailboxes or live co-authoring. For each wave, set a freeze window, run a final incremental export, import the data, and confirm mail routing and access. Keep the Microsoft 365 tenant readable until each wave is verified. Because the subscription lifecycle can delete data after expiry, agree the retention dates in writing with the vendor and calendar exports well ahead of them.
Retire Microsoft 365 data and record evidence
After the final wave is verified, remove or archive remaining Microsoft 365 content according to the retention decisions made in the inventory, and keep the export packages and checksums under your records policy. Update DNS, mail routing and client configuration, and revoke licenses that are no longer needed. The step closes when the retirement log, data disposition records and the updated system documentation have been signed off by the owners of the data and the security team.

Questions buyers ask before choosing openDesk

How much does a move from Microsoft 365 to openDesk cost?

The cost depends on the scope agreed in writing, and no single figure applies to every organization. Costs fall into four groups: the Kubernetes infrastructure and the external services openDesk expects for production (PostgreSQL, Redis, object storage, an SMTP relay, a TURN server and ClamAV), the Enterprise Edition subscription if you choose it, the migration and integration work, and internal staff time. Infrastructure and subscriptions recur, while migration and hardening are usually one-time. Ask for a quote that separates these lines and states which parts ZenDiS, your cloud provider and DeployOpen each cover. DeployOpen does not publish prices, and a quote follows from the written scope.

How long does an openDesk migration take?

The timeline is set by the number of users, the volume of mailboxes, files and sites to move, how many integrations you need, and how many change windows your organization allows. Plan the sequence before the work starts: export mail and content through Purview eDiscovery while your E3 or E5 licensing is in place, and move users in waves so that data is not left to expire. The written scope should list each phase, its deliverables and the dependencies on your identity provider and network. Ask for milestones rather than a single end date.

What does our own team need to provide for an openDesk project?

Your team needs to supply the Kubernetes environment, approval for the network, DNS and certificate design, and access to identity sources. It also needs owners for mail routing, retention rules and the business decisions about which data moves and when. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and an RWO volume provisioner, so confirm those exist or are budgeted. Name a project owner on your side early, because most delays come from waiting on decisions rather than from software.

Can our internal staff run openDesk without outside help?

Some organizations run openDesk with internal staff, but it requires Kubernetes, Helm and Helmfile skills plus a plan for upgrades. openDesk plans annual major releases, monthly minor releases and on-demand patches, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Skipping several minor versions may need intermediate steps. Ask whether your team has these skills, how many people can carry the on-call load, and whether you want a retainer for upgrades and continuous support. DeployOpen offers ongoing support and upgrades as retainers.

Will desktop Office users keep their current workflow in openDesk?

Desktop Office users will work mostly in the browser, because openDesk uses Collabora as its web office rather than the Microsoft desktop applications. Documents in .docx, .xlsx and .pptx can be opened and edited, but layout, macros, add-ins and some advanced features can differ from desktop Office. Test your most important documents, templates and macros with a pilot group before you commit. Outlook users will also need a different client path, so confirm how mail clients connect to the groupware in your scope.

How does the openDesk Enterprise Edition change support?

The Enterprise Edition uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. ZenDiS recommends it for production and sells it as SaaS or for on-premises installation. Enterprise-only features include Collabora automatic load scaling, the Element AdminBot, GroupSync, the Nextcloud Guard app and OX S3 storage. Ask ZenDiS for the current SLA terms in writing, and ask how the subscription interacts with the work DeployOpen scopes.

Does openDesk cover air-gapped deployments?

openDesk is designed to be deployed on Kubernetes in your own infrastructure, which makes offline operation a possible fit, but it depends on your environment. Plan for how container images, Helm charts and updates reach the cluster without internet access, how malware scanning works through ClamAV over ICAP, and how the external services are provided on the isolated network. Confirm each requirement with ZenDiS and in your own environment, and put air-gapped delivery, update flow and evidence collection into the written scope before work starts.

How DeployOpen helps evaluate and migrate to openDesk

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including openDesk. For Microsoft 365 vs openDesk, the work starts with a written scope that tests fit against your actual workloads before any deployment begins.

How we scope

Map which Exchange, SharePoint, OneDrive and Teams workloads your organization actually uses before choosing components.
Confirm which Microsoft 365 features, such as desktop Office apps, need a documented alternative or an accepted gap.
Agree deliverables, timelines and responsibilities in writing, since most engagements are fixed-scope.

How we build

Deploy openDesk on your own Kubernetes environment, cloud account, data center or air-gapped network, with the prerequisites checked first.
Integrate identity, mail flow, file storage and document editing with your existing directory and security controls.
Test the deployed stack, including upgrade paths and security configuration, before users are moved onto it.

How we hand over

Document the architecture, configuration, component licenses and operating procedures for your own administrators.
Prepare export and cutover runbooks so mailboxes, files and sites move in a sequence your teams can repeat.
Deliver backup and recovery procedures and a clear record of what remains a gap or manual step.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover.
Plan openDesk upgrades around its annual major and monthly minor release cadence, with your change windows.
Discuss with your team whether Enterprise Edition support fits your production requirements before a quote is written.

Microsoft 365 vs openDesk