How to migrate Domino mail to OX App Suite without losing mail or calendars
A renewal, a licensing change or a data residency requirement has forced a decision on Domino mail, and the good news is that mail and calendars can move to OX App Suite over standard protocols. The harder part is everything around the mailboxes: the directory that today tells Notes who users are, free/busy lookups during coexistence, and the Notes applications that send mail, approvals or calendar invitations. Those dependencies need separate planning before the first mailbox moves. This section sets out who usually does that work and how to frame the effort and risk, without judging the product you are leaving. Most organizations run the migration with internal messaging, identity and application owners, supported by an implementation partner such as DeployOpen for the platform build, integration and cutover runbooks. Your internal team owns the decisions that only it can make: which mail-enabled applications stay on Domino, which groups and distribution lists survive, and how users are authenticated once the Domino Directory stops being the source of truth. The partner typically carries the Kubernetes deployment of OX App Suite v8, its database and storage layers and the test migrations. Ask any partner to show how it will handle your Notes application dependencies before you agree the scope. The risk level is moderate and concentrated in a few places: mailbox extraction over IMAP, calendar data that must be converted into standard formats, and the cutover window in which users and applications may point at different systems. Treat a pilot group as the first milestone, confirm with Open-Xchange which OX App Suite release and support window you will be on, and check the current release details in the OX Support Commitment before fixing the target version. Effort depends mostly on mailbox volume, the number of applications and how much history each user must keep.
Which Domino mail capabilities map to OX App Suite and which need rework
This table maps common Domino mail, calendar and directory capabilities to OX App Suite components and labels each row as clean, needs rework or gap. Use it to scope the migration, then confirm parity for every row against a test tenant before committing to a cutover date. The main takeaway is that mail and calendar data move through standard protocols and formats, while Notes-specific automation, agents and directory logic need design work.
| Capability | OX App Suite equivalent | Label and what to confirm |
|---|---|---|
| Mail store and folders | OX Mail over IMAP | Clean for standard folders. Confirm how Notes folder hierarchies and message flags map during extraction. |
| Calendar entries | OX Calendar | Needs rework. Export in standard calendar formats and test recurring series, exceptions and time zones. |
| Contacts | OX Contacts | Needs rework. Confirm field mapping from Domino personal address books and group contacts. |
| Shared mail and mailbox access | Shared folders and delegated access in OX Mail | Confirm. Verify how shared mailboxes are modeled and whether permissions carry over. |
| Delegation and send-on-behalf | OX Mail delegation settings | Confirm. Test each delegation type used in your environment before cutover. |
| Free/busy lookup | OX Calendar availability during coexistence | Gap until tested. Coexistence free/busy with the Domino calendar must be validated end to end. |
| Mail rules and agents | OX Mail server-side rules | Needs rework. Notes agents using LotusScript or formulas must be rewritten, not imported. |
| Directory lookups | Identity source chosen for OX App Suite | Needs rework. Domino Directory stops being the source, so address resolution and group membership must come from a new directory. |
| Notes applications and NRPC | Not provided by OX App Suite | Gap. Notes applications and NRPC do not map to OX App Suite and must be planned separately. |
What data can be extracted from Domino and what must be rebuilt
Mail and calendar data can usually be moved over standard protocols, but directory, single sign-on and Notes applications do not move on their own. Each card below marks one piece of the Domino estate that needs a decision before the cutover plan is fixed. Confirm export formats and tooling in your own environment before committing to a timeline.
Mailbox content over IMAP
Mail is the part of the estate most likely to move cleanly, because OX App Suite's mail side is built on standard IMAP access. Plan the extraction as a per-user copy from the Domino mail file to the target mailbox, with folder mapping agreed in advance. Check how each Domino mail template handles attachments, encrypted messages and archived folders, since these are where copies most often differ from the source. Confirm the migration tool and its handling of Notes-specific items in your own environment.
Calendars and contacts in standard formats
Calendar entries and contacts need to leave Notes in formats the target can import, such as iCalendar and vCard, rather than as proprietary Notes records. Recurring meetings, delegated calendars and room bookings are the usual points of loss, so test them with real user samples. Ask your migration partner to define which items are carried over, which are recreated by hand and which are left behind.
Directory replacement for Domino Directory
Domino Directory holds user records, groups and mail routing that the target platform will not inherit. Decide which system becomes the source of truth, typically an LDAP directory or Active Directory, and map Domino groups and mail addresses into it before any mailbox moves. Every alias and distribution list needs a named owner in the new directory, or mail will bounce after cutover.
Single sign-on for the new suite
OX App Suite can authenticate through OpenID Connect or SAML, which replaces Notes password and ID file logins. Choose the protocol that your identity provider supports, then test sign-in, session timeout and logout for each user group. Confirm which identity provider you will run and whether it needs changes before the pilot starts.
Application links and mail-enabled Notes apps
Notes applications that send mail, pull data from Domino databases or open documents through links will break when mail moves. List every workflow, approval routing and scheduled agent that touches mail, then decide for each whether to rebuild it, redirect it or keep Domino running for that application. Treat mail-enabled applications as a separate workstream with its own owners and test cases.
Reconcile before you commit
Before fixing the scope, run an inventory of Domino databases, mail templates, directory entries and integrations, and record which are in use. Confirm with the vendor and in your environment which export paths, formats and API access your Domino version supports. The output of that inventory becomes the basis for a written scope and quote.
How free/busy and mail routing run during coexistence
Both systems must run in parallel for longer than the mailbox move itself. Users migrate in groups, so for some period people on Domino and people on OX App Suite will send invitations to each other, and the calendar lookups between them have to keep working. Plan coexistence as a stage of its own, with a named owner, a start and an end criterion, and a test group that exercises every path before any wider wave. Mail routing and calendar visibility are separate problems, and both need decisions before the first batch moves.
Mail routing is usually staged per user group. Define the groups by mailbox batch, then set the MX or smart-host routing so inbound mail for a migrated user reaches OX App Suite while unmigrated users remain on Domino. Where a user has a mailbox on both sides during the transition, decide whether Domino forwards to the new address or whether the directory alias points to one primary mailbox. Confirm with your Domino administrators how existing mail-in databases, server-based rules and Notes-side forwarding behave for migrated users, because these are often left behind and deliver mail to a mailbox that no longer receives new items. Document the routing table per group so that a rollback step is possible.
Cross-system free/busy is the part you must confirm yourself. Free/busy lookups depend on how OX App Suite can query the Domino calendar store, or on how each side publishes availability to the other, and that depends on your Domino version, your server configuration and your OX App Suite deployment. Ask Open-Xchange and your own Domino team to demonstrate, in a test tenant, a meeting request from an OX user to a Notes user and the reverse, including the free/busy grid and the response processing. Treat this as the most common source of scheduling confusion: a stale or empty availability view leads users to double-book rooms and people, and it rarely fails loudly.
The migration sequence from inventory to Domino decommission
This sequence moves Notes mail, calendars and contacts to OX App Suite in controlled stages, so each group is verified before its routing and directory changes become permanent. Each step produces a written record that the next step depends on.
Inventory mailboxes, calendars and contacts
Export a complete list of mail files, calendar owners, shared and resource calendars, contact databases, mail-in databases and delegations from the Domino Directory and server statistics. Include every mail-enabled Notes application, such as workflow or approval databases that send or receive messages, because these need a routing decision rather than a mailbox move. Who does it: the Domino administrator with the mail team. Done when the inventory is reviewed line by line, every item has an owner and a target (mailbox, shared mailbox, application stays on Domino, or retire), and the list is signed off as the migration baseline.
Confirm the target design and directory source
Decide which directory will authenticate OX App Suite users and where user, group and resource records will live once Domino Directory stops being the source, and confirm the OIDC or SAML options for login with Open-Xchange documentation. Record how Domino groups map to distribution lists and shared folders. Who does it: architecture and identity owners with the migration partner. Done when a design record lists the authoritative directory, the attribute mapping and the coexistence approach for free/busy, and the open items are assigned.
Run a pilot group end to end
Choose a small, representative pilot group that includes users with delegations, shared calendars and mail-enabled applications. Extract mail over IMAP and calendars and contacts in standard formats, load them into OX App Suite on the target Kubernetes environment, and test sending, receiving, calendar invitations and delegate access from both the new client and any remaining Notes clients. Who does it: the migration team with pilot users. Done when the pilot users sign off in writing against a checklist, and the discrepancies found are logged with fixes and retest results.
Operate a parallel run with routing changes
Keep Domino and OX App Suite running together. Change mail routing for the pilot group and configure the free/busy and directory exchange chosen in the design, then monitor delivery logs, queue depth and calendar lookups for both platforms. Re-run incremental extracts so messages received during the pilot are not lost. Who does it: messaging operations with the Domino administrator. Done when a routing change record documents each MX, connector and directory change with its rollback step, and the parallel run shows no unresolved delivery or lookup failures for the pilot group.
Cut over remaining groups in waves
Move the remaining users in groups rather than all at once. For each wave, freeze new Domino delivery for that group only, run the final incremental extract, verify counts and folder structure, switch routing and directory entries, and give users a short support window. Who does it: the migration lead with service desk and affected business owners. Done when each wave has a cutover record listing the users moved, the verification results and the rollback decision, and the service desk confirms no open access tickets.
Retire Domino mail and decommission
After all groups are live and the retention period agreed with compliance has passed, archive remaining Domino mail files that policy requires to be kept, remove mail routing and replication for those databases, and retire the mail templates. Keep applications that stay on Domino running under their own plan. Who does it: the Domino administrator, compliance owner and migration lead. Done when a decommission record lists each retired component, the archive location and the retention basis, and the compliance owner signs off that no mail is delivered to the old servers.
What drives migration cost and duration
This table breaks down the cost components of a Domino mail to OX App Suite migration and the drivers that move each one. Use it to see who is paid for what, which items recur, and which quote lines to request before comparing offers.
| Cost component or driver | Why it matters | How to keep it down or what to ask for |
|---|---|---|
| Infrastructure: Kubernetes, Istio or ingress-nginx | OX App Suite v8 is delivered as Helm charts for Kubernetes, requires Helm 3.17.0 or newer, and expects Istio, with ingress-nginx as a basic option where Istio cannot be used. | Ask the implementer which ingress option fits your platform and who maintains the cluster after handover. Confirm Kubernetes version support with Open-Xchange before sizing. |
| Infrastructure: MariaDB, Redis and file storage | MariaDB (InnoDB), Redis 7.4.x and a distributed file system for OX Drive files and PIM attachments are all required. Storage needs grow with mailbox and attachment volume. | Request a sizing worksheet covering database, cache and NFS or object storage. Ask whether Galera Cluster is included in the quote and which supported MariaDB line is recommended. |
| OX licensing and separately licensed modules | OX App Suite licensing is set in the license agreement, and the Operations Guide notes that some modules or features may carry custom packaging, limitations or separate fees. | Request a written list of every module and feature in scope, with its license terms, recurring fees and any support tier. Confirm which LTS line the quote targets. |
| Internal staff time | Your team must own the cluster, directory integration, user communication, helpdesk readiness and sign-off on each migration wave. This effort recurs after cutover for operations. | Ask the implementer to name the roles your staff must fill and the hours they must commit by phase. Plan for staff who will run upgrades on the support commitment cycle. |
| Implementation and migration services | Fixed-scope work covers architecture, customization, integration, coexistence design and mailbox moves. Scope drives the number of phases and test cycles. | Require a written scope listing sources, number of mailboxes, groups, calendars and contacts, plus deliverables and acceptance criteria before work starts. |
| Testing and cutover rehearsal | Mail, calendar and free/busy behavior must be checked with real client profiles before users move. Each failed rehearsal adds time to the plan. | Ask for a test plan that includes sample migrations, free/busy checks and a rollback procedure. Confirm who signs off each test. |
| Driver: mailbox volume and attachment size | Larger mailboxes and heavy attachment use increase extraction time over IMAP, storage consumption and the number of migration passes. | Measure mailbox sizes and attachment totals per group before quoting. Consider archiving or purging old mail on the Domino side with business agreement first. |
| Driver: number of groups and directory complexity | Domino Directory groups, nested groups and person documents must map to a new directory source. Each mapping rule adds design and test work. | Export a full group and membership inventory. Ask for a mapping document that shows how each group becomes an OX group or directory object. |
| Driver: custom Notes applications | Notes databases with workflows, agents or embedded mail logic usually stay on Domino and need separate planning, so they expand scope if moved. | List each application, its owner and its dependency on mail or calendar. Decide with the business whether each one stays behind, before the quote is written. |
What usually goes wrong in a Domino to OX App Suite move
Most Domino to OX App Suite problems come from the gaps between two systems that run side by side during coexistence: calendars, identities, applications and storage. Each card below names one failure point, why it matters for this move, and the check to run before users see it.
Free/busy breaks during coexistence
Users on Notes and users on OX App Suite need to see each other's availability while mailboxes move in batches. If free/busy lookups are not routed between the two systems, meeting invitations look free when they are not. Before the first pilot group moves, test lookups in both directions with a set of mixed test accounts and confirm which team owns the routing configuration during the coexistence period.
Directory identity mismatches
When Domino Directory stops being the source of truth, user names, primary addresses and aliases often disagree with the new identity source. A mismatch can send mail to a dead address or create a second mailbox for the same person. Export the directory, compare every primary and alias address against the target identity store, and agree a rule for names with accents, hyphens or changed surnames before the first batch.
Mail-enabled Notes applications fail after cutover
Notes applications that send mail, route approvals or read from mail files often assume a Domino mail server exists. After cutover those messages can queue, bounce or disappear. Inventory every application that calls the mail router or reads mail databases, assign an owner to each, and test a send and a receive path in a non-production copy before the final cutover date.
Attachment and storage sizing errors
OX App Suite stores attachments and Drive files on a distributed file system, so the storage plan has to cover the attachment-heavy mailboxes that Domino often holds, not only the average mailbox. Under-sizing the file layer is a common cause of failed imports and full volumes. Measure attachment volume per mailbox from the Domino side, pick NFS or object storage based on the deployment size listed in the requirements, and leave room for the import itself.
Lost delegations and mail rules
Delegate access, shared mailboxes and server-side mail rules are often configured in Notes in ways that a plain IMAP extraction does not carry across. Assistants may lose access to an executive's calendar, and filing rules may stop working on day one. Build a list of delegations and rules per user during the pilot, rebuild them in OX App Suite, and ask each pilot user to confirm their own setup before the wider batches move.
Licensing scope surprises from module terms
Open-Xchange 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. A deployment that works in the pilot can then fall outside the agreed scope when more users or features are enabled. Before the quote is accepted, ask the vendor to list each module, feature and user limit in writing and confirm which ones apply to your planned rollout.
How the migration differs by organization size and starting point
A small Domino site with a limited number of mail-only users usually has the simplest path. Most mailboxes can be extracted over IMAP, calendars and contacts can be exported in standard formats, and the project can run as a single wave with a short coexistence period. The main work is confirming that the directory, DNS and client settings are ready for the new platform, and that users who relied on Notes-only features understand what changes.
- Fewer moving parts: A single OX App Suite deployment on Kubernetes can serve the whole user base, so the platform build is the largest technical task.
- One cutover wave: With few users, the team can often move everyone in one window and avoid long mixed-platform periods.
- Mail-only users: Confirm which users depend on Notes databases. Users who only read mail and use the calendar are the easiest to move first.
- Lighter coexistence: Free/busy sharing across platforms may matter less, but confirm whether any users book rooms or invite external partners.
- Small-team skills: Plan for the platform team to operate Kubernetes, Helm, Istio or ingress-nginx, MariaDB and Redis after handover.
Before committing, ask your vendor and your own team to confirm the current OX App Suite requirements for your size and whether a basic ingress option fits your network.",
A large Domino site usually has many mailboxes, shared mail-in databases, workflow applications and server-side agents that read or write mail. Here the sequence matters more than the mailbox copy itself. Teams should inventory which applications send mail, which read calendar data and which depend on the Domino Directory, then group users into waves by business unit so each wave can be tested against its own applications.
- Inventory before waves: List every mail-linked application, mail-in database and scheduled agent, and assign each an owner and a cutover decision.
- Pilot group: Start with a representative group of users to test extraction speed, folder mapping and calendar fidelity before scaling.
- Operational scale: Plan storage on a distributed file system such as NFS or object storage, because the platform requirements change at larger sizes.
- Coexistence period: Expect longer mixed operation. Confirm how free/busy and room booking behave between platforms for each wave.
- Change control: Each wave needs a rollback plan, mailbox count checks and a named owner for user communication.
Ask for a written wave plan that lists applications, owners and test evidence for each group before any mailbox moves.
In a regulated organization, the migration must show where mail and calendar data went, who had access during the move and how retention was preserved. The technical steps are similar to other sites, but the project needs more documented evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Your compliance lead should agree the evidence list before extraction begins.
- Data handling records: Document the extraction path, the staging locations, who can access exported archives and when those archives are deleted.
- Retention mapping: Confirm how Domino retention rules, legal holds and archive policies translate to OX App Suite. Do not assume they carry over.
- Access controls: Use named administrator accounts, logged changes and separation of duties for the migration tooling.
- Verification evidence: Keep mailbox counts, sample message checks and calendar reconciliation reports for each wave.
- Scope of assessment: Ask your auditor which controls apply to the new platform and which to the old, and plan for a period where both are in scope.
Confirm with your auditor and compliance lead which evidence they will accept before the first wave starts.
Some Domino sites depend on Notes applications that are deeply tied to mail, such as approval workflows, document libraries and custom forms that send notifications. Moving mail to OX App Suite does not move those applications. The project must decide which applications are retired, which are rebuilt elsewhere and which stay on Domino during a longer transition. The cutover order then depends on how many workflows still need the Notes mail path.
- Application classification: Sort applications into retire, rebuild, keep on Domino and integrate. Each category sets a different sequence.
- Notification paths: Identify where applications send mail through SMTP and confirm that the replacement path still reaches users and is logged.
- Keeping Domino longer: Some organizations keep Domino for applications while moving only mail. Plan the coexistence and directory dependencies for that model.
- Data extraction: Application databases often hold records that users need. Decide whether to export them to standard formats, archive them or leave them in place.
- Testing burden: Each workflow needs its own test cases and user sign-off, which often sets the pace more than mailbox volume.
Ask for a full application inventory before agreeing the sequence, and confirm whether any application needs a separate project.
Questions buyers ask before moving Domino mail to OX App Suite
What does a Domino mail migration to OX App Suite cost, and what drives it?
The cost is set by the components in the written scope, not by a single licence figure. The main cost lines are the OX App Suite subscription or licence terms, the Kubernetes, storage, database and Redis infrastructure, the migration tooling and labour, and the parallel running period while both systems exist. Infrastructure and labour are typically the largest one-time items, while licences and hosting recur. Costs rise with mailbox count, mail volume and archive size, the number of Notes applications that need a home elsewhere, and the number of directory and client integrations. Ask for a quote that separates one-time work from recurring costs, and confirm with Open-Xchange whether the modules you need carry custom packaging or separate fees, as the Operations Guide notes. DeployOpen does not publish prices; a quote follows from the written scope.
How long does a Notes mail migration take, and what sets the timing?
The duration depends on the number of mailboxes, total mailbox and archive size, how many calendars and shared resources need to move, and how many systems depend on the current mail flow. Timing is also set by the platform work that comes first, including the Kubernetes cluster, Istio or ingress choice, MariaDB, Redis and the distributed file system for attachments. Pilot waves, a freeze window for each group of users and the cutover order all add time. Ask for a timeline in the written scope with milestones for each wave and a named rollback point. Your own change calendar and any regulatory retention review will also shape when cutover can happen.
What does the migration need from our internal staff?
Internal staff are needed for decisions and access, not for building the platform alone. Expect requirements from mail administrators who know the Domino Directory and mail routing, from application owners who decide which Notes databases stay on Domino, from identity staff who will supply the new directory or SSO integration, and from service owners who approve the cutover. Someone must also own user communication, helpdesk scripts and sign-off on test results. Ask the implementation partner to list these roles in the scope document with estimated hours per role, so you can plan backfill before work starts.
Can our own team run the Domino to OX App Suite migration without a partner?
A capable team can do it, but the work is specialised. The platform needs Kubernetes operations skills, Helm 3.17.0 or newer, the Istio or ingress-nginx design, and database and storage administration. The data move needs an approach for extracting mail over IMAP and converting calendars and contacts into standard formats, plus testing of free/busy and client behaviour. Teams that run this rarely often find that the hardest part is the coexistence and directory work, not the mailbox copy. Ask yourself whether you can staff those skills through cutover and the first upgrade cycle, since the OX support commitment means standard releases are supported for a limited period and must be kept current. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms in your environment, usually under a fixed scope agreed in writing before work starts.
Will Outlook and Notes clients keep working during and after the move?
Outlook is not the target client for OX App Suite, so Outlook users need to be planned as a separate change. OX App Suite's mail is accessed through its web interface and standard protocols such as IMAP, which is also how mail is extracted during migration. Notes clients use the proprietary NRPC protocol and will not connect to OX App Suite, so Notes users move to a new client on cutover. During a coexistence period, confirm which users stay on Notes against Domino, which move to OX webmail, and how mail routing and delegation behave for shared mailboxes. Test each client type in a pilot wave and document the user steps before the first move.
How does free/busy work between Domino and OX App Suite during coexistence?
Free/busy during coexistence depends on whether the two calendar systems can read each other's availability, and this is one of the points to confirm in the design before any cutover. Domino and OX App Suite use different calendar stacks, so a shared availability view usually needs a deliberate integration, a published availability feed, or a documented limitation for the coexistence window. Ask the partner to demonstrate free/busy lookups for a pilot group in both directions, and to write down which meeting-scheduling actions fail during the period. Plan for a short window where users see incomplete availability, and set the cutover order so that teams who schedule heavily move together.
Which licensing terms should we confirm before committing to OX App Suite?
Confirm the licence model in writing before you sign anything. Ask Open-Xchange which modules and features are included in your agreement, because the Operations Guide states that some modules or features may be subject to custom packaging, limitations or separate fees. Confirm how the licence counts users, service accounts and shared resources, what support tier applies, and how the release cadence affects your obligations. Note that the AGPL-3.0 licence for the published App Suite code is separate from the commercial terms for packaged support and modules. Also confirm the terms for renewal, term length and any charges when you add users, since these recur over the life of the platform. Ask your legal or procurement team to review the agreement against your Domino CCB or Messaging Express licences so the two overlap windows are costed correctly.
How DeployOpen scopes and runs a Domino to OX App Suite migration
DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted OX App Suite deployment inside your own cloud account, data center or air-gapped network. For a Domino migration, the scope usually starts with decisions only you can make: which Domino mail and calendar databases move, whether Domino Directory stays authoritative for any identity data, and which Notes applications remain on Domino. Those decisions shape the Kubernetes cluster, the Istio or ingress-nginx choice, the MariaDB and Redis layout, and the NFS or object storage backing for OX Drive and PIM attachments. Most engagements are fixed-scope, so the deliverables, the cutover sequence and the acceptance checks are written down and agreed before any work starts.
Delivery typically covers the platform build, the directory and single sign-on integration, the extraction and load of mailboxes, calendars and contacts, the coexistence arrangement for free/busy during the transition, backup and restore testing, and the operating documentation your operations team will use after handover. Before you sign, ask for the written list of what is excluded, including any OX module or feature that may require separate licensing under the agreement with Open-Xchange, and confirm which OX release line is in scope and how its support window will be handled. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configuration records, access reviews and backup test results, but it does not issue audit reports, attestations or certifications. Your independent auditor or certification body makes those determinations. DeployOpen does not publish a price list. A quote follows from the written scope, and ongoing support, upgrades and continuous testing are available as retainers once the migration is complete.
