Exchange Server vs OX App Suite: when each option fits
If your renewal, licensing change or data residency rule forces a decision on on-premises mail, Exchange Server Subscription Edition fits organizations that run Windows Server, depend on Outlook and Exchange-specific features, and want to keep their current administration skills. OX App Suite fits organizations that want a self-hosted groupware stack covering mail, calendar, documents and drive, can operate Kubernetes, and are prepared to change clients and workflows. The decision turns on four factors: the client mix your users depend on, whether your team is stronger on Windows or Kubernetes, the licensing budget you can commit to, and how much groupware beyond mail you want to consolidate.
Start with the client mix. Exchange Server SE serves Outlook for Windows, Outlook for Mac and mobile clients natively through its own protocols, so users notice little change. OX App Suite offers its own web interface and clients connect over standard protocols, and the Exchange-facing options, including the ActiveSync connector, need to be tested against your actual Outlook and mobile profiles before you commit. Next, compare platform skills. Exchange runs on Windows Server with Active Directory integration, while OX App Suite v8 is delivered as Helm charts that require Helm 3.17.0 or newer, Istio or a basic ingress-nginx option, Redis 7.4.x, and MariaDB with a supported 10.6.x, 10.11.x, 11.4.x or 11.8.x release. Confirm with your platform team whether they can run that stack, and whether storage will be NFS or object storage such as S3-compatible systems.
Then price the decision on paper. Exchange licensing now centers on subscription or Software Assurance for servers and client access licenses, so ask your Microsoft partner for the quote for your user count and hosting plan. For OX App Suite, ask Open-Xchange and your implementation partner to separate the support subscription, any module fees described in the license agreement, storage, Kubernetes infrastructure and migration work, and to state which costs recur each year. Finally, decide how much you want beyond mail. If shared documents and drive are a priority, check whether a separate file platform such as Nextcloud is a better fit, because OX App Suite's drive and document features cover a narrower range than a full file platform.
Which option fits which organization
This table matches common organizational situations to the platform that usually fits best, and states the condition under which each advantage matters. Read each row against your own client mix, platform skills and regulatory position before deciding.
| Scenario | Better fit and why | Condition under which the advantage matters |
|---|---|---|
| Outlook-dependent Windows shop | Exchange Server SE keeps native MAPI, Outlook, delegate and shared calendar behavior unchanged, because Outlook is built around the Exchange server. OX App Suite relies on its own clients, an Exchange ActiveSync connector and IMAP with CalDAV, so Outlook users may see gaps. | Choose Exchange Server SE if Outlook features such as delegates, shared mailboxes and room booking are critical and must work identically. Confirm each feature with OX before committing. |
| Kubernetes-capable platform team | OX App Suite v8 is delivered as Helm charts and needs a Kubernetes cluster, Istio or ingress-nginx, Redis, MariaDB and a distributed file system. This suits teams that already run and patch clusters. | Choose OX App Suite if your team already operates Kubernetes, storage and database platforms with clear ownership for upgrades and backups. Without that skill set, the platform work becomes the main cost. |
| Windows Server estate with no Kubernetes skills | Exchange Server SE runs on Windows Server, which most Windows administrators already know how to patch, back up and monitor. Ongoing work stays within a familiar operating model. | Choose Exchange Server SE if the license terms are acceptable to finance and your current Windows Server processes are working. Review the subscription licensing terms with Microsoft before renewal. |
| Air-gapped or sovereignty-driven public sector | OX App Suite can be deployed in a private datacenter or air-gapped network, and openDesk is an alternative public sector suite built on it. Mail, files and identity remain under the organization's own control. | Choose OX App Suite when data residency, procurement policy or sovereignty rules require open-source software that runs entirely in your own environment. Confirm the air-gapped delivery model and update process in writing. |
| Organization already using Nextcloud or openDesk | OX App Suite fits alongside Nextcloud for files and openDesk for a full suite, so mail and files can be planned as one change instead of separate projects. | Choose OX App Suite when files, chat or video are moving to the same open-source stack in the same period, and identity integration is planned from the start. |
| Mixed-client organization with Outlook, mobile and web users | Exchange Server SE serves Outlook, mobile and web users from one server. OX App Suite serves its web client well but needs connector or IMAP-based access for Outlook and some mobile clients. | Choose OX App Suite if most users work in the web client and a small group needs Outlook, and that group can accept the connector behavior after testing. Test each client group before cutover. |
| Organizations facing a subscription licensing decision | Exchange Server SE requires subscription or Software Assurance licensing for servers and client access licenses. OX App Suite is licensed through Open-Xchange, with support subscriptions and possible module fees set in the license agreement. | Choose OX App Suite if the total licensing and upgrade model in your quote is lower than the Exchange subscription over your planning horizon. Ask for the module list and any fees in writing. |
What running OX App Suite on Kubernetes asks of your team
Running OX App Suite v8 means operating a Kubernetes cluster as the foundation, with the platform delivered as Helm charts that reference container images. Helm 3.17.0 or newer is required, and Kubernetes support covers the N-1 and N-2 versions, so your platform team needs an upgrade rhythm that keeps the cluster inside that window. Open-Xchange expects Istio for service mesh, supporting its latest release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option exists, but you should confirm with Open-Xchange what that option gives up before you commit to it. Redis 7.4.x handles caching and session storage, deployed by default through the littlered operator, and MariaDB with InnoDB is the primary data store on versions 10.6.x, 10.11.x, 11.4.x or 11.8.x, with Galera Cluster supported.
Storage is the decision that most changes the footprint. OX Drive files and PIM attachments must sit on a distributed file system: NFS suits small to mid-size deployments, while object storage such as AWS S3, Ceph RadosGW or Scality RING fits larger ones. Choose the storage tier with your mail volume and attachment growth in mind, and ask Open-Xchange to confirm where the threshold between NFS and object storage falls for your user count. Sizing for the cluster, database, Redis and storage should come from Open-Xchange's written guidance and your own load tests, not from this page.
The skills shift is the part many Exchange teams underestimate. Exchange administration centers on Windows Server, Active Directory, Exchange Management Shell and Outlook client policy. OX App Suite moves that work to Linux hosts, container orchestration, Helm releases, service mesh certificates, MariaDB replication and object storage administration. Identify who will own each layer before cutover, decide whether to build that capability in-house or contract it, and confirm with Open-Xchange which operational tasks are covered by support. Keep the OX App Suite requirements open during planning, because the exact versions change with each release.
Where mail data lives and who controls it
Mail, calendars and attachments are among the most sensitive records an organization holds, so where they are stored and who can reach them usually decides the platform. This section sets out the control points that differ between on-premises Exchange Server and a self-hosted OX App Suite deployment, and what to confirm before you commit.
Data location and hosting models
Exchange Server SE runs on Windows Server inside your datacenter, while OX App Suite can run on premises, in a public cloud you choose, or as the managed OX Cloud service. Each option places mailboxes, Drive files and attachments in a different jurisdiction and operator boundary. Ask Open-Xchange which hosting models your contract covers, where backups and support access are located, and whether any managed option changes the data processor. Confirm the hosting model in writing before the design review.
Identity integration with OIDC and SAML
Who signs in matters as much as where data sits. OX App Suite supports OpenID Connect and SAML for single sign-on, so authentication can stay with your existing identity provider rather than a local directory. Check how mailbox provisioning, deprovisioning and group-based access will be driven from that provider, and how privileged administrator accounts are protected. Exchange Server depends on Active Directory, so the migration plan must map those dependencies explicitly.
eDiscovery and legal hold tooling
Exchange Server customers often rely on Microsoft Purview eDiscovery, which can export mailbox items as PST or .msg files and requires a Microsoft 365 E3 or E5 license. Purview is a cloud service, so it does not replace an on-premises legal hold workflow by itself. With OX App Suite, legal hold, search and export must be designed and tested as part of your own platform. Confirm which retention and hold features your deployment includes and who operates them.
Audit evidence and control records
Regulated organizations need evidence that access, changes and retention settings are controlled and logged. Logging, configuration baselines and change records have to be collected from the Kubernetes cluster, the mail stack and the identity provider, not from a single admin console. DeployOpen can prepare systems, controls and evidence for a compliance assessment, but it does not issue audit reports or attestations. Independent auditors and certification bodies make that determination.
Air-gapped and restricted operation
Some organizations must run mail with no route to the internet. Exchange Server can operate on premises, but licensing and activation steps must be planned around it. OX App Suite is documented as deployable in your own infrastructure, which makes air-gapped operation a design question: container image mirroring, Helm chart delivery, relay configuration and update media. Ask Open-Xchange how packages and security updates reach an isolated network before you rely on that model.
Module licensing and feature rights
Some OX App Suite modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Before you map features to users, get the modules and rights your organization needs listed in the contract. Compare this with Exchange Server SE licensing for servers and every client access license, so that the data control gained is not undone by an unexpected feature restriction later.
How licensing differs between Exchange SE and OX App Suite
The first decision is what you are actually buying. Exchange Server Subscription Edition (SE) is licensed per server and per client access license (CAL), and it is sold through Microsoft's subscription or Software Assurance channels rather than as a one-time purchase. Those licenses recur, so the cost of keeping mail on premises grows with the number of users and servers, not just with the first installation. Ask your Microsoft partner or licensing advisor to state in writing which SKUs cover the Exchange servers, every CAL type your users need, and whether any Windows Server or SQL-related licensing is required alongside them. Confirm also how Software Assurance or subscription renewals interact with your current agreement.
OX App Suite is a different arrangement. Open-Xchange publishes mirrors of the App Suite UI (appsuite-frontend) and middleware (appsuite-middleware) on GitHub under the AGPL-3.0 license, so the core code can be read and inspected. The Operations Guide, however, states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Support is a separate commitment, with a standard release supported for 12 weeks and LTS releases supported until the next LTS plus six months. Request in writing an itemized list of the modules in your quote, any feature fees, the support tier and the LTS versions it covers, and whether the AGPL terms apply to every component you will run.
Cost components on each side and what drives them
Exchange Server and OX App Suite split costs differently: one is mostly licensing and Windows Server, the other is mostly Kubernetes, storage and operations staff. Each card below names a cost component, whether it is one-time or recurring, and what moves it, so you can compare line-item quotes rather than headline totals.
Exchange Server licensing and CALs
Exchange Server SE is licensed per server with client access licenses for each user, and the terms you hold determine what you pay each year. Confirm with Microsoft or your reseller whether your agreement is subscription or Software Assurance based, and whether the CAL count tracks named users, devices or both. Recurring licensing grows with headcount, so the user count in your quote is the first number to verify.
Windows Server hosts and OS licensing
Exchange Server runs on Windows Server, so each mail host carries an operating system license, its patch cadence and its own backup and monitoring. Ask whether the quote includes Windows Server datacenter or standard licensing for each node and for any standby or DR servers. Recurring OS costs and host count rise with redundancy requirements, which is often the largest hidden line on the Exchange side.
Kubernetes infrastructure and Istio
OX App Suite v8 is delivered as Helm charts on a Kubernetes cluster, and it requires Istio or a basic ingress-nginx option where Istio cannot be used. Infrastructure is recurring, whether you rent cloud nodes or run hardware in your own datacenter. Costs rise with node count, high availability needs and the Kubernetes versions you must keep within the supported window, so ask the integrator to price the cluster and service mesh separately.
Storage for mail and files
Mailbox data, OX Drive files and PIM attachments grow over time, and OX App Suite needs a distributed file system such as NFS for small to mid-size deployments or object storage such as Ceph RadosGW or Scality RING for larger ones. Storage is recurring and driven by mailbox size, attachment volume and retention rules. Ask for capacity growth assumptions in writing and the cost of replication or backup for each storage tier.
Support subscriptions and LTS cadence
Open-Xchange supports a standard release for 12 weeks, while an LTS release is supported until the next LTS plus six months, so the release you pick sets how often you must upgrade. Exchange Server SE follows a Modern Lifecycle Policy with no fixed end date, but its configurations must stay current. Ask both vendors what support tier, response times and patch delivery your quote includes, and whether upgrades are billed as recurring work or as projects.
Staff time and migration services
Staff time for operations, upgrades and Kubernetes or Windows patching recurs every year, while migration services such as mailbox export, directory integration, client rollout and coexistence testing are one-time. Costs rise with the number of mailboxes, the complexity of your Active Directory or identity setup and the number of client types you must support. Ask for migration work as a separately priced, fixed-scope item with the deliverables listed, and ask who is responsible for each upgrade cycle.
What a move from Exchange to OX App Suite involves
The sequence moves mail, calendars, contacts and archives from Exchange into a self-hosted OX App Suite platform in a controlled order, so each stage ends with a verified result before the next begins. Each step names what is produced and how the team knows it is complete.
Inventory mailboxes, calendars, contacts and archives
Start by listing every mailbox, including shared mailboxes, room and equipment resources, delegates, distribution lists, public folders and in-place or local archives. Record item counts, total size and any mailboxes under legal hold or retention policy. Your Exchange administrators and the records or legal owners should sign off on the list, because it defines the scope of export and the retention obligations that follow. The output is an approved inventory and a list of exceptions that need a decision before migration starts.
Build and size the OX App Suite platform
Your platform engineers build the Kubernetes environment that OX App Suite v8 requires, with Helm 3.17.0 or newer, Istio or the basic ingress-nginx option, Redis 7.4.x, a supported MariaDB version with InnoDB, and a distributed file system for OX Drive files and PIM attachments. Sizing depends on the inventory from the first step, so confirm storage type, growth and backup targets with Open-Xchange and your own environment before procurement. The output is a tested cluster with working authentication, backups and restore verified in a non-production environment.
Connect identity and directory services
Decide how users sign in to OX App Suite before data moves. Options include OpenID Connect and SAML, which Open-Xchange documents, and they must match your directory design. Map Exchange mail addresses, aliases and distribution groups to the new platform so that user identifiers do not change during cutover. Your identity team and the application owners should test sign-in with a pilot group. The output is a documented identity design and a pilot group that signs in without manual workarounds.
Export and sync mail, calendars and contacts
Move the data with a method that covers all three data types. IMAP alone transfers mail but leaves calendars and contacts behind, so plan a separate route for those, such as calendar and contact exports or a supported sync connector, and confirm it with Open-Xchange. Run a pilot mailbox first, then the bulk load in waves, and compare item counts and folder structure against the inventory. Your migration engineers own the runs, and the output is a reconciliation report per mailbox showing matched counts and listed exceptions. The sibling migration guide covers the export and sync options in detail.
Roll out clients, including Outlook options
Decide which clients users will run before cutover. Options include the OX App Suite web interface and mobile access, IMAP and CalDAV clients, and Outlook through an Exchange ActiveSync connector if your licensing and testing support it. Test shared calendars, delegate access, free and busy lookups and out-of-office messages, because these features often behave differently after migration. Give users written guidance and a support path. The output is a client matrix signed off by the business, with the Outlook behavior tested against real shared mailboxes.
Run coexistence and cut over mail flow
Plan a period when both systems run, so that mail routing, free and busy and address lookups keep working for users who have not moved yet. Change MX records, connectors and smart hosts only after the pilot and the first waves pass reconciliation. Keep a documented rollback path to Exchange until the cutover is accepted. Your messaging and network teams run the change under an agreed change window. The output is confirmed inbound and outbound mail flow to the new platform and a closed rollback window.
Decommission Exchange and set retention
Once users have moved and the rollback window has closed, archive the final Exchange data that retention or legal hold rules require, using formats your records team approves, such as PST or other exports that your eDiscovery tools can read. Confirm that retention policies are configured on OX App Suite, then remove Exchange servers, licenses and service accounts in a documented order. Keep the decommissioning records with the inventory. The output is a signed record that Exchange has been retired, the archive location is known, and retention rules are active on the new platform.
Questions buyers ask before choosing
What drives the total cost of Exchange Server versus OX App Suite?
Total cost depends on components, not a single license line. On the Exchange side, the main items are Windows Server hosts, the server and client access licensing your agreement requires, and any extended support or upgrade work on older versions. On the OX side, the main items are Kubernetes infrastructure, distributed storage for mailbox and drive data, MariaDB and Redis operations, the Open-Xchange support subscription, and the migration itself. Ask any vendor or partner for a quote that itemizes these components, separates one-time costs from recurring ones, and states which modules or features fall under separate license terms. Open-Xchange's Operations Guide notes that certain modules may carry custom packaging or separate fees, so confirm those in writing.
How long does a migration from Exchange to OX App Suite take?
No fixed duration can be stated from the supplied facts, so treat any timeline as a function of your environment. The main drivers are mailbox count and total data volume, the number of calendars, shared mailboxes and delegates that need careful mapping, how much archive and compliance data must move, the state of your identity directory, and how many client types must keep working during coexistence. Storage choice also matters, because OX requires a distributed file system such as NFS or object storage for drive files and attachments. Ask for a written scope with phases, a pilot group, rollback steps and acceptance criteria before agreeing to a date.
What does our internal team need to provide during the project?
Your team typically provides the decisions and access that only your organization can give. That includes the target infrastructure and cloud or datacenter accounts, Kubernetes platform ownership, storage capacity, DNS and mail-flow changes, certificates, the identity source for login, and named owners for mailbox migration waves and user communication. Legal or compliance staff should confirm retention and eDiscovery requirements, since Exchange tools such as Microsoft Purview export capabilities do not map directly to OX. Ask any implementation partner to list these dependencies in the written scope so that gaps are visible before work starts.
Can our own staff run OX App Suite after it is deployed?
Yes, but only if you have Kubernetes, database and storage skills in-house or under a support arrangement. OX App Suite v8 is delivered as Helm charts, requires Helm 3.17.0 or newer, expects Istio or a basic ingress-nginx option, and uses MariaDB, Redis 7.4.x and a distributed file system. Routine work includes database backups, certificate renewal, Kubernetes upgrades within the supported N-1 and N-2 window, and applying OX releases. Decide early whether your staff will own these tasks, whether an implementation partner will provide ongoing support as a retainer, or whether a mix of both suits your team.
Will Outlook keep working after we move to OX App Suite?
Outlook compatibility is the question most likely to change the plan, so test it before committing. OX App Suite's Exchange ActiveSync connector and IMAP with CalDAV cover many mobile and desktop scenarios, but shared calendars, delegate permissions and full native Outlook behavior need validation with your actual mailbox types and client versions. Ask for a documented test matrix covering Outlook versions, mobile devices, free-busy lookup, room booking and shared mailboxes. If native MAPI behavior is a hard requirement, compare this page with the grommunio and Exchange-alternative options before choosing.
How do upgrades and LTS timing affect day-to-day operations?
Upgrade timing is governed by Open-Xchange's support commitment. A standard release is supported for 12 weeks, ending with the availability of the third following release, so standard releases require regular upgrades. An LTS release is supported until the next LTS release plus six months. The current LTS named in the supplied facts is v8.47 (FCS 2026-03-18), and v8.35 is discontinued, so confirm which release you are deploying and plan a recurring upgrade window. Also budget for Kubernetes, Istio, MariaDB and Redis version compatibility checks with each release, since these components change independently.
How do air-gapped or sovereign deployments differ from a standard install?
Air-gapped and sovereign deployments change the delivery and maintenance model more than the core product. Container images, Helm charts, operating system packages and vulnerability feeds must be mirrored into your disconnected environment through an approved transfer process. Mail relay, antivirus signature updates, certificate authorities and license activation all need a plan that works without internet access. Sovereignty requirements also shape where storage, backups and support access sit, and who can reach the system. Confirm with your security and compliance teams which controls and evidence your auditors expect, and remember that DeployOpen prepares systems and evidence for assessments, while independent auditors issue any audit report.
What to test before committing
Start with a pilot on the real Outlook build your users run, not a test client. Outlook behavior depends on the build, and OX App Suite's Exchange connector and IMAP with CalDAV are different paths with different limits. Confirm with Open-Xchange which Outlook versions and protocols are supported, then test shared calendars, free/busy lookups, delegate access, send-on-behalf and meeting responses with a pilot group that includes delegates and executive assistants. Test mobile sync on the device models in your fleet as well, because ActiveSync coverage and push behavior are the checks most likely to differ from what your users have now. Do not assume parity for any of these. Ask for written confirmation and run the test on your own tenant data.
Next, test the compliance and data-handling needs that a mail move tends to break. Export a sample of mailboxes and confirm that retention, legal hold and litigation search requirements can be met in the new environment. Microsoft Purview eDiscovery exports mailbox items as PST or .msg files, and an OX-based deployment will need its own export, archive and search process, which you must define and test. Decide where the storage backend sits: OX App Suite requires a distributed file system for persistent data such as PIM attachments, using NFS for small to mid-size deployments or object storage such as Ceph RadosGW or Scality RING for larger ones. Have your storage and backup teams size and restore-test that backend during the pilot, not after go-live.
Finally, check the operating side. OX App Suite v8 runs on Kubernetes with Helm charts, requires Istio or a basic ingress-nginx option, and uses MariaDB and Redis, so confirm that your platform team has the Kubernetes and database skills to run it, or price in the people or partner support needed. Ask Open-Xchange for a written support commitment that covers which release you will run, how long each release is supported under its support commitment, and which LTS line applies, since a standard release has a short support window. Also confirm in writing any module or feature that may carry separate fees under the license agreement. Treat the answers as the basis for your go or no-go decision.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen plans, implements and supports self-hosted open-source platforms inside your own infrastructure, so mail stays in your datacenter or cloud account. We start with a written scope that tests the Exchange Server vs OX App Suite decision against your actual licensing, platform and client requirements before any build work begins.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- We inventory mailboxes, shared calendars, delegates, Outlook clients and mobile devices in use today.
- The written scope records which Exchange features must map to OX App Suite and which need a documented gap decision.
How we build
- We plan the OX App Suite v8 target on Kubernetes with Helm, Istio or the basic ingress-nginx option, and the storage layout.
- We size and configure the MariaDB, Redis and distributed file storage that OX App Suite requires in your environment.
- We integrate identity through OpenID Connect or SAML, then test mail flow, calendars and client connections before cutover.
How we hand over
- You receive documentation of the deployed architecture, configuration, backup procedures and operational runbooks.
- We prepare the controls and evidence that your internal or independent assessors may need for compliance reviews.
- Handover covers how to track OX support commitment dates and plan upgrades between standard and LTS releases.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should be agreed in writing, including who performs upgrades and how security patches are tested.
- Ask us to confirm licensing terms for any OX module or feature in your quote before the build begins.
