What an Open-Xchange migration involves
This service covers two different starting points, and the work differs between them. The first is moving users, mailboxes, calendars and contacts from another mail platform into OX App Suite. The second is moving an existing OX App Suite 7.10 installation to v8, which is designed to run on a Kubernetes cluster, is delivered as Helm charts that reference container images, and relies on MariaDB, Redis and a distributed file or object storage layer for persistent data.
v8 is a different deployment model, not an upgrade in place. A 7.10 installation cannot be patched into v8. The practical move is a data and cutover project: you build the v8 target, transfer and verify data, then switch users over. Plan for both environments to exist for some period, and confirm with Open-Xchange which data export and import paths apply to your 7.10 version and database layout before you commit to a schedule.
Teams with mail operations experience and a Kubernetes platform team can often do parts of this in-house, such as cluster preparation, chart deployment, and user communication. Cross-platform data mapping, cutover sequencing and coexistence planning are where outside help is most often used, because mismatched folder structures, identity attributes and calendar formats tend to surface late. Ask any partner to show how they will test a sample mailbox end to end before full cutover.
What the migration work includes
Each package ends with a named deliverable you keep, so your team can check progress and run the platform after handover. The work depends on separate OX platform topics for Kubernetes and Helm, database and storage design, SSO, high availability and hardening, which are scoped on their own pages.
Source assessment and inventory
We inventory mailboxes, calendars, contacts and attachments on the source platform, including counts, sizes, shared folders, delegations and non-standard data. The output is a migration inventory that shows what moves, what is archived and what is out of scope. Confirm early who owns data cleanup decisions, because stale or duplicate items change the migration size and duration.
Target design on v8
We design the OX App Suite v8 target environment, including the storage choice for OX Drive files and PIM attachments (NFS or object storage) and the identity approach for user provisioning and sign-in. Decisions on Redis, MariaDB and Istio are documented here and linked to their own topics. The deliverable is a target architecture document with a decision record for each storage and identity choice.
Migration tooling and test runs
We select and configure the migration tooling for the source and target pair, then run trial migrations against a copy of production data. Each test run records error rates, skipped items, mapping gaps and throughput. The deliverable is a tested migration runbook with run logs from at least one full trial and a list of known exceptions to resolve before cutover.
Coexistence and mail routing
During the transition, some users remain on the source system while others move, so mail routing, free/busy lookups and address resolution must work across both platforms. We design the routing rules, MX and relay changes, and the sequence of user batches. The deliverable is a coexistence design with routing diagrams and a batch plan your team can audit.
Cutover runbook and rollback
We write the cutover runbook with timed steps, owners, freeze windows, final delta sync and go/no-go checkpoints. A rollback plan defines the conditions for reverting mail routing and the data state at each step. The deliverable is an approved cutover runbook and rollback plan, rehearsed at least once in a non-production environment.
Post-cutover verification and handover
After cutover we verify mail flow, mailbox counts, calendar and contact integrity, and attachment access against the inventory, then hand over operational runbooks for daily tasks, incident response and migration close-out. The deliverable is a verification report signed off by your team and a set of operations runbooks your staff keep after the engagement ends.
What drives migration cost and duration
This table lists the factors that change the effort of an Open-Xchange migration, why each one matters and how to keep it under control before work is scoped.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Mailbox count and total data volume | Each mailbox adds extraction, transfer, verification and user follow-up, and total volume sets how long bulk copies run within the cutover window. | Inventory mailboxes and gigabytes per source platform, archive or purge stale accounts, and move historical mail in batches after cutover. |
| Attachment and file storage volume | PIM attachments and OX Drive files must land on the distributed file or object storage that OX App Suite v8 requires, so large attachment sets add transfer and sizing work. | Measure attachment totals per mailbox, deduplicate where the source allows it, and confirm target storage capacity before the first pilot batch. |
| Number and type of source systems | Each mail, calendar, contact or file source needs its own extraction method, mapping rules and test cycle, and mixed estates multiply that work. | List every source platform and instance, group them by export method, and retire or consolidate sources before scoping begins. |
| Calendar and contact format conversion | Recurring events, time zones, alarms, vCard fields and category labels often need translation, and conversion errors are only visible to users after migration. | Sample real calendars and contact books during planning, agree field mapping rules in writing, and define which data loss is acceptable. |
| Shared mailboxes and resources | Shared mailboxes, group calendars and room or equipment resources need owners, membership and access rights rebuilt on the target. | Export a list of shared objects with members and owners, assign a business owner to each one, and rebuild them in a pilot tenant first. |
| Delegation and permissions | Delegates, send-as rights and folder sharing are often undocumented, and missing grants generate support tickets in the first days after cutover. | Extract delegation and sharing settings from the source, confirm them with mailbox owners, and include a post-cutover check of each grant. |
| Custom folders and retention rules | Custom folder trees, filters and retention or archiving rules change how data is structured and must be mapped or replaced, not simply copied. | Document folder structures and rules per team, reduce custom rules to those the business still needs, and test one representative mailbox per pattern. |
| Number of environments to test in | Each test environment, from a pilot through staging to a production-like copy, repeats migration runs and verification, which increases elapsed time. | Agree the minimum set of environments in the written scope, and use the pilot to settle mapping issues before staging runs begin. |
| Compliance or legal hold requirements | Legal holds, journaling, audit trails and evidence of completed transfers require additional export logic, reconciliation and retained records. | Confirm the hold and retention obligations with legal and compliance owners before scoping, and ask for the evidence format each stakeholder expects. |
| Cutover window the business allows | A shorter window limits how much data can move during downtime, so more data must be synchronized in advance or coexistence must be planned. | Define the acceptable outage and the mail flow change in advance, and plan delta synchronization so the final cutover moves only recent changes. |
| Source version (7.10 or another platform) | Moving from OX App Suite 7.10 to the Kubernetes-based v8 differs from moving from another mail platform, because schema, data stores and client settings are not the same. | Confirm the exact source version and extension set, then ask for a migration approach that states which path applies. Confirm version details with Open-Xchange documentation and your own environment. |
Migration phases and what each one produces
The sequence moves mailboxes, calendars and contacts in controlled passes, so each phase closes with evidence that the next one can rely on.
Discover and inventory the source estate
DeployOpen reviews the source mail platform, directories, mailbox sizes, calendars, shared resources, delegations, public folders and integrations that send or receive mail. The client's messaging owner confirms the inventory. It closes with an inventory report that lists every data type in scope and the open questions that block planning.
Design the target environment
The team sets the target OX App Suite design: the v8 Kubernetes platform, identity and provisioning approach, the storage and database layout, mapping of folders, calendars and contacts to OX structures, and the migration tooling. It closes with a signed-off target design document and a list of decisions the client owns.
Run a pilot with a test set of mailboxes
A small, agreed set of test mailboxes covering typical and unusual data is migrated into a non-production target. Users and the client's administrators check mail, calendar series, contacts, shared items and attachments. It closes with a pilot report listing defects, fixes and changes to the migration runbook.
Execute full test runs with reconciliation
Complete migration runs are repeated against a copy of the production source until results are stable. Each run is reconciled by comparing item counts, folder structures and sample content between source and target. Every run produces a reconciliation report, and the final accepted run becomes the baseline for cutover.
Set up coexistence and mail routing
Where users move in groups, mail routing, free/busy lookup, directory entries and any transport rules are configured so that mail reaches the correct platform during the transition. The team tests delivery in both directions. It closes with a routing test record and an updated mail flow diagram that the client's operations team approves.
Cut over and provide hypercare
The production cutover follows a signed-off runbook with a final delta sync, DNS and routing changes, and a rollback point. After cutover, the team watches delivery, login, client connections and support tickets for an agreed period. It closes with a cutover record and a hypercare exit report.
Decommission the source platform
Once the client confirms that the target is the system of record and retention obligations are met, the source is archived or switched off in line with the client's data retention policy. Access and licenses are removed. It closes with a decommissioning record that confirms what was retained, where and for how long.
What teams keep in-house and what they outsource
This table compares, for each part of an Open-Xchange migration, what teams usually keep in-house, what they commonly hand to a partner and which skills the work requires, so you can see where your own gaps are.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Mail flow and DNS ownership | Final MX, SPF, DKIM and DMARC changes, and approval of any mail routing change | Drafting the DNS change plan, lowering TTLs ahead of cutover and testing mail flow in staging | Mail routing, DNS administration, email authentication records |
| User communication | Approving messages, choosing the cutover window and sending notices to staff and external contacts | Drafting user guides, FAQs and login instructions for the new OX App Suite client | Internal change communication, plain-language writing, service desk coordination |
| Source platform administration | Export rights, admin accounts and the knowledge of quirks in the current mail platform | Running export jobs, validating source data and documenting the source configuration | Administration of the current mail platform, its directory and its retention rules |
| Data mapping and conversion | Deciding which mailboxes, folders, calendars, contacts and shared resources move, and what to archive | Mapping source fields to OX objects, writing conversion scripts and running test migrations | Mailbox formats, calendar and contact data models, scripting, data quality checks |
| Kubernetes and Istio platform operation | Cluster ownership, node capacity, change control and access policies for the target platform | Helm chart configuration, Istio setup, upgrades and troubleshooting during the migration window | Kubernetes, Helm 3.17.0 or newer, Istio, ingress and network policy operation |
| MariaDB and storage operation | Database and storage ownership, backup policy and capacity decisions for mailbox and attachment data | Schema setup on MariaDB with InnoDB, Galera configuration and sizing of the file or object store | MariaDB administration, Galera clustering, NFS or object storage operation |
| Identity integration | Directory ownership, account lifecycle rules and decisions on who may sign in | Configuring OpenID Connect or SAML login and provisioning users and contexts from the directory | Directory services, OIDC and SAML configuration, provisioning logic |
| Cutover execution and rollback | Go and no-go decisions, sign-off on rollback triggers and business hours coverage | Writing the runbook, rehearsing cutover steps and executing the delta sync and switchover | Migration runbooks, change management, incident response, rollback testing |
| Post-cutover support | Helpdesk ownership, user escalations and assessment of how well the platform meets business needs | Hypercare monitoring, defect triage, patching within the support window and handover documentation | Service operations, monitoring, OX release tracking, support ticket handling |
What usually goes wrong and how to prevent it
Most OX App Suite mail migrations fail in predictable places: the source data was never fully inventoried, conversion altered items users rely on, or the cutover could not be reversed. Each card names one failure pattern and the step to complete before cutover.
Incomplete source inventory
Mailbox lists exported from the directory often leave out shared mailboxes, room and equipment resources, distribution lists and delegated access. Build the inventory from the source platform's own mailbox and resource reports, then reconcile it against the directory. Assign each shared mailbox an owner and a target account before the first pilot batch.
Calendar invitations and recurring events
Invitations, meeting responses and recurring series can change shape when items are converted, so attendees may see duplicates, lost exceptions or responses that no longer match the organizer's event. Pilot a set of users with recurring meetings, external invitations and resource bookings, then compare the calendars on both sides before approving the full run.
Contact duplicates and merge rules
Contacts held in personal address books, shared directories and mailbox folders usually overlap, so a naive import produces duplicates that users then have to clean up by hand. Decide in advance which source wins for each field, whether matching uses email address or display name, and how shared contact folders are mapped. Test the rules on a copy of a real mailbox.
Attachment storage not sized for the file layer
PIM attachments and OX Drive files must sit on the distributed file system the deployment is built on, and migrated attachments can add more volume than the source mailboxes suggest once conversion is complete. Calculate the expected attachment footprint from the source export, confirm the NFS or object storage capacity and I/O headroom, and check quotas before loading any user data.
Identity mismatch between directory and login path
Users who authenticate with one identifier in the source directory may be expected to sign in with another in the OX login path, which causes failed logins, duplicate accounts or mail delivered to an unclaimed context. Map every source identity to its target login name, verify the SSO attribute values for a sample of users, and confirm how the identity provider handles aliases before cutover.
Cutover without tested coexistence or rollback
Changing MX or DNS records before coexistence has been tested can route live mail to a platform that is not ready, and a cutover with no written reversal path leaves the team improvising under pressure. Test mail flow for pilot users with the records unchanged, document the MX, DNS and client steps, and rehearse the reversal once with the same change window and owners.
How the work differs by starting point
This path moves an existing OX App Suite 7.10 installation onto the Kubernetes-based v8 platform. The data already follows OX conventions, so the main work is mapping the old deployment to v8 components and proving that the new stack reads the same contexts, mailboxes and files.
- Data mapping: Confirm which 7.10 database schemas, file store locations and PIM attachments the v8 upgrade path carries over, and which need a separate step.
- Coexistence: Decide whether the old and new platforms share a database or file store during the transition, and confirm the supported arrangement for your version pair.
- Storage design: v8 expects persistent data such as OX Drive files and PIM attachments on a distributed file system or object storage, so plan that layer before any data moves.
- Identity: Check how existing login settings, session rules and directory links map to the v8 SSO configuration.
- Cutover: Confirm the supported upgrade order, the rollback point and the Helm chart version that matches your target release.
This path moves mailboxes, calendars and contacts from a commercial or open-source mail platform into OX App Suite. The source system is not an OX system, so data mapping and identity work carry most of the risk.
- Data mapping: Inventory the source formats for mail, folders, calendars and contacts, then define how each object type maps to OX objects. Test with a sample of mailboxes before any bulk run.
- Coexistence: Plan mail routing so that mail for migrated and unmigrated users reaches the right system during the transition, and confirm how folder and flag state is preserved.
- Storage design: Size the mail and attachment volume from the source export, and place attachments on the distributed storage that the v8 documentation requires.
- Identity: Map source accounts to OX users and contexts, and decide how passwords and SSO links are re-established.
- Cutover: Set a freeze window, run a final delta sync and confirm with Open-Xchange and your migration tool vendor which migration method they support for your source and target versions.
This path deploys OX App Suite into a network with no direct internet access or with strict egress controls. The platform itself does not change, but every chart, image and dependency must reach the cluster through a path you approve.
- Artifact delivery: Confirm which Helm charts, container images, Redis operator components and Istio images the v8 deployment needs, and build an internal registry and chart repository for them.
- Data mapping: Keep data transfer inside the boundary. Confirm the approved media or transfer method for any migrated data, and validate checksums on arrival.
- Coexistence: Plan routing and directory sync within the controlled network. Confirm whether any component needs external lookups, such as license checks, before go-live.
- Storage design: Use the NFS or object storage platform that your environment already governs, and confirm its supported versions with Open-Xchange.
- Identity and cutover: Connect OX to your internal identity provider, and schedule cutover inside approved change windows with a rollback plan that does not depend on external services.
What you need to provide
Most of the schedule for an Open-Xchange migration depends on what you hand over before the first pilot batch runs. Read or export access to the source platform comes first, because every mailbox, calendar and contact move depends on it. Confirm with your current mail administrator which export method is available, whether it reads the store directly or through IMAP or an export tool, and who can grant a service account with read rights. Without that access, the team cannot measure the source or test a single batch.
A current mailbox and resource inventory and sizing data for mailboxes and attachments turn the migration into a plan. Ask for mailbox counts, shared mailboxes, room and equipment resources, calendar delegations, and the largest mailboxes and attachment volumes. These figures drive batch sizing, the time each wave takes, and the storage that the distributed file or object layer must hold for OX Drive files and PIM attachments. Missing sizing data is the most common reason a cutover window gets extended.
The target Kubernetes cluster and storage platform must already exist and pass the checks from the prerequisite projects, including the Istio ingress, MariaDB, Redis and the distributed storage. Migrating into an unverified platform moves the risk of data loss into the cutover itself. You also need DNS and certificate control for the mail and web hostnames, so that MX, autodiscover and TLS changes can be made on a known schedule and reversed if needed. Confirm who can change those records and how long they take to propagate in your environment.
Identity matters because users must sign in on the target. Provide identity provider access for the login design, including the OpenID Connect or SAML configuration and a test tenant, so that accounts and contexts can be provisioned before users arrive.
Name owners for mail flow, cutover approval and user communication. Each owner should be a person, not a team alias, with authority to pause the migration. Also fix a cutover window that your business has agreed to, and a rollback decision owner who can declare a rollback within that window. Without a named rollback owner, a failed batch can stay half-moved, which is where mail loss and duplicate items usually begin.
Frequently asked questions
What drives the cost and duration of moving mail to OX App Suite?
The source platform, the data volume and the target design drive most of the cost and duration. The source system determines how hard it is to extract mailboxes, calendars and contacts, while the number of mailboxes, total data size and attachment volume set the transfer effort. On the target side, the OX App Suite v8 prerequisites (Kubernetes, Istio, Redis, MariaDB and distributed storage for files and attachments) must be ready before data moves. Ask for a quote that separates platform prerequisites, data migration, cutover support and testing, and marks each item as one-time or recurring. The scope is agreed in writing before work starts.
Can a small IT team run an OX App Suite migration without a partner?
A small team can often handle parts of a migration itself, but the answer depends on existing skills and tolerance for risk. Teams already comfortable with Kubernetes, Helm, MariaDB and mail protocols can manage a pilot group and a phased rollout with good documentation. The hardest parts are usually source extraction, the coexistence period, identity integration and the cutover window, where a mistake affects every user at once. Ask for a scoped option that covers only the work your team cannot staff, and decide in advance which parts you will own after handover. DeployOpen plans and implements these migrations inside your infrastructure under a written scope.
What does an OX App Suite migration need from our internal staff?
Your staff must provide access, decisions and knowledge of the current mail system. Typical inputs include administrator access to the source platform, the directory that holds users, groups and aliases, control of DNS and certificates, and a named owner who approves the cutover. Users and mailbox owners need a communication plan and a list of shared mailboxes and resources. Someone in the business must also validate migrated data, because only the owners can confirm that a folder, calendar or contact set is complete. Ask the scoping process to list each input with an owner so approvals do not stall the work.
How does coexistence let us move users without a hard cutover?
Coexistence keeps the old and new platforms running side by side while mailboxes move in groups, so users are not all switched on the same night. Mail for migrated users is routed to the new system, unmigrated users stay on the source, and folders and calendars are synchronized during the overlap. Free/busy lookups and mail routing between the two systems need planning, because a user on one platform must still see colleagues on the other. The exact method depends on the source platform and its connector options, so confirm it during scoping. Coexistence adds moving parts, which is why the plan states what runs where at each stage.
What happens if a mailbox cutover fails partway through?
A failed cutover is handled by a rollback plan agreed before the cutover window opens. The plan returns affected users to the source platform and names the trigger conditions, such as mismatched item counts, failed logins or broken mail flow, along with the person who makes the rollback decision. Keep the source system readable until the cutover is accepted, and retain migration logs and reconciliation reports so partial moves can be traced and corrected. No one can promise a cutover will go to plan, but the written scope can include a rehearsal, a go/no-go checklist and a defined rollback path. Ask how the rollback works for each batch of users.
Does an OX App Suite migration include SSO and high availability setup?
Single sign-on and high availability are often part of a migration plan, but inclusion depends on the scope you sign. OX App Suite supports single sign-on through OpenID Connect, and SAML login is documented for the middleware, so identity integration can be scoped alongside the mail move. High availability for v8 involves multiple replicas on Kubernetes, MariaDB Galera, Redis and distributed storage, which adds build and test effort beyond the data move. Name both explicitly in the scope and ask for failover testing to be listed as a deliverable. Identity and availability work change the cutover plan, so settle them before the migration schedule is set.
How DeployOpen delivers OX App Suite migrations
DeployOpen plans, builds and hands over Open-Xchange migrations inside infrastructure you control, from the current mail platform or an OX App Suite 7.10 installation to a Kubernetes-based v8 platform. Each step is scoped in writing before work starts, so cutover and coexistence decisions are made before any mailbox moves.
How we scope
- The written scope lists the source platform, mailbox, calendar and contact volumes, and the target OX App Suite v8 environment.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Scope names the coexistence period, cutover approach and which user groups move in each wave.
How we build
- Target platform prerequisites are set out first: Kubernetes, Helm 3.17.0 or newer, Istio or ingress-nginx, Redis 7.4.x and MariaDB with InnoDB.
- Persistent OX Drive files and PIM attachments are planned on a distributed file system or object storage before data is loaded.
- Migration runs are rehearsed in a non-production environment, and results are checked against the agreed acceptance criteria.
How we hand over
- Handover includes runbooks for cutover, rollback, user communication and post-migration verification in your environment.
- Configuration, Helm values and migration tooling are documented so your own operators can repeat or audit the work.
- Open items, known gaps and any licensing or module conditions are recorded in the handover pack, so you can confirm them with Open-Xchange.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Post-migration support can cover mailbox issues, coexistence clean-up and decommissioning of the source platform.
- Upgrade planning follows the Open-Xchange support commitment, so the platform stays inside a supported release window.
