OX App Suite 7 to 8 upgrade

Target an LTS line, not the newest release. Open-Xchange's support commitment decides how long a version keeps receiving fixes, and that window sets how long your migrated v8 environment can run before you must upgrade again. A standard release is supported for 12 weeks, ending when the third following release becomes available. For an environment that will hold mail, calendar and contacts for years, that window is too short to build a migration around. An LTS release is supported until the next LTS release plus six months, so it gives your team a longer period to finish cutover, stabilize operations and plan the next move.

The published LTS lines are easy to misread, so name each one before you choose. v8.35, first released on 2025-03-12, was the first v8 LTS. It is now discontinued and should not be a target for a new deployment. v8.47, first released on 2026-03-18, is the current LTS and is the usual starting candidate. v8.53 is the newest release listed in the commitment, with first customer shipment on 2026-09-23. A newer version number does not automatically mean a better target. Check whether it is an LTS or a standard release before you put it in the migration plan.

Choose by support end date. For each candidate, read the published end of support in the commitment and calculate how many months remain after your planned cutover and your first post-cutover review. Because an LTS ends six months after the next LTS, the end date of your chosen line depends on when the following LTS ships. Ask Open-Xchange to confirm the end date for the current LTS, the expected next LTS and any custom support terms in your contract. Record the answers in the migration decision log so the reason for the target is clear to auditors and to the operations team that inherits the platform.

Then check whether the target has shipped before your cutover window. A release can be listed in the commitment and still reach customers later, so compare the first customer shipment date with the date your change window opens. v8.53 has a first customer shipment of 2026-09-23. If your cutover falls before that date, that release is not an option for production, and you should plan on the current LTS or another release that is already shipping. Also confirm that the Helm chart version and container images you pin in your deployment repository match the release you select, and keep a documented fallback target in case shipment dates move.

The cutover model decides how long App Suite 7.10 on VMs and v8 on Kubernetes must share mailboxes, files, sign-in and calendars. A big bang cutover moves every user, mailbox and file store in one window, then retires 7.10 for that scope. A hybrid model keeps some user groups or services on 7.10 while others run on v8. A gradual model moves users in waves over a longer period. Each model creates a different coexistence problem, so the choice should follow from the data and identity dependencies you have mapped, not from the calendar alone.

For mailbox and file data, the key question is whether a user's data can be read by both environments at once. In v8, persistent data such as OX Drive files and PIM attachments must sit on a distributed file system, either NFS for small to mid-size deployments or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. If 7.10 cannot point at the same store, each wave copies files and the copy window grows with the data. Ask Open-Xchange and your storage team whether the two environments can share one store, and whether the database schema update allows 7.10 and v8 to read the same MariaDB data during the transition.

Sign-in and shared calendars are where users notice a split first. v8 supports single sign-on through OpenID Connect, and the middleware also documents SAML login configuration, so confirm whether one identity provider can serve users on both sides during a wave. A user who signs in to one environment and opens a calendar shared from the other will hit the share model directly. Keep calendar sharing groups together in the same wave, and test shares that cross the boundary before any user moves. Plan routing at the proxy or DNS level so the user sees one login path during each wave.

The supported coexistence model must be confirmed with Open-Xchange in writing before you choose hybrid or gradual cutover. Ask which data may be written from both environments, whether a user can be routed to either side, how long the two releases may run together, and what support applies to the mixed state. The support commitment supplied for this topic states that a standard release is supported for 12 weeks, and an LTS release is supported until the next LTS release plus six months. Target the current LTS line, v8.47 (FCS 2026-03-18), and confirm whether that line is the one the coexistence model covers.

A practical rule follows from these points. Choose big bang when the shared-data and identity risks are small and the window fits your service commitments. Choose hybrid or gradual only when Open-Xchange confirms the coexistence model and your storage and schema checks pass in a test environment. For each wave, define a rollback point, the data that must be restored to reverse it, and the owner who makes the call. Record these decisions before configuration mapping starts, because they set the order of every later task.

The configuration mapping decides how much of your 7.10 setup carries into v8, so it should be finished before any cutover date is set. List every setting from the current VM deployment and give each one a single outcome: carried over unchanged, rebuilt in the v8 model, or dropped. v8 is delivered as Helm charts that reference container images, and Helm 3.17.0 or newer is required to deploy them. Many settings therefore become chart values, secrets and Kubernetes objects, and fewer remain hand-edited files on a server. Start from an inventory of your middleware configuration, identity integration, storage paths and the services around the suite, then map each item to its v8 location. Confirm every target location with Open-Xchange, because the mapping is only as reliable as the documentation behind it.

