Open-Xchange for telecom and hosting providers

Sizing an OX App Suite deployment for provider scale starts from a written mailbox forecast and a load test profile, not from a per-mailbox rule of thumb. The inputs that matter most are the mailbox count for each tenant, the expected growth per tenant and per quarter, peak concurrency (how many users are logged in and active in the busiest hour), and the volume of attachments and OX Drive files each mailbox will hold. Each of these drives a different component, so a single average figure hides the load that breaks the platform. This section gives no capacity figure. Ask the partner for a sizing model built on your own forecast and on load tests run against a realistic copy of your tenant mix, with the assumptions written down so you can challenge them.

Attachment and Drive volume decide the storage design. OX App Suite v8 requires persistent data such as OX Drive files and PIM attachments to sit on a distributed file system. NFS fits small to mid-size deployments. For larger ones, the supported options named in the requirements are object storage such as Ceph RadosGW, AWS S3 or Scality RING. The choice depends on where you run the platform and what your team already operates. If you already run Ceph or a compatible object store, that usually changes the cost and skills picture. Confirm throughput, metadata behavior, replication and backup for the option you choose, and collect the attachment size distribution and retention policy before the storage tier is sized.

The database and cache are the two places where early design mistakes are expensive to reverse. MariaDB with InnoDB is the primary data store, and the supported branches are 10.6.x, 10.11.x, 11.4.x and 11.8.x. Galera Cluster is supported, so the decision is whether to run a Galera cluster, how many nodes it needs for your availability target, and how write load from many tenants will behave under synchronous replication. Redis 7.4.x handles caching and session storage. The littlered operator deploys it by default, and unmanaged or custom Redis setups are possible. Decide whether Redis is dedicated, shared or placed per region, because session volume tracks peak concurrency and a shared instance can fail for every tenant at once. Confirm each choice with the vendor's current requirements.

Turn these decisions into a short list before requesting a quote. Give the partner the mailbox forecast by tenant and region, the peak hour assumption, the attachment and Drive profile, the availability target, and the storage platform you already operate. Ask what the sizing model covers: the node counts for the application, database and Redis tiers, the storage capacity and growth plan, the load test method, and the headroom it assumes. Also ask which items are fixed in the written scope and which are re-measured after the first load test. A quote built on these inputs lets you compare a partner's model with your own team's estimate on the same assumptions, instead of comparing two unexplained numbers.

The EU Data Act requires providers of data processing services to let customers switch to another provider or to on-premises ICT infrastructure. For a telecom or hosting provider running white-labeled OX App Suite, this means your mail offering must be designed so that a business or consumer customer can leave with their mailboxes and data. The Act sets a maximum two-month notice period for switching and a 30-day transitional period, as set out in Articles 23, 25 and 50 of Regulation (EU) 2023/2854. These are obligations to plan for now, not after a customer asks. The Data Act has applied since 12 September 2025. From 12 January 2027, providers of data processing services may not impose any switching charges. Until that date, any reduced switching charge may not exceed the costs directly linked to switching, under Article 29. Review your customer terms, notice clauses and fee schedule against these limits, and decide which internal costs you can document as directly linked to a switch. Ask counsel whether your white-label mail service, and the way you contract with your own customers, falls under the Act. This section is an engineering summary, not legal advice.

Switching is only possible if the data can be taken out in a usable form. In OX App Suite v8 on Kubernetes, mailbox and calendar data sit in MariaDB with the InnoDB engine, while OX Drive files and PIM attachments sit on a distributed file system such as NFS or object storage. An exit plan that exports only the database will leave attachments and files behind. Identity is a separate concern: if customers sign in through OpenID Connect or SAML, you need a mapping from identity-provider accounts to exported mailboxes so the receiving environment can match users. Redis holds cache and session state, so it is not a primary exit source. Before committing to an exit commitment, confirm with Open-Xchange which export formats and tooling your release supports for mailboxes, contacts, calendars and files. Then document each format, its version, and the fields that will not survive the transfer. Customers and receiving platforms need that list in advance.

An exit runbook is the document that turns these capabilities into a repeatable procedure. It should name the owner for each step, including the people who approve a switch request, run the per-tenant export, verify it, hand over the data and decommission the old context. Include checks that compare message and file counts and checksums between source and target, and state how long backups of the exported data are kept before deletion. Record the evidence of each step, because you will need it if a customer disputes the switch. Runbooks only count once they have been rehearsed. Run a full export and import into a non-production target for a representative tenant, time each stage, and compare the result against the two-month notice and 30-day transitional periods the Act sets. Repeat the rehearsal after each OX App Suite upgrade and after any change to storage or identity. When you request a quote, ask for the exit runbook, the export tooling, the rehearsal, and the support hours during a switch as separate line items.

Ask your engineering and legal teams to agree on three decisions before the next product review: which offerings are in scope of the Act, which exit formats you commit to in writing, and who signs off that a rehearsal met the timing your contracts promise. These decisions shape the architecture more than any single setting does, so make them while the tenant model and storage layout are still open.

Settle the licensing position before you ask for a quote, because it changes what the quote covers. Open-Xchange's Operations Guide 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. For a telecom or hosting provider, that makes tenant design and module choices cost decisions as well as product decisions. A design that gives every reseller context the same feature set may fall under different terms than one that enables a few add-on modules for selected business customers. Ask Open-Xchange for a module-by-module statement of what is included, what is limited and what is priced separately, and test it against the tenant model you plan to run.

Ask which charges recur and what they are measured against. A quote from DeployOpen covers implementation work under a written scope, but module entitlements, license fees and any usage-based terms come from the license agreement with Open-Xchange. Confirm whether any charge is tied to mailboxes, contexts, tenants or specific modules, how it is counted, and whether it renews annually or on another schedule. Also confirm how the agreement treats white-label branding and whether any restriction applies when you resell the service to your own customers. Get these answers in writing before you size the environment, because changing tenant structure after go-live can change the license position as well.

Plan releases around the support commitment, not around the feature list. A standard release is supported for 12 weeks, ending with the availability of the third following release. An LTS release is supported until the next LTS release plus six months. v8.47 (FCS 2026-03-18) is the current LTS, and v8.35 (FCS 2025-03-12), the first v8 LTS, is now discontinued. For a fleet serving many tenants, standard releases arrive too quickly to stage upgrades across all of them safely, so most providers should run on an LTS track. The newest release listed in the commitment is v8.53, which is a reason to confirm your upgrade path, not a reason to move the fleet.

Choose an LTS track for the fleet, then write the release calendar around its end date. Record the date on which v8.47 support ends, which depends on the next LTS release plus six months, and schedule rehearsals on a staging copy of your largest tenants before that date. Confirm in writing with Open-Xchange what counts as the next LTS, how much notice you receive, whether security fixes are available for a discontinued release, and how license terms carry across an upgrade. If any tenant is still on v8.35, treat migration off it as an open risk with an owner and a deadline. These checks should be part of the statement of work, so the cost and timing of upgrades are visible in the quote.