Migrate from Microsoft Exchange to OX App Suite: what the move involves
Moving mailboxes, calendars and contacts from Exchange to OX App Suite is a planned project, not a file copy. It is usually triggered by a renewal, a licensing change, a data residency requirement or a wish to reduce lock-in, and the target is a Kubernetes-hosted platform in your own infrastructure. The work is normally carried out by your platform team with an implementation partner, who handles the Helm deployment, the MariaDB, Redis and distributed storage layers, identity integration and the migration tooling. Effort and risk depend less on mailbox volume than on how many users rely on shared calendars, delegates, resource bookings, public folders and mobile devices, and on how much of the Exchange estate is custom. Ask the partner for a written inventory of those dependencies before agreeing on scope.
IMAP alone does not carry calendars and contacts. Mail moves over IMAP, but calendar events and address books need a separate path, typically CalDAV and CardDAV on the OX side and a converted export from Exchange, so confirm early which items your users depend on and test each one with a pilot group. Client support is the other decision point. Outlook connects to OX App Suite through its Exchange ActiveSync connector or IMAP with CalDAV, and the trade-offs in shared calendars and delegate access should be tested before any user is moved. For timing, Exchange Server Subscription Edition reached general availability on July 1, 2025 under the Modern Lifecycle Policy, while Exchange Server 2019 extended support ended in October 2025. Those dates explain why many organizations are planning now, but they do not set your cutover date.
Plan coexistence before cutover. Mail flow between Exchange and OX App Suite, free/busy lookups across both systems and shared mailboxes all need a decision, and each one can break silently if it is not tested. Agree a rollback point for each migration wave, keep Exchange read-only for a defined period, and confirm retention and legal hold requirements with your compliance team, since those obligations often outlast the migration itself. Ask your partner to document the cutover runbook and the validation checks, and confirm the OX App Suite release and support window you are standardizing on, using the OX App Suite requirements as the starting point for platform prerequisites.
Which Exchange capabilities map cleanly to OX App Suite and which need rework
This table compares the main Exchange capabilities that organizations rely on with their OX App Suite equivalents, and labels each as clean, needs rework or gap. Mail folders usually carry over through standard protocols, while calendars, contacts, delegates and Outlook behavior need separate checks. Confirm Outlook, shared mailbox and delegate behavior in your own test tenant before you set a cutover date.
| Capability | Exchange side | OX App Suite side | Status |
|---|---|---|---|
| Mail storage and folders | Mailboxes and folders accessed by Outlook and mobile clients | Mail stored in Dovecot-backed IMAP folders; Dovecot is part of the Open-Xchange product line | Clean |
| Calendars | Personal and shared calendars, free/busy and meeting invitations | Calendar data needs CalDAV or an export path, since IMAP alone leaves calendars behind. Confirm invitation and free/busy behavior | Needs rework |
| Contacts | Personal contacts and the global address list | Contacts need their own export and import path. Confirm the contact protocols your release supports | Needs rework |
| Shared mailboxes and delegates | Shared mailboxes, Send As, Send on Behalf and calendar delegates | Confirm whether shared mailbox and delegate permissions match your needs before planning manual access grants | Gap |
| Outlook connectivity | Outlook connects through Exchange-native protocols and Autodiscover | Confirm which Outlook connection modes your release supports, then plan profile changes for every user | Needs rework |
| Mobile sync | Phones sync mail, calendar and contacts through ActiveSync | The Exchange ActiveSync connector is available for OX App Suite. Confirm device coverage and policy support | Needs rework |
| Archive and eDiscovery-style retention | In-place archives and Purview exports to PST or .msg, requiring E3 or E5 licensing | No direct equivalent is assumed. Export PST or .msg files before cutover; Purview search exports expire 14 days after creation | Gap |
| Identity sign-in | Sign-in through Entra ID or on-premises Active Directory | OpenID Connect and SAML login are documented for OX App Suite. Confirm the flow that matches your directory | Needs rework |
What data can be exported from Exchange and what must be rebuilt
Mailboxes are only part of an Exchange move. Some data has a documented export path, while mail routing, directory sync, single sign-on and device policies have to be designed and rebuilt on the OX App Suite side. Treat each card as a checklist item to confirm before the cutover plan is signed off.
Mailbox export to PST
On-premises Exchange Server mailboxes can be exported to PST files with the built-in mailbox export tooling, and those PST files can then be imported into a target mailbox store. PST is a container format, so message properties, folder structure and item metadata depend on the export and import path you choose. Confirm with your own test mailboxes that flags, categories, read state and attachments survive the round trip before you commit to bulk export.
Purview eDiscovery exports
Microsoft Purview eDiscovery can export Exchange mailbox items as PST or .msg files, and SharePoint and OneDrive content as native documents with selectable version history. Exporting requires a Microsoft 365 E3 or E5 license, so check your entitlements before planning. Search export packages expire 14 days after creation, which means a large export must be downloaded and staged on your own storage within that window.
Exchange Online export options
Exchange Online mailboxes can be exported through eDiscovery or through PST export tooling administered by your Microsoft 365 tenant. Exporting is a tenant administration task, so the people running it need the right roles and your legal and records team should approve what leaves the tenant. Ask Microsoft or your tenant administrator to confirm the current export methods and any licensing conditions for your tenant before you depend on them.
SMTP relays and journaling
Applications, scanners and line-of-business systems often send mail through an Exchange SMTP relay, and compliance journaling may copy every message to an archive. Neither is moved by a mailbox export. Inventory each sending system, its relay address and allowed senders, and any journal rule, then define the equivalent submission and archiving path on OX App Suite and your mail transfer agents before cutover.
Directory sync and single sign-on
Exchange usually depends on Active Directory or Entra ID for user identity, group membership and address lookups. OX App Suite needs its own user and group provisioning, plus a login path. Plan the directory source, the attribute mapping and the sign-on method, which can use OpenID Connect or SAML, and test the login flow with the identity team before users are moved.
Mobile device policies
Exchange ActiveSync policies control passcodes, encryption, remote wipe and app restrictions on phones and tablets, and those policies do not transfer automatically. List the policies in force, decide which controls OX App Suite and your mobile management tool will enforce, and confirm which device clients connect before you retire the Exchange policy set.
Why IMAP alone leaves calendars and contacts behind
IMAP moves mail folders and messages, but it does not carry calendar objects, contact books or delegate permissions. An Exchange mailbox holds all of these in the same store, so a migration that only copies mail over IMAP will deliver an inbox with no calendar and no address book. Plan calendars and contacts as separate workstreams from the start. In OX App Suite, calendar and contact data is handled through its groupware layer rather than the mail protocol, and the import path for each object type needs to be confirmed with Open-Xchange and tested against your own export files. Ask the platform team to confirm which CalDAV and CardDAV endpoints are enabled for your deployment and which clients they serve.
Before cutover, verify item counts per user for mail, calendar items and contacts, comparing the Exchange export against what lands in OX App Suite. Counts alone can hide damage, so also check recurring events. Pick a sample of users with series that have exceptions, cancelled occurrences, time zone definitions and attendee responses, and confirm each occurrence and exception appears correctly after import. Check that shared calendars and delegate rights were either recreated or documented for manual reassignment, because these do not come across with mail. Keep the source data available until the sample checks pass for every department.
Put these questions to the platform team and the migration vendor in writing: which exact export format is used for calendars and contacts, how time zones and recurrence rules are preserved, how attachments on calendar items are handled, and what the reconciliation report looks like for each user. Ask how the team will confirm that contact photos, categories and distribution lists survive the import. If any of these answers depends on a module or feature, confirm with Open-Xchange whether it is included in your license, since the Operations Guide notes that certain features may be subject to separate terms.
Migration sequence from inventory to Exchange decommission
This sequence moves mail, calendars and contacts from Exchange to OX App Suite in controlled stages, so each stage has a written output and a rollback point before the next one starts. Each step names what it produces, which lets the migration team and the business owners sign off before any user's mail is routed to the new platform.
Build the inventory register
Start by listing every mailbox, shared mailbox, room and equipment resource, distribution group, public folder, and online or in-place archive in the Exchange organization. For each object, record its owner, size, item count, delegates, permissions, calendar sharing, and whether it is subject to retention or legal hold. Export the object list from Exchange Management Shell or Exchange Online PowerShell and reconcile it with the directory. The step is done when the inventory register has been signed by the mail owner and each object has a target account in OX App Suite or an explicit decision to archive or drop it.
Confirm the target platform and identity
Deploy the OX App Suite v8 test environment on Kubernetes using the Helm charts, confirm the required Helm, Istio or ingress-nginx, Redis and MariaDB components, and the distributed file system for attachments and files. Decide how users will sign in, whether through OpenID Connect or SAML, and map the directory attributes that drive mailbox provisioning. The step is done when a test account signs in, sends and receives mail, and shows a calendar entry, and the platform team has a written record of the component versions in use.
Run the pilot with a small group
Choose a small group of users who represent the main client types in use, including Outlook users if Outlook will be kept, mobile users, and at least one user who relies on delegates or shared calendars. Migrate their mailboxes, calendars and contacts using the export and sync method approved in the design, then test the open items list against the agreed acceptance criteria. Record any gaps, such as calendar invitations that do not update, delegate access that fails, or contacts that do not sync. The step is done when the pilot acceptance record shows each criterion as passed, failed with a fix scheduled, or accepted as a known limitation by the business owner.
Set up coexistence and free-busy routing
Configure mail routing so that mail for migrated users reaches OX App Suite while unmigrated users remain on Exchange. Plan how free-busy information will be shared between the two systems, because scheduling across the boundary depends on it, and test it with pilot users and users still on Exchange. Confirm how the Outlook client options chosen in the design behave during this period, including what happens to shared calendars and delegate permissions. The step is done when a test matrix of sender and recipient combinations passes and the coexistence runbook has been approved by the messaging and security teams.
Execute the parallel run and wave migrations
Move the remaining users in waves, keeping the Exchange environment available so that each wave can be reversed. After each wave, compare item counts and folder structures against the inventory register, check delta syncs for mail that arrived during the move, and collect help desk tickets. Keep a log of exceptions for each wave. The step is done when every wave has a reconciliation report and no open exception blocks the cutover of the final wave.
Cut over DNS and MX records
Plan the final change to mail routing, including the MX records, the autodiscover and client endpoints, SPF, DKIM and DMARC entries for the new sending path, and any connector or relay that sends mail for applications and scanners. Lower the DNS record time-to-live in advance, following the guidance from the DNS provider, and agree a change window with the business. Execute the change from a written cutover runbook that lists each record, its old and new value, the validation command, and the rollback command. The step is done when inbound and outbound test messages pass, the runbook is signed, and the old Exchange routing has been confirmed as no longer used.
Decommission Exchange with retention and legal hold confirmed
Before shutting down any Exchange server or tenant, confirm with legal and records teams which mailboxes, archives and public folders are under retention or legal hold, and how they will be preserved in the target environment or in an export. Export any data that must be kept, verify the export with a sample restore, and document where it is stored and who can access it. Only then remove licenses, mailbox databases and servers, and revoke the connectors and service accounts that Exchange used. Ask your licensing advisor to confirm the end date for any Exchange subscription or support contract. The step is done when the decommission record lists the retained data locations, the verified exports, and the signed approval from the legal and records owners.
What drives migration cost and duration
This table lists the cost components of moving from Exchange to self-hosted OX App Suite, who is paid for each, and whether it is one-time or recurring. Use it to frame a written scope and ask each vendor or partner for line-item quotes, since no fixed prices or durations are given here.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Kubernetes platform build with Istio or ingress-nginx | Internal platform team or implementation partner | One-time build, then recurring operations | Cluster count, Kubernetes version support (N-1 and N-2), and whether Istio is used or the basic ingress-nginx option applies |
| Redis 7.4.x and MariaDB database services | Infrastructure or DBA staff, or managed database provider | Recurring hosting, one-time configuration | Choice of unmanaged or operator-managed Redis, MariaDB version (10.6.x, 10.11.x, 11.4.x or 11.8.x) and whether Galera Cluster is needed |
| Distributed file storage for OX Drive and attachments | Storage vendor or cloud provider | Recurring capacity and operations | Mailbox volume and attachment history, NFS for smaller deployments or object storage such as S3, Ceph RadosGW or Scality RING for larger ones |
| Support subscription from Open-Xchange | Open-Xchange, or a partner that resells support | Recurring | Standard release support window versus LTS support, and the service level chosen in the license agreement |
| Migration tooling and data export | Implementation partner or internal engineers | One-time per migration wave | Source platform (on-premises Exchange or Exchange Online), mailbox count, archive and shared mailbox handling, and throughput of the sync method chosen |
| Client work and Outlook connectivity | Internal desktop team or implementation partner | One-time, plus support for new devices | Client mix (Outlook, mobile, web), whether ActiveSync or IMAP with CalDAV is used, and how many users rely on shared calendars and delegates |
| Identity integration and directory work | Identity team or implementation partner | One-time build, then recurring maintenance | Existing directory, SSO design using OpenID Connect or SAML, and how many user lifecycle processes must change |
| Compliance evidence and training | Internal compliance team, auditors and training providers | One-time evidence set, then recurring review | Regulatory scope, retention and eDiscovery requirements, and how much administrator and user training the cutover needs |
What the OX App Suite v8 platform needs before any mail moves
Before any mailbox is copied, the target platform has to exist and match the version you plan to run through cutover. OX App Suite v8 is designed to run on a Kubernetes cluster and is delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. Kubernetes support covers the N-1 and N-2 releases, so confirm the cluster version against the OX App Suite requirements before the platform team commits to a build. The stack also requires Istio, supporting the latest Istio release plus two prior versions. Where Istio cannot be used, a basic ingress-nginx option exists, and that choice changes your traffic and certificate design, so decide it early.
The data tier has fixed components. Redis 7.4.x handles caching and session storage and is deployed by default through the littlered operator, with unmanaged or custom Redis configurable. The primary store is MariaDB with the InnoDB engine, using versions 10.6.x, 10.11.x, 11.4.x or 11.8.x, and Galera Cluster is supported. 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. Confirm the storage choice with your storage team, because attachment volume and backup scope follow from it.
Plan the version you will run at cutover against Open-Xchange's support commitment. A standard release is supported for 12 weeks, ending with the availability of the third following release, so a standard build can fall out of support during a long migration. An LTS release is supported until the next LTS release plus six months. The v8.35 LTS is discontinued, and v8.47 is the current LTS, so most regulated buyers should pin to an LTS line and schedule upgrades around its end date. Ask Open-Xchange which LTS line matches your cutover window and confirm the dates for that line in writing.
What usually goes wrong and how to prevent it
Most failed Exchange-to-OX moves do not fail on mail delivery. They fail on the items that IMAP does not carry and on the permissions and retention settings that users never see until something breaks. Each card below names one risk, the prevention step and the check to run before cutover.
Calendar and recurring-meeting loss
IMAP moves messages but does not carry calendar objects, so recurring meetings, invitations and attendee responses can disappear or arrive as plain mail. Plan a separate CalDAV or PST-based calendar path and test a recurring series with exceptions. Before cutover, confirm that a meeting created in Outlook on the old server shows the same occurrences, attendees and responses on the new server. Test recurring series with exceptions in every migrated calendar.
Delegates and shared mailbox permissions
Delegate access, send-as rights and shared mailboxes are defined in Exchange and do not transfer with message data. Inventory every shared mailbox, delegate and resource calendar on the source, then recreate each grant in OX App Suite and record who holds it. Confirm with the OX administrator how shared folders and delegation are configured in your version, since the feature set depends on the client path you choose.
Outlook profile reconfiguration
Outlook profiles point at Exchange endpoints, and users who keep Outlook need a new account definition on each workstation. Decide before the pilot whether users will connect over IMAP with CalDAV, over an Exchange ActiveSync connector, or through another supported path, because each has different support for calendars and folders. Pilot the chosen profile on a few workstations and document the exact steps for the service desk.
Mail flow loops during coexistence
While some users sit on Exchange and others on OX App Suite, routing rules, smart hosts and accepted domains decide whether mail loops between the two systems. A forwarding rule or a connector that points back at the source can create a cycle that is hard to spot. Define one authoritative domain per recipient, set MX and routing changes in a documented order, and send test messages in both directions and through every relay before moving the first group.
eDiscovery and retention gaps
Legal holds, retention policies and Microsoft Purview eDiscovery searches run on the Exchange side and do not follow mailboxes to the new platform. Export or preserve the required data before the source is decommissioned, and confirm which system becomes the legal record for each period. Microsoft's own export packages expire 14 days after creation, so plan the export window and storage location in advance. Ask counsel to sign off on the retention scope before the source is switched off.
Unsupported license feature assumptions
Some Exchange features, such as specific compliance add-ons or advanced mobile policies, may have no equivalent in the target product, and some OX modules may be subject to custom packaging or separate fees set in the license agreement. Before cutover, list every feature your users rely on and ask Open-Xchange in writing which modules and connectors are covered by your license. Do not assume a feature exists until it is confirmed in your environment.
How the migration changes by starting point
Exchange Server on your own Windows hosts keeps mailboxes, calendars and contacts in databases you control, so the export runs inside your network. Active Directory usually defines users, groups and delegates, and those objects must be mapped to OX App Suite accounts before any mailbox moves. Export is typically done per mailbox to PST or through a server-side process, then imported into OX App Suite, with IMAP or a client connector handling ongoing access during the transition.
- Export method: Plan a per-mailbox export and confirm which mailboxes, archives and public folders are in scope, since these are often missed.
- Directory mapping: Decide how Active Directory identities map to OX App Suite users and whether sign-in will federate through your existing identity provider.
- Coexistence: Keep mail flow through Exchange until cutover, then switch the MX records and smart host settings in one planned window.
- Calendars and contacts: Verify that shared calendars, delegates and contact folders arrive intact, because IMAP alone does not carry them.
- Platform prerequisites: Confirm your Kubernetes, Istio, Redis and MariaDB plan against the OX App Suite v8 requirements before you export anything.
Confirm with your Exchange administrator which mailbox types and public folders exist, and with Open-Xchange which connector supports your Outlook clients.
Exchange Online stores mailboxes in Microsoft 365, so you cannot export through a server you operate. Export is usually performed through Microsoft tooling, and the output must be checked for completeness before it is imported. Retention, litigation holds and licensing affect what you can extract, so legal and compliance owners should be involved from the start. Coexistence commonly relies on mail forwarding or a staged period in which both platforms receive mail.
- Export tooling: Microsoft Purview eDiscovery can export mailbox items as PST or .msg files, but exporting requires a Microsoft 365 E3 or E5 license and export packages expire 14 days after creation.
- Holds and retention: Confirm which litigation holds or retention policies apply, since they can change what is exported and when mailboxes may be deleted.
- Forwarding: Decide whether mail is forwarded during the transition and how long the forwarding remains in place.
- Calendars and contacts: Check that recurring meetings, shared calendars and contact groups survive the export and import.
- Tenant changes: Confirm with Microsoft how any license removal or tenant change affects data access before cancelling subscriptions.
Confirm the current license entitlements and retention settings for each mailbox with your Microsoft 365 administrator before export starts.
Hybrid estates run some mailboxes on Exchange Server and others in Exchange Online, often with directory synchronization in place. The migration must treat each group separately, decide which side is the system of record for each user, and keep mail routing correct while both sides exist. Free/busy lookups and shared calendars across the two environments are the usual points of failure, so they need explicit testing.
- Batch planning: Group users into migration waves so that each wave's calendars and delegates move together.
- Routing: Define which domain or subdomain routes to which platform during coexistence, and test inbound and outbound mail for each wave.
- Free/busy: Confirm that availability information remains visible across the old and new platforms until the last wave completes.
- Directory sync: Decide whether directory synchronization continues to feed OX App Suite identities or is retired at a defined point.
- Rollback: Document how a wave is returned to its previous platform if a cutover fails.
Confirm the exact routing and free/busy behavior with a test mailbox in each direction before the first production wave.
Banks, healthcare providers and public bodies often need mailbox data, export logs and retention evidence to stay within defined boundaries. The migration therefore includes controls over where exports are stored, who can access them and how deletion is confirmed. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or certification. Retention and legal hold obligations should be settled before the source data is removed.
- Export storage: Keep PST files and export packages on storage you control, with access limited to named migration staff.
- Evidence: Record export counts, import results and exceptions so that auditors can review the migration.
- Retention: Confirm that retention schedules and legal holds are mapped to OX App Suite before source mailboxes are decommissioned.
- Identity: Plan authentication through your identity provider, using OpenID Connect or SAML as supported by OX App Suite.
- Certification: Ask your auditor which controls and evidence they expect, rather than assuming a standard applies.
Confirm with your compliance lead and auditor which evidence and retention controls apply to your sector before the first export.
Disconnected networks cannot reach cloud export tools or online package repositories, so every component, image and update must be brought in through an approved transfer process. The export itself usually runs from the existing on-premises Exchange server, and the import runs on an OX App Suite deployment inside the same enclosure. Mail relay, antivirus signature updates and licensing activation must be planned explicitly because none of them can rely on internet access.
- Transfer process: Define how exported PST files and Helm charts or container images enter the network, and who approves each transfer.
- Mail relay: Confirm how inbound and outbound mail reaches external partners through approved gateways.
- Updates: Plan antivirus and component updates through a controlled media process.
- Licensing: Ask Open-Xchange how license activation works without internet access and what the license agreement permits.
- Storage: Confirm that persistent data sits on a distributed file system that your environment supports, such as NFS or an object store.
Confirm the offline installation and licensing procedure with Open-Xchange and your security team before the transfer plan is approved.
Questions buyers ask before moving Exchange to OX App Suite
What does it cost to move from Exchange to OX App Suite?
The total depends on the components you pay for, and no single figure applies to every organization. Cost falls into four groups: the Kubernetes cluster and its supporting services (Istio or ingress-nginx, Redis, MariaDB and a distributed file system for mailbox and attachment data), the Open-Xchange subscription and any module fees set in your license agreement, the migration project itself, and internal staff time for operations. Infrastructure and licensing recur each year, while migration work is largely one-time. Ask each vendor and integrator for a quote that lists these lines separately, and ask which Exchange licensing (server, CALs, or Software Assurance) you can retire at cutover.
How long does an Exchange to OX App Suite migration take?
The timeline depends on mailbox count, total data volume, the number of shared calendars and delegates, how many clients must be reconfigured, and how much of the platform is new to your team. The supported Kubernetes, Istio, Redis and MariaDB versions also need to be set up and tested before any mailbox moves. Ask for a timeline in the written scope with milestones for a pilot group, a coexistence period and the final cutover. Treat any duration you hear before a scope review as a guess until you have measured your own mailbox sizes and data sources.
What do we need to provide for the migration?
The migration needs decisions and access from your side as much as technical work. Expect to provide a named sponsor, a list of mail domains and users, a directory source for accounts, access to Exchange or Exchange Online for export, a target cloud account or data center with capacity for the Kubernetes cluster, and storage that meets the distributed file system requirement for your deployment size. Your team should also agree the cutover window, the list of shared mailboxes and resources, and the communication plan for users. Confirm each of these in the scope document before work starts.
Can our in-house team run this migration without a partner?
Some teams can, but the answer depends on skills you already have. The platform runs on Kubernetes with Helm charts, requires Istio or a basic ingress-nginx option, and depends on Redis, MariaDB and a distributed file system. Your team also needs to handle client reconfiguration, calendar and contact checks, and coexistence with Exchange during cutover. Assess your Kubernetes, database and mail operations experience honestly. A fixed-scope engagement can cover planning, implementation and documentation, while a retainer can cover ongoing upgrades and support, so you can split the work by skill rather than all or nothing.
Which Outlook options work with OX App Suite?
Outlook support is the first thing to test, because not every Outlook feature maps to OX App Suite. Options typically include the Exchange ActiveSync connector for mobile and some desktop clients, and IMAP with CalDAV for calendars and contacts. IMAP alone moves mail but does not carry calendar and contact data, so plan a separate sync path for those. Test shared calendars, delegate access, out-of-office messages, and folder permissions with real users before cutover. Confirm each client path in writing with Open-Xchange and your integrator, since client support changes between releases.
What licensing terms should we check before we sign?
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. The App Suite UI and middleware are published on GitHub under AGPL-3.0, but that does not settle which modules, connectors or support tiers your deployment needs. Ask which modules your use case requires, whether any are priced separately, what the support commitment covers, and how long each release line is supported. Check the Long Term Support terms, since an LTS release is supported until the next LTS release plus six months. Have your legal team review the agreement before purchase.
How do we scope a fixed-scope engagement for this migration?
A fixed-scope engagement starts with a written scope that defines deliverables, timelines and responsibilities before work starts. Ask for a scope that covers the platform design for your environment, the Kubernetes and storage setup, the mailbox, calendar and contact migration method, the Outlook client plan, a pilot group, coexistence rules during cutover, backup and upgrade procedures, and documentation handover. Each item should name who does what, what evidence is delivered, and what happens if the source data is larger or messier than expected. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and it prepares evidence for compliance assessments without issuing audit reports. Ask for a quote that follows from this written scope.
How the migration scope is agreed before work starts
Before any mailbox moves, DeployOpen agrees the scope, deliverables and timelines with you in writing. Most engagements are fixed-scope, so the written agreement is what defines the work: which Exchange mailboxes, shared mailboxes, resource calendars and public folders are in scope, how many Dovecot and OX App Suite environments are built, and which cutover and rollback steps are included. Ongoing support, upgrades and continuous testing after cutover are offered as separate retainers, so the migration agreement should end clearly at handover.
Several inputs decide how accurate that scope can be, and you supply them. Provide tenant or server access for the Exchange environment (Exchange Online administration or Exchange Server management shell access), an inventory of mailboxes with sizes, archive mailboxes, distribution lists, delegates and shared calendars, and the Kubernetes and storage platform where OX App Suite will run. Name one decision owner per business unit who can accept or reject calendar and contact mappings, and who signs off on retention and legal hold questions before any data moves.
Test users matter as much as the inventory. Ask for a small group across mail clients, including people who rely on Outlook, mobile devices and delegated calendars, and agree in advance which tests they run: sending and receiving, free/busy lookups, meeting invitations, contact sync and attachment access. Confirm with DeployOpen which of these paths the agreed scope covers, since Outlook connectivity options differ and are described elsewhere on this page. Any hypothetical timeline you receive before this step is illustrative until the written scope fixes it.
How DeployOpen plans, runs and supports the Exchange migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted OX App Suite inside your own cloud accounts, data centers or air-gapped networks. Engagements start with a written scope covering mailboxes, calendars, contacts and the coexistence period before any migration work begins.
How we scope
- Inventory mailboxes, shared mailboxes, calendars, contacts and archives across Exchange Server or Exchange Online.
- Record which clients, mobile devices and Outlook versions staff use, and which of them must keep working during cutover.
- Agree deliverables, timelines and acceptance tests in writing before any work starts, since most engagements are fixed-scope.
How we build
- Plan the OX App Suite v8 Kubernetes footprint, including Helm charts, Istio or ingress-nginx, Redis, MariaDB and the distributed file system for attachments.
- Build and test the export, import and sync jobs for calendars and contacts, since IMAP alone does not carry them over.
- Run test migrations on sample mailboxes and check folder structure, delegates, shared calendars and attachment integrity before production runs.
How we hand over
- Document the target architecture, runbooks, cutover steps, rollback steps and the coexistence routing between old and new mail flow.
- Walk your administrators through user provisioning, mail flow, backups and Open-Xchange release upgrades, and record the results.
- Deliver the configuration and evidence your internal team and any independent auditor will need, noting that DeployOpen prepares evidence but does not issue audit reports.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the migration closes.
- Plan upgrades around the Open-Xchange support commitment, including standard release windows and LTS timing, so your team knows when to move.
- Confirm with Open-Xchange which modules, features and client connectors your license covers before you commit to a design.
