Open-Xchange vs SOGo

OX App Suite v8 is designed to run on a Kubernetes cluster and is delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. The support policy shapes who must own the platform: OX App Suite v8 supports Kubernetes versions N-1 and N-2, and it requires Istio, supporting the latest Istio release plus two prior versions, unless you use the basic ingress-nginx option where Istio cannot be used. Your team therefore needs someone who can plan Kubernetes and Istio upgrades on a schedule that matches the vendor matrix, and who can test those upgrades in staging before production. Confirm with Open-Xchange which Kubernetes and Istio versions match the release you plan to run, and confirm whether your platform team already operates Istio or would be adding a new mesh to its workload.

Storage is the other place where the footprint changes. OX Drive files and PIM attachments must sit on a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Redis 7.4.x (deployed by default through the littlered operator) and MariaDB with InnoDB, which supports Galera Cluster, add further stateful services that someone must back up, restore and patch. SOGo takes a different path. It runs on your existing IMAP and SMTP servers, so most of the day-to-day operating burden sits with the mail layer: Dovecot or your chosen IMAP server, the SMTP relay, mailbox storage and quotas. If your mail team already runs those well, SOGo adds a web and sync front end rather than a new storage tier. If it does not, the work of running mail will not change with SOGo.

Before you decide, confirm three things in your own environment. First, whether you can staff Kubernetes, Istio, Redis and a clustered database as ongoing responsibilities, or whether a partner will carry them under a written retainer. Second, which distributed file system you already operate and whether its capacity, performance and backup model suit mailbox-scale attachments. Third, the lifecycle of your current mail stack, including who owns its upgrades and how its IMAP and SMTP components are tested. Ask Open-Xchange and any implementation partner to describe, in writing, who performs each upgrade, how long a standard release stays supported under the support commitment, and what happens to your data during a rolling change. These answers determine whether the operating model fits your team.

The largest cost difference between these two options is who is paid for what. OX App Suite v8 is delivered as Helm charts for a Kubernetes cluster, so the bill includes the cluster itself, an Istio service mesh or a basic ingress-nginx option, Redis 7.4.x, MariaDB, and a distributed file system for OX Drive files and PIM attachments. SOGo is a groupware layer that sits on IMAP and SMTP servers you already run, so its direct cost is mainly the host it runs on, the mail stack beneath it and the people who maintain both. Separate the one-time items (design, migration, hardening, integration with identity) from the recurring ones (infrastructure, support contracts, upgrades and staff time). Ask whether any OX App Suite module or feature is licensed separately, because the Operations Guide says certain modules may carry custom packaging, limitations or separate fees set in the license agreement.

Upgrade cadence drives recurring effort more than most buyers expect. Open-Xchange states that a standard release is supported for 12 weeks, ending with the availability of the third following release, and that an LTS release is supported until the next LTS plus six months. Plan for an upgrade rhythm that matches the release you choose, and ask the vendor which release line your quote covers and what it costs to stay on a supported one. SOGo's release history is shorter in the sources supplied, and its current release is 5.12.12. Ask Alinto or your support provider what support window applies to the version you deploy, and whether premium support from Alinto is priced per year or per incident. Factor the internal time for testing each upgrade against your mail, calendar and ActiveSync clients, since those changes touch every user.

Skills and support commitments are where quotes often diverge. Running OX App Suite at scale calls for people who can operate Kubernetes, Helm, Istio, Redis, MariaDB and object or NFS storage, so ask whether the quote includes operating those layers or only deploying them. SOGo needs staff who understand the underlying IMAP, SMTP, CalDAV and CardDAV servers and the Outlook CalDav Synchronizer path, which may already exist in your team. Ask for a written scope listing the components, the environments (test, staging, production), the backup and restore procedures, the identity integration method, support hours and response expectations, and what is excluded. Ask for the price of ongoing support as a separate line item from implementation, and confirm which costs you pay directly to a vendor and which go through a partner. DeployOpen quotes follow from the written scope, so the more precisely that scope names the components above, the more comparable the quotes will be.

The most common overrun on an OX App Suite v8 project is the platform foundation, not the mail flows. OX App Suite v8 is designed to run on a Kubernetes cluster and is delivered as Helm charts, and the requirements call for Helm 3.17.0 or newer. Its support rules tie the cluster to Kubernetes versions N-1 and N-2 and to Istio, with the latest Istio release plus two prior versions supported, and a basic ingress-nginx option exists only where Istio cannot be used. Before work starts, confirm whether your platform team already runs a cluster that meets these rules, who owns Istio upgrades, and whether a service mesh is acceptable in your security architecture. If any of those answers is no, the readiness work lands in the project plan as its own deliverable, and it should be written into the fixed scope rather than discovered in week one.

Storage sizing and identity integration are the next two places where timelines slip. Persistent data such as OX Drive files and PIM attachments must sit on a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Ask for the expected attachment volume, growth rate and retention before choosing the backend, because migrating file storage later is expensive. On the identity side, OX App Suite supports OpenID Connect and SAML, but your directory, MFA policy and group mapping decide how long the login path takes to validate. SOGo, by contrast, sits on your existing IMAP and SMTP servers, so its identity path is usually shorter, but it still needs the same directory decisions. Put the identity provider, the claims or attributes used for authorization, and the test accounts into the written scope.

Client changes are the overrun users notice most. ActiveSync device re-enrollment, Outlook client profile changes and mailbox migration windows all depend on how many devices and users you have, not on the platform alone. Each phone or tablet that must be re-enrolled, and each Outlook profile that must change, adds support work and user communication. Plan the migration in waves, confirm the cutover window with the business owners of each group, and agree in writing who performs client reconfiguration and who handles failed syncs. Because most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts, the reader should ask for these items to be listed explicitly: cluster readiness, storage backend, identity integration, device and client count, and the migration waves. Anything not listed is a change request, so the more precisely these are written, the fewer surprises appear later.