Unchanged values describe your organization and your intent, such as domain names, tenant structure, quotas and policy choices, provided the v8 chart accepts them with the same meaning. Rebuilt values are tied to the old platform: file paths, VM hostnames, service placement and anything about caching or sessions. Redis 7.4.x is the v8 default for caching and session storage, deployed through the littlered operator, so a 7.10 session or cache setting has to be recreated for v8. Authentication belongs in the rebuilt group too. Single sign-on through OpenID Connect or SAML must be reconfigured against the v8 login path and tested with your identity provider. Dropped values are settings for features or components that v8 no longer uses or handles differently. Record each drop with a reason and an owner who signs it off.

The database work centers on MariaDB with the InnoDB storage engine, which OX App Suite v8 uses as its primary data store. The supported versions listed in the requirements are 10.6.x, 10.11.x, 11.4.x and 11.8.x, and Galera Cluster is supported. Confirm which version your 7.10 deployment runs, whether the target v8 release requires a database engine upgrade before the schema update, and whether a Galera topology changes any step. Also ask the vendor whether any table in your existing schema uses a storage engine other than InnoDB, and what conversion, if any, the release requires. The schema update tasks should come from the Open-Xchange release documentation, which must list each required step in order. If a step is missing from that list, treat it as a gap to resolve with Open-Xchange before the upgrade plan is approved, and do not improvise the step.

Rehearse the schema update on a copy of production data before any planned window. Restore a recent backup into a separate environment that matches the target database version and topology, then run each task in the documented order exactly as written. Record the start and end time of each task, every warning and every manual intervention, so the production runbook reflects what happened during the rehearsal. Repeat the rehearsal from a fresh restore to confirm the sequence is repeatable and that no step depends on state left behind by an earlier attempt. Verify the result at the application level, including mail flow, calendar and contacts reads and writes, and Drive file access, because a schema that updates without errors can still leave the application misconfigured. Keep the rehearsal log as an input to the cutover decision.

Do not assume a standard procedure for any database task, even if your team has upgraded MariaDB before. Ask Open-Xchange to confirm in writing each task, its order, its prerequisites, whether it can be reversed, the rollback point, the expected verification checks, and whether the chart, the release tooling or an engineer performs it. The same request should name the supported database versions for the exact target release. Cost follows from this list. The rehearsal needs a second database environment, restore time and staff hours to run and log each attempt, and every manual task adds hands-on work to the cutover window. Ask any implementation partner to quote the rehearsal and the cutover as separate line items, so the one-time work is visible and the recurring database operations are clear.

A cutover from App Suite 7.10 to v8 is safe only when every test layer has a written pass criterion and every rollback point has an owner. Functional checks should cover mail send and receive, calendar invitations and free/busy lookups, and contact sync for each client type your users rely on. File and attachment integrity needs its own checks: confirm that sample OX Drive files and PIM attachments migrated to the distributed file system (NFS or object storage) open, match their source checksums, and keep their sharing permissions. Sign-in must be tested through the OIDC or SAML configuration you plan to run in production, using your real identity provider and test accounts for each group and role. Performance testing should replay a load profile built from your own peak mailbox and login figures, not a generic benchmark. Confirm these expected loads with your operations team before the test window opens.

Restore drills are the layer teams most often skip, and they are the one that decides whether rollback is real. Restore the MariaDB backup taken from 7.10 into an isolated environment, restore the file store copy alongside it, and confirm that a user can sign in and read mail from the restored state. Record how long each step took on your hardware, because that measured figure is the only restore duration you can plan around. Redis holds caching and session data, so expect users to sign in again after a rollback instead of planning to restore sessions. Agree the decision points in advance: after the migration rehearsal, after the pilot group has used v8 for an agreed period, and at the final sign-off. At each point, the go or no-go owner, the criteria and the rollback action should be on paper.

Until sign-off, 7.10 must stay intact as a working fallback. That means its databases and file stores remain writable only by the backup process, its configuration and certificates are unchanged, and its DNS records and load balancer targets can be switched back within a window you have tested. Lower DNS record time-to-live values before the cutover so that a route change takes effect quickly. Decide how mail and changes written to v8 will be handled if you roll back after users have worked in it. Reverse synchronization is possible only if you planned it, so ask your partner to state whether it is in scope and what it costs. On the platform side, take an etcd snapshot with etcdctl snapshot save before any Helm upgrade, store it outside the cluster, and rehearse restoring it with etcdutl. Helm rollback does not reverse database schema changes, so confirm what each rollback path reverts.

Before the cutover, ask for the test plan, the restore drill record, the rollback runbook with named owners, and the retention period for the 7.10 environment. Ask what recurring cost keeping 7.10 running adds, and who pays for the reverse data path. Secrets stored in etcd are unencrypted by default, so every etcd snapshot is a sensitive backup. Confirm encryption at rest, restricted access to snapshot storage and the RBAC rules that govern who can read Secrets. Also confirm the Kubernetes version and etcd topology, stacked or external, because that determines which nodes hold the snapshots and who restores them. Document these answers in the cutover plan so the rollback owner does not need to find them during an incident.