When HCL Domino mail or OX App Suite fits best
If your organization keeps Domino applications but questions Domino mail and its per-user licensing, the decision turns on one question: how many of your mail users depend on Notes-specific behavior? Staying on Domino mail fits when workflows, approvals and agents are tightly bound to mail databases, and when applications call mail or calendar functions over NRPC, the proprietary Notes remote procedure protocol. In that case, moving mail alone can break the applications that stay behind, and the cost of re-engineering them usually outweighs any licensing saving. Before deciding, inventory which applications write to or read from user mail files and which ones trigger on mail documents.
OX App Suite fits best when the scope is mail, calendar, contacts and documents, and when your team wants standard protocols such as IMAP, CalDAV and CardDAV so that clients and integrations are not tied to one server. It also suits organizations that have Kubernetes skills in-house or in a trusted partner, since OX App Suite v8 is delivered as Helm charts and expects Istio or a basic ingress-nginx option, Redis, MariaDB and a distributed file system such as NFS or object storage. Confirm the current requirements with Open-Xchange, because the Helm version, Kubernetes support window and LTS release in use change over time. Check the license agreement too: Open-Xchange's Operations Guide notes that certain modules may carry separate fees.
The decision therefore turns on three things. First, application dependencies: the list of Notes applications that must keep working after mail moves determines whether a split architecture is acceptable. Second, entitlement counts: confirm how CCB or Messaging Express counts users, including administrative and test IDs, so the per-user baseline is accurate before you compare it with a self-hosted quote. Third, the operating model: someone must patch, back up and upgrade the chosen platform on a schedule, whether that is your own team or a retained support partner. Put these answers in writing before you ask for a quote.
Which platform fits which scenario
This table compares OX App Suite with grommunio for common Domino mail scenarios and names the condition that makes each one the better fit. Read each row against your own user mix, Notes application dependencies and hosting constraints, then check the conditions before choosing.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Mail and calendar users with few Notes applications | OX App Suite | Users work mainly in webmail, calendar and Drive, and Notes applications that remain are few or can move to other tools |
| Heavy use of Notes applications and NRPC-dependent workflows | Neither without a plan | Keep Domino for application servers during transition, then confirm which application features need replacement before any mail cutover |
| Users who expect Outlook desktop and MAPI behavior | grommunio | Staff rely on Outlook with MAPI or EWS features and expect that client to keep working after migration |
| Teams already operating Kubernetes with Helm and Istio | OX App Suite | Your platform team can run Helm 3.17.0 or newer, Istio and a supported Redis and MariaDB stack, or can confirm they will be added |
| Small teams without a Kubernetes platform | grommunio | You want a conventional server deployment managed by your own administrators rather than a cluster-based stack |
| Air-gapped or data-residency-bound sites | Depends on hosting | Both can run on-premises, but you must confirm offline package delivery, update channels and storage design with the vendor |
| Organizations needing a shared document drive with mail | OX App Suite | Drive files and mail should sit under one platform, with object storage or NFS available for persistent data |
Where the data sits under each hosting model
This is the baseline most readers are leaving. Mailboxes, calendar data and application databases sit in Domino data directories on servers that your organization runs in its own data center or private hosting. Authentication typically depends on the Domino Directory and Notes ID files, and access to mail is governed by Domino ACLs and the Notes client. Evidence for audits usually comes from server configuration, administrator logs and the backup process your team already operates.
- Data location: Mail and calendar databases live on named Domino servers under your control, so residency is set by the physical or hosted location you chose.
- Identity: Users authenticate against the Domino Directory and Notes IDs, which is a proprietary model that does not map directly to OpenID Connect or SAML.
- Access control: Permissions are enforced through database ACLs and roles, which you will need to translate into groups in the new identity source.
- Evidence: Your team already holds server logs, backup records and change history, which auditors often ask to see in both the current and target states.
- Recurring cost: Server hardware or hosting, Domino licensing and maintenance renewals recur, while migration work is one-time.
Before you compare models, confirm with your current Domino administrators which databases, Notes ID files and directory dependencies would have to be preserved.
In this model OX App Suite v8 runs as Helm charts in a Kubernetes cluster that your organization operates, whether in your own data center or your cloud account. 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. MariaDB holds the primary data, and Redis handles caching and sessions. Your team controls the physical location of every component.
- Data location: Mail, calendars, Drive files and databases stay in storage you select, which makes residency and backup location a design decision you own.
- Identity: OX App Suite supports OpenID Connect and SAML, so sign-in can federate to your existing identity provider while group data moves to that source.
- Compliance evidence: DeployOpen can prepare configuration baselines, access reviews and operational records, but auditors and certification bodies issue any report or attestation.
- Operations: Your team patches the cluster, Istio or ingress, databases and storage, and must keep pace with the supported Kubernetes and Istio versions.
- Recurring cost: Infrastructure, storage, staff time and any support subscription recur, which makes sizing of storage a key cost driver.
Confirm with Open-Xchange and your identity provider which OpenID Connect or SAML flows and attributes your sign-in design needs before you commit to a storage layout.
Here OX App Suite runs on the infrastructure of a public cloud provider in an account that your organization owns and controls. The application, databases and object storage are placed in the regions you choose, which lets you match residency commitments to a specific geography. Your team still manages the Kubernetes layer and the data services, but the provider becomes a sub-processor for hosting, so its contractual and certification evidence becomes part of your audit scope.
- Data location: Region selection controls where mail, Drive files and backups are stored, and replication options should be confirmed against your residency rules.
- Identity: Federation through OpenID Connect or SAML works as in self-managed deployments, with the identity provider reachable from the cloud network.
- Shared responsibility: The provider secures the physical and virtualized layers, while your team secures configuration, identities and data.
- Evidence: Provider attestations and your own configuration records are both needed, and DeployOpen can organize them, but issuing audit reports stays with independent auditors.
- Recurring cost: Compute, managed database and object storage charges recur and scale with mailbox volume and retention, while the migration project is one-time.
Ask the provider for the regions, backup locations and sub-processor list in writing, and confirm them against your legal and regulatory requirements.
OX Cloud is the managed service from Open-Xchange, in which the vendor operates the platform. Your organization decides on the contract, the service terms and which data the service holds, but the operating responsibility for the platform sits with Open-Xchange. This model reduces the number of systems your team runs, though it moves data custody and operational evidence to a third party, so the contract must answer residency and audit questions in detail.
- Data location: Confirm in the service agreement where mail, Drive data and backups are hosted, and whether any processing occurs outside that location.
- Identity: Confirm which OpenID Connect or SAML integration the managed service supports for your identity provider and who configures it.
- Operational visibility: Ask what logs, change records and incident notices your team can receive, since your own monitoring may not see the platform layers.
- Evidence: Request the provider's current audit reports and certification scope, and check whether they cover the services you will use.
- Recurring cost: Subscription fees recur, while your internal work shifts toward contract governance, identity configuration and data migration.
No details of OX Cloud hosting regions or certifications were supplied for this page, so request them from Open-Xchange before you rely on this model for a regulated workload.
What running OX App Suite v8 on Kubernetes requires
OX App Suite v8 is delivered as Helm charts that reference container images, so the platform team has to run a Kubernetes cluster that meets the vendor's requirements before any mail is moved. The supplied requirements call for Helm 3.17.0 or newer, and v8 supports Kubernetes versions N-1 and N-2. Confirm which cluster version your distribution ships against that support window, and confirm how your team will track Open-Xchange's release cadence, since the support commitment ends standard releases on a fixed schedule and an LTS line is supported for a limited period after the next LTS arrives.
Ingress is the first design decision. v8 requires Istio, with support for the latest Istio release plus two prior versions. The basic ingress-nginx option exists only where Istio cannot be used, so ask Open-Xchange whether your environment qualifies before you build around it. Redis 7.4.x handles caching and session storage and is deployed by default through the littlered operator, although unmanaged or custom Redis is configurable. Your team must decide which option it will operate, because each one adds an operator or a service to patch and monitor.
The data tier carries most of the operational risk. MariaDB with InnoDB is the primary store, and the supported versions are 10.6.x, 10.11.x, 11.4.x and 11.8.x. Galera Cluster is supported, so confirm the replication topology and backup approach with your database administrators. 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. Your platform team owns the cluster, the Istio mesh, the Redis operator, the database cluster and the storage tier, so name an owner for each before the project is scoped.
Which operating duties move to the platform team
Moving from Domino mail to OX App Suite replaces a vendor-run mail stack with a Kubernetes platform that your team or a partner must keep current. The cards below cover the recurring duties that decide whether that platform stays supported, recoverable and observable, and they show which of those a DeployOpen retainer can take on and which stay with your team.
Release tracking and support windows
OX App Suite standard releases are supported for 12 weeks, ending when the third following release becomes available. LTS releases are supported until the next LTS plus six months, and v8.47 (FCS 2026-03-18) is the current LTS, so many sites should pin to LTS rather than track standard releases. Your team decides which track fits your change calendar and who signs off on each upgrade. A retainer can monitor releases, prepare upgrade plans and test them in a non-production cluster.
Database and cache upkeep
OX App Suite v8 stores primary data in MariaDB with InnoDB and uses Redis 7.4.x for caching and session storage, deployed by default through the littlered operator. Confirm which MariaDB line you run (10.6.x, 10.11.x, 11.4.x or 11.8.x) and whether you use Galera Cluster, because each choice changes patch and failover work. Your DBA team keeps schema, replication and credential ownership. A retainer can cover patching, version checks and failover tests on the agreed scope.
Storage for drive files and attachments
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. Capacity growth in attachments often drives the storage decision more than user count does. Ask who owns the NFS or object store, how quotas are watched and who answers when a volume fills. Your storage team keeps the hardware and tenancy, and a retainer can set up alerts and runbooks.
Backup and restore testing
A mail platform needs backups of the MariaDB data, the file store holding Drive files and attachments, and the Kubernetes configuration that defines the deployment. Each backup is only as good as the last restore, so schedule restore tests for mailboxes and Drive folders, not just backup job success. Confirm your retention periods, legal hold process and recovery time targets in writing before cutover. DeployOpen can design, document and run restore exercises under a retainer, while your team approves recovery targets and retention.
Monitoring and incident response
Mail queues, database replication lag, Redis availability, certificate expiry and storage fill rates all need monitoring that reaches an on-call person. Domino administrators often rely on console checks, so agree on alert thresholds and escalation paths before go-live. Your operations team owns the on-call rota and the paging tool. A retainer can build dashboards, tune alerts and support incident triage within the agreed scope.
Ownership of Istio and ingress changes
OX App Suite v8 requires Istio, supporting the latest Istio release plus two prior versions, and offers a basic ingress-nginx option where Istio cannot be used. Mesh upgrades and certificate changes can break mail access in ways that look like application faults. Decide early which team owns the service mesh and whether ingress-nginx is a compliant fallback for your environment. A retainer can plan and test mesh upgrades, while your platform team keeps change approval for production.
How a move from Domino mail to OX App Suite is sequenced
The sequence turns a Domino mail estate into a tested OX App Suite environment with a known directory source, working free/busy during transition, and mailboxes moved group by group with a rollback path at each cutover.
Inventory mailboxes, calendars and contacts
The Domino administrator and the mail owners list every mail file, delegate, shared mailbox, resource calendar, distribution list and personal contact store, and record which users rely on archives or local replicas. Mail and calendar items are sized per user, and the inventory notes which items carry Notes-only features such as encrypted mail or embedded applications. The step is done when every user and shared object has an owner, a target group and a named migration method, reviewed by the business owners of the mail.
Decide the directory source
The identity team decides which system becomes authoritative for users, groups and aliases once Domino Directory stops being the master, typically an LDAP or identity provider that OX App Suite can authenticate against. The team confirms how OX App Suite's supported login methods, such as OpenID Connect or SAML, will connect to that source, and what happens to group membership and mail routing. Ask OX to confirm the exact directory and login options for your version. The step closes with a written directory design and a mapping of every Domino group to its new home.
Set up the OX App Suite environment
The platform team deploys OX App Suite v8 into your own Kubernetes cluster from the Helm charts, with the required Helm version, Istio or the basic ingress-nginx option, Redis, MariaDB, and a distributed file system or object store for Drive files and attachments. Each component is checked against the supported version list for the release you choose, and backup and restore are tested before any user is placed in the system. The step is done when a pilot account can send, receive, book and share in a non-production copy of the environment.
Run coexistence for free/busy
While users still sit on Notes, the team sets up the routing and free/busy exchange needed so that people on both platforms can see each other's availability and send mail without bouncing. The pilot group tests invitations sent in both directions, recurring meetings, resource bookings and delegated calendars. The step is done when the pilot group confirms that availability lookups and invitations behave correctly for at least one full working cycle, and the open issues are logged with owners.
Migrate extracted mail over IMAP
The migration team extracts mail from each Notes mailbox and loads it into the target OX mailboxes over IMAP, with mailbox folders preserved. Calendars and contacts move in standard formats, such as iCalendar and vCard, and the team checks recurrence rules, time zones and attachments on a sample. Counts of messages and items are compared between source and target for each mailbox. The step is done when reconciliation reports for each batch are signed off by the mail owners, and any items that failed extraction are listed with a remediation plan.
Cut over users by group
Users move in defined groups, with the last delta sync taken, the Notes client redirected or disabled for that group, and mail routing switched to OX for those addresses. The help desk runs a short script for mobile devices, client setup and password handling, and the migration team keeps the Notes source readable for a defined rollback window. Ask the vendor and your legal team how long source data must be retained. The step is done when each group reports successful sign-in, mail flow and calendar access, and the rollback decision for that group has been closed.
Retire or re-home Notes applications
Once mail and calendars are on OX, the application owners review the Notes databases that stay behind, such as workflow or approval applications that depend on Notes mail templates or agents. Each application is either kept on Domino with its own support and licensing, re-platformed to another system, or retired after its data is archived to an approved format. The step is done when every remaining Notes application has a named owner, a documented decision and a retention plan, and the Domino server licensing is reviewed against the users who still need it.
Questions buyers ask before moving off Domino mail
What does it cost to move off Domino mail to OX App Suite?
The cost is the sum of several components, and only some of them are one-time. Expect one-time work for migration design, directory changes, mailbox extraction, calendar conversion, testing and cutover. Expect recurring costs for the Kubernetes cluster, Istio or ingress, Redis, MariaDB, the distributed file system or object storage behind OX Drive and attachments, backups, and OX subscription or support terms. The main drivers are total mailbox volume, number of calendars and shared resources, how many systems depend on Domino Directory, and whether you need Drive and third-party integrations at launch. Ask for a quote that separates one-time services from recurring licensing, infrastructure and support, and that lists each assumption about mailbox counts and data size.
How long does a Domino to OX App Suite mail migration take?
Duration depends mainly on mailbox volume, the number of calendars and contacts, and how much directory work the move needs. Large mailboxes take longer to extract and verify, and a Domino Directory that feeds authentication, distribution lists and address books adds design and testing time before any mailbox moves. Coexistence for free/busy lookups, the cutover order by group, and user communication also set the pace. Ask for a timeline built from a written scope that states the mailbox count, total data size, number of directory-dependent applications and the cutover approach. Any duration in a proposal should trace back to those inputs rather than a generic figure.
What does the migration need from our internal team?
Your team supplies the knowledge of how Domino mail is used, and the decisions that only you can make. This includes the list of mail-dependent applications, the source of truth for identities and groups once Domino Directory stops being used, the mailbox and calendar owners who will validate results, and the change windows for cutover. Network, DNS, certificate and identity integration work also needs an owner on your side, along with someone who can approve the Kubernetes and storage platform that OX App Suite runs on. Agree these responsibilities in the written scope so that gaps appear before testing, not during cutover.
Can our own team migrate Domino mail without an implementation partner?
A capable platform team can do it, but the decision depends on how much of the work they have done before. The skills involved include running Kubernetes with Helm, operating MariaDB with Galera where needed, managing Redis, configuring a distributed file system, and handling Notes mailbox extraction, calendar formats and directory changes. Your team should also own ongoing upgrades, since OX App Suite releases follow a support commitment with defined end dates. A partner can plan, implement, harden, back up, document and support the platform inside your own infrastructure, on a fixed scope agreed in writing, or as a retainer for upgrades and continuing support. Compare the internal effort, with its training and staffing time, against that scope.
Do our Notes applications have to move when we leave Domino mail?
No. Moving mail and calendars to OX App Suite does not require moving Notes databases, and many organizations keep their Domino applications running while they change the mail platform. The practical question is which applications depend on Domino mail, such as workflow notifications, approval routing, or applications that send mail through the Domino router. Each of those needs a new mail submission path, a new address lookup, or a change in how it reads calendars. Inventory these dependencies before design begins, and decide whether each one stays on Domino, is rebuilt, or is retired.
How do we confirm the licensing terms for OX modules before we commit?
Ask for the license agreement in writing before signing, and confirm which modules and features you will use. 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, so webmail, calendar, Drive and any add-on features should each be checked. Also confirm the support tier, the release and LTS policy that applies to your version, and whether the AGPL-licensed App Suite code on GitHub covers the components you deploy. Request a quote that lists each module, its terms and any recurring fees, so you can compare it with your current Domino CCB or Messaging Express entitlements.
Which parts of the platform should we check for operational risk?
Focus on the components that can stop mail delivery or access if they fail. For OX App Suite v8 these are the Kubernetes cluster and its version support window, the Istio service mesh or the ingress-nginx option, Redis 7.4.x for caching and sessions, MariaDB with InnoDB in one of its supported versions, and the distributed file system that holds Drive files and attachments. Confirm backup, restore and failover for each, and check that the storage choice fits your size, such as NFS for small to mid-size deployments or object storage for larger ones. Ask the vendor or implementation partner to document these dependencies and the support dates for each release you plan to run.
How DeployOpen evaluates and implements the switch
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure. For a move from HCL Domino mail to OX App Suite, we start with a written scope that separates mail, calendar and directory work from the Notes applications that may stay in place.
How we scope
- Inventory which Domino mail, calendar and contact data must move, and which Notes applications stay on Domino.
- Record how users, groups and authentication are sourced today and which directory will replace Domino Directory.
- Agree deliverables, timelines and responsibilities in writing before any work starts, as engagements are fixed-scope.
- Confirm with Open-Xchange the license terms for the modules and features in scope, since some may carry separate fees.
How we build
- Plan the OX App Suite v8 target on Kubernetes with Helm, Istio or ingress-nginx, and the MariaDB, Redis and file storage tiers.
- Test mail extraction over IMAP and calendar conversion in standard formats against a representative sample of mailboxes.
- Design coexistence for free/busy lookups and mail routing during the transition period, then test cutover order in a non-production environment.
- Run security testing on the new webmail, API and identity integration before production use.
How we hand over
- Document the architecture, configuration, runbooks, backup and restore steps and upgrade procedure for your operations team.
- Deliver evidence of controls and configuration to support your own compliance assessment, without issuing any audit report or certification.
- Run knowledge transfer sessions with administrators and service desk staff covering day-to-day operations.
- Agree a written list of open items and the owner of each before the final handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Track Open-Xchange release and LTS timing so upgrades are planned against the published support commitment.
- Re-run tests and review configuration when Kubernetes, Istio or database versions change within supported ranges.
- Ask any retainer provider to confirm response scope and escalation paths in writing before signing.
