Open-Xchange upgrades and support

The first decision is which release path your OX App Suite v8 platform will follow, because the path sets how often you upgrade and how long a version keeps receiving support. Standard releases arrive on a four-weekly cadence. Open-Xchange supports each standard release for 12 weeks, and that window ends with the availability of the third following release. A team on standard releases has to move forward almost continuously or it falls outside support. This path suits teams that want new features and fixes quickly and have the staff to test them often. It also means every change to Helm values, custom plugins or middleware configuration is retested several times a year.

The LTS line works differently. An LTS release is supported until the next LTS release plus six months, which gives a longer period between mandatory moves. Open-Xchange named v8.35 (FCS 2025-03-12) as the first v8 LTS, and that release is now discontinued, so any platform still running it needs a planned move. The current LTS is v8.47 (FCS 2026-03-18). Fewer upgrades reduce the testing load on your change board, but new features reach you later, and the LTS line still requires a move when the next LTS supersedes the current one. Ask Open-Xchange when the successor LTS is expected, because your support window depends on that date.

The support commitment also lists v8.53 as the newest release, with first customer shipment on 2026-09-23. Treat that date as a planning reference only, since a first shipment date does not show how your custom work, Kubernetes version or Istio version will behave on that release. Weigh three factors before choosing. Feature cadence matters if your users depend on new functions. The size of your custom work matters because each white-label change, UI plugin or Helm override must be retested on every move. The capacity of your change board matters because a standard path only works if production approvals can happen inside the support window.

Before you decide, run a short check. List every custom component and its owner, record the Kubernetes and Istio versions your cluster runs, and note the date your change board can next approve a production change. Then confirm the current release status, the release you are running and the LTS successor with Open-Xchange in writing, since the support commitment is the reference for dates. Document the chosen path and the date by which you must leave your current release, and set a reminder well before that date so the move is not forced by an expired window.

Every Open-Xchange App Suite v8 upgrade should pass the same test sequence in a staging environment before it touches production. The sequence starts by pinning the Helm client to version 3.17.0 or newer, which the OX App Suite requirements name as the minimum for v8 charts. Pinning the client version in your pipeline and in the runbook means the render you test is the render you deploy, and it removes one common source of drift between the engineer who ran the test and the engineer who ran the rollout.

Next, compare the chart and values between the current and target releases before anything is deployed. Render both releases with your production values and diff the output, not only the values files, so you see changed templates, image references, resource requests, probes and any new or removed Kubernetes objects. Review the diff against the Istio and Kubernetes support statements in the requirements for the target release. Any change to Redis deployment mode, MariaDB connection settings or storage mounts should be treated as a design decision with an owner, not as routine chart noise.

Rebuild staging from production-like values and restore a recent database and file-storage snapshot. The MariaDB data and the distributed file or object storage holding OX Drive files and PIM attachments must come from the same point in time, or the test will not show whether links between mail, calendar and file records still resolve after the upgrade. Confirm the snapshot age and retention with your backup owner, and record the restore duration so the production window can be planned from measured data.

Run functional checks after the upgrade in staging. At minimum, test mail send and receive, calendar create and invite, contact create and sync, Drive upload, share and download, and Documents open and save. Add a single sign-on login through your configured OpenID Connect or SAML flow, and confirm session behavior matches your policy. Keep the test accounts and expected results in a written script so two engineers produce comparable evidence.

Finish with a rollback drill. Roll the staging release back to the previous chart version, confirm the platform serves the same checks, and note any database migration that cannot be reversed by a Helm rollback. Ask Open-Xchange and your database team to confirm which target-release migrations are one-way. Also confirm the upgrade order and any migration steps for the target release in the vendor documentation, because these can change between releases and the chart diff alone will not show them.

For change approval, keep a short evidence pack for each rollout: the Helm version used, the rendered diff with reviewer sign-off, the snapshot identifiers and restore logs, the functional test script with results, the SSO test record, the rollback drill outcome and the list of confirmed migration steps. Store it with the change ticket so auditors and internal reviewers can trace each production change to a tested build.

Before any upgrade or support work starts, the team responsible for the Open-Xchange platform needs to give the engagement read access to the running cluster and to the Helm releases deployed into it. Without the live release state, nobody can confirm which OX App Suite chart version and container images are running, which values files were applied, or whether anyone has changed resources by hand. We also need the current values files for each environment and a record of every custom patch, middleware override or UI plugin layered on top of the stock charts. Ask your platform team to export these now, including the Helm 3 release history, so the first review works from facts rather than memory. Data access is the second group. Confirm how database backups for MariaDB and the Redis layer are taken, where they are stored, and who can restore them. Storage for OX Drive files and PIM attachments on the distributed file system or object store needs a matching backup or snapshot policy that is tested, not assumed. The engagement also needs a staging environment that can match production in Kubernetes version, Istio version, Redis and MariaDB versions, and storage layout. If staging differs in any of these, test results will not predict production behavior, so list the differences in writing before the first rehearsal. Three people or roles must be named early. The first is a change approver with authority to accept or stop each rollout. The second is the owner of the maintenance window policy, which sets when rollouts may happen, how long a window can run, and who is notified. The third is the rollback owner, the person who decides to reverse a release and who has the access to do it. Name the support contact at Open-Xchange who will receive escalations under your support arrangement. Confirm the release path you intend to follow, either the four-weekly standard releases or the yearly LTS line, because that choice sets the cadence of every later decision. Check the Open-Xchange support commitment for the support window that applies to your chosen line before you commit to a calendar. Finally, build an inventory of integrations that the upgrade can affect. This covers single sign-on through OpenID Connect or SAML, directory connections used for provisioning, and mail gateways that deliver to or receive from the platform. For each integration, record the endpoint, the certificate or secret owner, and the test that proves it still works after a change. Integrations are the most common reason a chart upgrade passes in staging and still fails in production, so this inventory should be complete before the first test cycle begins.