Microsoft 365 Local vs self-hosted open source: who controls updates, licences and hardware
Microsoft 365 Local keeps Exchange and SharePoint in your datacenter under Microsoft's software lifecycle, while self-hosted open source puts the update cadence, the licence terms and the hardware choices under your own governance. Which one fits depends on which workloads matter most and how much lifecycle commitment you need. Start by listing each workload (mail, calendar, files, sites, chat) and the date each one must still be supported, because that date drives both the platform and the hardware decision. On the lifecycle question, the facts are specific. Exchange Server Subscription Edition reached general availability on July 1, 2025 and follows the Modern Lifecycle Policy with no fixed end date, provided your configuration stays current, and Microsoft plans no further year-based major versions. Exchange Server 2019 follows the Fixed Lifecycle Policy, and its extended support ended in October 2025. If you still run 2019, you are already outside Microsoft's security servicing for that product, so confirm your current version before comparing any option.
On the open-source side, control shifts to you and to the vendors you contract with. openDesk has an annual major release cadence, monthly minor releases and only the latest minor version is supported, so your team must plan regular upgrades. Nextcloud publishes a new major version every four months and supports each for one year, and it does not allow skipping major releases. Open-Xchange supports standard releases for 12 weeks and LTS releases until the next LTS plus six months. Ask each vendor for its written support commitment, its supported upgrade paths and who performs the upgrades in your environment. Licensing and hardware are where the costs diverge. Nextcloud Hub and Collabora Online's community editions are free to self-host, while enterprise subscriptions add support and lifecycle commitments. openDesk's deployment automation is Apache 2.0, but each bundled component keeps its own licence, so review those separately. For hardware, openDesk needs a Kubernetes cluster at v1.33 or later plus production-grade PostgreSQL, Redis, object storage and an SMTP relay. Microsoft 365 Local ties you to Azure Local hardware and Microsoft's licensing terms. Ask each vendor for a bill of materials and a written licence summary before you commit.
What a datacenter-hosted productivity platform must control
Hosting Office, mail and files in your own datacenter moves update timing, licensing, hardware and data exit back to your team. Each card below names one control point and the check to make before committing to either Microsoft 365 Local or an open-source stack.
Who applies updates
Exchange Server SE follows the Modern Lifecycle Policy with no fixed end date, provided configurations stay current, so the update cadence is set by Microsoft and your own change window. openDesk ships major releases once a year in Q3, minor releases monthly and patches on demand, and only the latest minor version is supported. Confirm who tests, approves and rolls back each release, and how many minor versions you can skip.
Major-version upgrade rules
Nextcloud does not allow skipping major releases, so each upgrade moves one major version at a time, with a backup before every step and third-party apps disabled until confirmed compatible. openDesk does not guarantee in-place upgrades between majors. Ask any vendor or integrator for a written upgrade path, test environment and rollback plan before the first production go-live.
Licence terms and enterprise modules
Open-source core licenses such as AGPL-3.0 and MPL-2.0 govern use, but enterprise editions add closed-source modules and SLA-backed support on top. openDesk Enterprise adds Collabora branding, GroupSync and Nextcloud security patches, and Open-Xchange states that some modules may carry separate fees in the license agreement. Get a written list of which features sit under which license before you design the service.
Hardware and database platforms
openDesk's evaluation footprint starts at 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and production expects external PostgreSQL 15, MariaDB 10, Redis 7, object storage and an SMTP relay. Open-Xchange requires Kubernetes with Istio or a basic ingress-nginx option, MariaDB with InnoDB, and a distributed file system. Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18. Check that your hypervisor, database and storage teams can support these versions.
Data export and exit
Microsoft Purview eDiscovery exports mailboxes as PST or .msg files and SharePoint or OneDrive content as native files, but export packages expire 14 days after creation and require an E3 or E5 license. Your own datacenter must still hold backups, mail stores and file storage that you can read without the vendor. Define how mail, files and calendars are exported in open formats, who tests the restore, and where the copies are kept.
What Microsoft 365 Local does and does not hand you
Microsoft 365 Local is a packaged way to run Exchange Server and SharePoint Server on Azure Local, so the server software, its patching and the hardware under it sit in your datacenter while the product sets the software relationship. The decision that matters is who controls each layer after go-live. Microsoft supplies the server products and their update channel, your team or a partner operates the Azure Local cluster, and your organization carries the storage, power, cooling and staffing. Before you compare it with an open-source stack, confirm with Microsoft exactly which components the offer includes, which Exchange and SharePoint versions it covers, and whether licences are per user, per device or per server.
Exchange Server Subscription Edition is where the update relationship changes most. Microsoft released it to general availability on July 1, 2025, and it follows the Modern Lifecycle Policy with no fixed end date as long as your configuration stays current, and Microsoft has said it plans no further year-based major versions. In practice, staying supported means applying cumulative updates on Microsoft's cadence rather than waiting for the next numbered release. Exchange Server 2019 is different: it follows the Fixed Lifecycle Policy, and its extended support ended in October 2025, so any estate still on it is already past the point where a vendor fix is guaranteed. Ask Microsoft to confirm the current update cadence, the minimum cumulative update your configuration must run, and the support end date for any version you plan to keep.
Keep three items on your confirmation list before signing anything: licence terms, supported hardware and update cadence. Ask for the written licence terms that apply to Exchange and SharePoint Server on Azure Local, including what happens to access rights if a subscription lapses. Ask which hardware configurations Microsoft supports for Azure Local and whether the vendor's validated hardware list is a requirement or a recommendation. For updates, get the schedule in writing and the process for testing them in your environment. The open-source side carries its own version of this check: openDesk and Nextcloud each publish release and upgrade rules you can read, so compare the update obligations on both sides, not only the purchase price.
Which open-source option fits which datacenter model
openDesk is a complete digital workplace suite built for public administration and deployed to Kubernetes with Helmfile and Helm charts. It bundles components such as Nextcloud for files, OX App Suite for groupware, Collabora as the web office, Element for chat, and Nubus for identity, so control over updates, data location and hardware stays with the operator. Because the suite is delivered as one unit, the operator owns the whole Kubernetes platform beneath it.
- Update control: ZenDiS plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, and in-place upgrades between majors are not guaranteed.
- Hardware and platform: A CNCF-certified Kubernetes cluster at v1.33 or later is required, along with an ingress controller, cert-manager and an RWO volume provisioner. The project tests on kubespray clusters, not OpenShift.
- Production services: The project expects external PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server.
- Editions: ZenDiS recommends the Enterprise Edition for production. It adds SLA-backed support and patches, with closed-source modules, and is sold as SaaS or for on-premises installation.
- Trade-off: One suite means one upgrade train, so a major release touches every bundled component at once.
Before committing, confirm with the vendor which Enterprise features your compliance evidence depends on, and which lifecycle step applies when you skip minor versions.
Nextcloud with Collabora Online and Open-Xchange is a component-by-component stack, where each workload has its own product, release train and operator-facing configuration. Nextcloud handles files and sharing, Collabora handles Office documents and OX App Suite handles mail and calendars. Each component can be hosted on a Kubernetes cluster or on traditional servers in your datacenter, which gives you more freedom in choosing hardware but more integration work.
- Nextcloud cadence: Nextcloud publishes a new major version every four months and supports each for one year through monthly maintenance releases. Major releases cannot be skipped, so you must upgrade one major at a time.
- OX lifecycle: A standard release is supported for 12 weeks. An LTS release is supported until the next LTS plus six months, and v8.47 is the current LTS at the time of research.
- Infrastructure for OX: OX App Suite v8 is delivered as Helm charts and requires Istio, Redis 7.4.x and MariaDB. Persistent data needs NFS or object storage such as Ceph RadosGW or Scality RING.
- Identity: Nextcloud's LDAP app and its OpenID Connect and SAML backends let you reuse your existing directory.
- Trade-off: You own the integration between three products, including the upgrade order and the backup of each data store.
Ask each vendor to confirm which release train your compliance schedule can absorb, and who on your team holds each upgrade step.
Enterprise subscriptions do not replace the open-source software. They add paid support, maintenance periods and extra features on top of the same core, so the decision is about who answers when something breaks and how long a release stays patched. For regulated organizations, that answer often matters as much as the software itself. Note that subscription terms and features differ between vendors, so treat each tier as a contract to read rather than a default.
- Nextcloud tiers: Nextcloud Enterprise is sold as Standard, Premium and Ultimate, with a 100-user minimum. Standard includes one year of maintenance, Premium adds a lifecycle of five or more years, and Ultimate adds support up to 24/7.
- openDesk Enterprise: SLA-backed second and third level support and patches are included, along with Enterprise-only modules such as the Admin Console and GroupSync.
- OX licensing: The Operations Guide notes that some modules may carry custom packaging or separate fees set in the license agreement.
- Recurring cost: Subscriptions recur every year, while deployment and migration are usually one-time costs.
- What to ask for: Request the support hours, response times, patch scope and the end date of each maintenance period in writing.
Check whether the subscription covers the exact components in your stack, since a support contract for one product does not cover the others.
How to deploy openDesk or Nextcloud and OX in your own datacenter
This sequence takes a datacenter from an empty Kubernetes cluster to a tested productivity stack, with each prerequisite confirmed before the next component is installed. The result is a deployment your own team can operate, update and back up.
Confirm the Kubernetes platform and tooling
Your platform team checks that the cluster is a CNCF-certified Kubernetes distribution at v1.33 or later, and that it has an ingress controller (haproxy-ingress, or the deprecated Ingress nginx), cert-manager and an RWO volume provisioner. Confirm Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later on the deployment host. openDesk is tested on kubespray clusters and not on OpenShift, so ask the vendor to confirm any other distribution in writing. The step is done when a dry run of the chart toolchain runs cleanly against the cluster and every component reports its version.
Size the production services you must provide
For production, openDesk expects you to supply PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV reachable over ICAP, object storage and a TURN server. Your team owns the sizing, high availability, patching and backups of each of these, and the cost of running them recurs every year. Ask the platform vendor and your storage team to confirm capacity for mail, file and chat volumes. The step closes when each service has an owner, a backup target and a documented connection endpoint.
Prepare OX App Suite prerequisites
OX App Suite v8 runs on Kubernetes as Helm charts that reference container images, and requires Helm 3.17.0 or newer. Choose Istio, which the vendor requires for its supported path, or the basic ingress-nginx option where Istio cannot be used, and confirm the choice with Open-Xchange before building the cluster. Provide Redis 7.4.x through the littlered operator or a custom setup, and MariaDB from the supported 10.6.x, 10.11.x, 11.4.x or 11.8.x lines. Persistent OX Drive files and mail attachments need a distributed file system: NFS for small to mid-size deployments, or object storage such as Ceph RadosGW or Scality RING for larger ones. The step is done when the database, cache and file store each accept test connections from the cluster.
Deploy the suite and its identity integration
Install the chosen suite from its Helm charts, using the openDesk deployment repository for openDesk or the Nextcloud and OX charts for the component stack. Connect directory sources early: Nextcloud's LDAP app lets Active Directory users sign in with their directory credentials, and Nextcloud also documents OpenID Connect and SAML backends. openDesk documents federation with an external identity provider. Decide with your identity team which system holds the authoritative user list before any mailbox or file is created. The step is done when a test user can sign in, open mail, edit a document and share a file.
Validate security controls and backups
Confirm malware scanning through ClamAV, TLS certificates issued through cert-manager, and access logs flowing to your monitoring platform. Run a restore test from the backup tooling you chose, because a backup that has never been restored is not evidence of recoverability. For Nextcloud, the All-in-One installation bundles BorgBackup-based backups, and openDesk security documentation describes its controls. Ask your security team to review findings from this validation before users are onboarded. The step closes when a restore has been completed and the results are recorded.
Plan the update and upgrade cadence
Agree the upgrade calendar before go-live, since the upgrade path differs by product. openDesk plans major releases annually in Q3, minor releases monthly and patches on demand, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Nextcloud releases a new major version every four months with one year of support per version, and does not allow skipping major releases, so each upgrade is a stepped sequence with a backup before each one. OX publishes LTS releases and a standard release support window, so confirm which track you will follow. The step is done when a written runbook names the owner, the test environment and the rollback point for each product.
Decide on enterprise support and operations
Decide whether your team will run the platform alone or buy vendor support. openDesk recommends the Enterprise Edition for production and offers SLA-backed second and third level support, sold as SaaS or for on-premises installation. Nextcloud Enterprise is sold in Standard, Premium and Ultimate tiers with a 100-user minimum, and the tiers differ in maintenance length and support hours. OX support terms depend on the license agreement. Ask each vendor for a written quote tied to your user count, support hours and maintenance window, and for the cost of the services in the earlier steps. The step is done when the support model is signed and each operational owner is named.
Questions buyers ask before choosing a self-hosted productivity stack
What drives the cost of self-hosted openDesk or Nextcloud compared with Microsoft 365 Local?
The cost comes from several components, and they are paid to different parties. Microsoft 365 Local is priced through Microsoft licensing plus the Azure Local hardware and operations underneath it. A self-hosted stack adds the hardware or cloud capacity you provision, the Kubernetes platform, storage, backup, email delivery, the open-source software itself (free to download), and the people who install, operate and upgrade it. One-time costs include design, initial deployment, data migration and integration with your identity provider. Recurring costs include hardware refresh, storage growth, staff time for upgrades, monitoring, backups, and any enterprise subscription. Ask every quote to separate these lines and to state which costs depend on user count, storage volume and the number of environments (production, test and disaster recovery).
Can an internal team run openDesk or a Nextcloud stack without outside help?
Some teams can, but it depends on existing Kubernetes, identity and storage skills. openDesk is deployed with Helmfile and Helm onto a CNCF-certified Kubernetes cluster at v1.33 or later, and it needs an ingress controller, cert-manager, an RWO volume provisioner and production services such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. A Nextcloud deployment is smaller in scope but still needs database, caching, backup and upgrade discipline. Nextcloud does not allow skipping major releases, so upgrades must follow a planned sequence with backups first. Assess your team against this list, then decide which parts to keep in-house and which to scope as a fixed-scope engagement or a retainer for upgrades and support.
How long does a migration from Microsoft 365 take, and what drives the timeline?
The duration depends on the workloads, data volume and the number of users, not on a fixed formula. Mailboxes, files, SharePoint or OneDrive content, calendars and chat each move differently, and each needs its own export format, mapping and validation. Timeline drivers include the total data volume, the number of identity and group mappings, how much custom integration exists, whether a pilot group runs first, and how long your change process takes to approve cutovers. Export constraints also matter: Purview eDiscovery search export packages expire 14 days after creation, and exporting requires an E3 or E5 license. Ask any provider for a phased plan with named milestones and acceptance criteria rather than a single overall duration.
Do production deployments require Enterprise subscriptions?
Not always, but production requirements usually push organizations toward a paid tier. The Nextcloud server is licensed under AGPL-3.0 and free to self-host, while Nextcloud GmbH sells Standard, Premium and Ultimate subscriptions with a 100-user minimum, adding support, maintenance periods and extended features. ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules and SLA-backed 2nd and 3rd level support. Open-Xchange states that certain modules may be subject to separate fees in the license agreement. Confirm with each vendor which features and support levels your production obligations require, and price the subscription as a recurring line in your comparison.
Who is responsible for security updates and patching in each option?
In every self-hosted option, your organization or its service partner owns patching, which is a key difference from a cloud service where the provider handles the platform. openDesk releases follow an annual major, monthly minor and on-demand patch cadence, and only the latest minor version is supported. Nextcloud publishes a major every four months and supports each for one year with monthly maintenance releases. OX App Suite LTS releases are supported until the next LTS release plus six months. Enterprise tiers may add signed or enterprise-only security patches, so confirm that detail in writing. Build a patch calendar that covers the operating system, Kubernetes, databases and every application component, and assign an owner for each.
What should a DeployOpen quote include before work starts?
A DeployOpen quote follows from a written scope, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask the quote to list the workloads in scope, such as mail, files, office editing, chat or video, and the number of users and environments. It should name the target platform (openDesk or the Nextcloud stack), the identity integration, the data migration method and the acceptance criteria for each phase. Request an explicit list of what is excluded, such as third-party licenses, Microsoft licensing, hardware and cloud capacity, and ongoing support. Ask whether upgrades, backups, testing and documentation are included, and what a retainer covers after go-live. DeployOpen does not publish a price list, so compare quotes on the written scope.
Does the hardware underneath change which option is cheaper to run?
Yes, the hardware and hosting model affects both one-time and recurring cost, so compare it explicitly. Microsoft 365 Local runs on Azure Local infrastructure that you supply and maintain, while openDesk needs a Kubernetes cluster and production services that you must size. An openDesk evaluation deployment starts at 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and production sizing is far larger and depends on users and workloads, so confirm sizing with the vendor and your own testing. ARM is not supported yet. Ask for a sizing assumption for each user tier, the storage growth rate you planned for, and the cost of a disaster recovery site.
How do I compare the cost of keeping Exchange Server against a move?
Start by confirming the lifecycle of the product you run today, because it sets your timing. Exchange Server 2019 reached the end of its extended support in October 2025, and Microsoft points customers to Exchange Server Subscription Edition or Exchange Online. Exchange Server SE follows the Modern Lifecycle Policy with no fixed end date provided configurations stay current. Compare the costs of staying on a supported Microsoft path, moving to a self-hosted mail platform such as OX App Suite, and the migration effort for each. Include the cost of keeping old servers patched, the eDiscovery and archival needs you must still meet, and the internal time needed to run either path.
Evidence to keep for update, licence and hardware decisions
A decision to run productivity servers in your own datacenter stands or falls on records you can show later. The cards below list the documents that tie an update path, a licence position and a hardware baseline to dates and versions. Independent auditors decide what evidence is sufficient for your obligations.
Product and lifecycle policy record
Keep a dated record of the exact product, edition and lifecycle policy you run, such as Exchange Server SE under the Modern Lifecycle Policy or Exchange Server 2019 under the Fixed Lifecycle Policy. Note the extended support end date for any Fixed Lifecycle product, which Microsoft lists as October 2025 for Exchange Server 2019. For openDesk and Nextcloud, record the release train and the end of support for your version, since a version past its support window stops receiving security fixes. Re-check the record at each renewal decision.
Update and upgrade log
Maintain a log of every patch, minor and major upgrade with the date, the source version, the target version and the person who approved it. Nextcloud does not allow skipping major releases, so the log should show each step in order. openDesk expects in-place upgrades between majors may not be guaranteed, so record any intermediate steps you took. This log is the main proof that your update process ran as designed.
Licence agreements and module entitlements
Store the signed licence or subscription agreement for each commercial component, including the tier, the user count and the support period. For Nextcloud Enterprise, that means the Standard, Premium or Ultimate tier and its 100-user minimum. For OX App Suite, the agreement sets which modules you may use, since some features may carry custom packaging or separate fees. Keep the open-source licence texts that apply to each bundled component, because each component keeps its own licence.
Hardware and database baseline against vendor requirements
Record the CPU, memory, storage and operating system you deployed, and compare each against the vendor requirements page on the date of deployment. Include database versions such as MariaDB or PostgreSQL, PHP, Redis, Kubernetes and Helm. Note where the vendor marks a version as unsupported or tested only on certain platforms, such as openDesk on kubespray clusters and not on OpenShift. Store the requirement page copy you used, because vendor pages change between releases.
Backup and restore test records
Keep dated records of backup jobs and of restore tests into a separate environment, showing which data sets were restored, how long the restore took and whether mail, files and database content matched. Nextcloud recommends a backup before every upgrade, so link each upgrade entry to a backup record. Include the location and encryption of backup copies and who holds the keys. A backup you have never restored is not yet evidence that recovery works.
When to keep Microsoft 365 Local and when to move
Keep Microsoft 365 Local if your organization accepts Microsoft's update cadence and license terms, and if Outlook and Office desktop integration matter more than control over the platform. Those are the workloads where a move costs the most in retraining and client change, and where Microsoft's on-premises stack already fits your existing skills. Move when one of three constraints becomes binding: lifecycle control, licensing terms, or the choice of hardware underneath. Before deciding, confirm with Microsoft exactly which Exchange and SharePoint versions your Local deployment will run, how each update is delivered, and what happens to your licenses at renewal. The Exchange Server Subscription Edition announcement and the Exchange 2019 lifecycle page are the starting references for the Exchange side.
A hybrid path is possible. Many organizations keep Outlook clients and a small number of regulated mailboxes on the Microsoft side while moving file sharing or collaboration workloads to a self-hosted platform. Be careful with the boundary: mail, calendar and document links must still resolve for users on both sides, and identity must come from one directory. Also plan for export. Microsoft Purview eDiscovery can export Exchange mailbox items as PST or .msg files and SharePoint and OneDrive content as native documents, but exporting requires a Microsoft 365 E3 or E5 license, and search export packages expire 14 days after creation. If your exit plan depends on that tooling, confirm your license tier now rather than during a migration window.
Ask for a written statement of responsibilities for every workload you are considering. For each one, record who applies patches, who holds the hardware lifecycle, which licenses recur and which are one-time, and how a rollback would work. If the answers show that the vendor controls the timing of your upgrades, or that a licensing change would force a platform decision, the case for moving is clear. If your main concern is Outlook and Office desktop use, consider a hybrid or a later move instead of an immediate cutover.
How DeployOpen deploys open-source productivity in your datacenter
DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure, so the choice between Microsoft 365 Local and an open-source stack becomes an engineering decision rather than a licensing one. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory mailboxes, file shares, SharePoint sites and retention needs before choosing between openDesk and Nextcloud with Open-Xchange.
- Confirm the Kubernetes platform, storage backend, identity source and SMTP relay the datacenter can supply.
- Record in the written scope which workloads move, which stay, and who approves update windows.
How we build
- Deploy the chosen stack to the client's own Kubernetes cluster, following the vendor's Helm and Helmfile or Helm chart guidance.
- Connect the directory, certificates, mail relay, antivirus scanning and object storage the deployment expects for production.
- Test sign-in, mail flow, document editing and restore procedures against the agreed scope before go-live.
How we hand over
- Document the architecture, configuration, upgrade path and runbooks so the client's own staff can operate the platform.
- Deliver backup and restore evidence along with the controls and records needed for compliance readiness reviews.
- Explain which decisions remain with the client, including licensing for enterprise editions and the choice of an independent auditor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
- Plan major version upgrades one step at a time, with backups and third-party app checks before each change.
- Ask any quote to state which open-source editions, enterprise subscriptions and hardware assumptions it includes.

