Can you replace Exchange and still keep Outlook for every user?
If a renewal, licensing change or residency rule forces you off Exchange but a share of your users depend on Outlook desktop features, the deciding factor is which open-source server speaks the protocols Outlook actually uses. grommunio is the option that implements MAPI/HTTP, RPC/HTTP and Exchange Web Services, so native Outlook connections are the design goal rather than a workaround. OX App Suite takes a different route: it connects mobile clients through Exchange ActiveSync and offers IMAP with CalDAV, so Outlook behavior depends on which connector your users run. Treat the two options as different Outlook experiences, not as interchangeable ones.
Timing matters for this decision. Exchange Server 2019 reached the end of extended support in October 2025, and Microsoft points customers to Exchange Server Subscription Edition or Exchange Online. If your environment still runs 2019, plan the Outlook test against your real client mix now, because a test that finds a gap leaves little room for a rushed cutover. Confirm with your Microsoft account team which Outlook builds your users run and whether your organization has any licensing constraints that shape the exit path.
Before you commit, run a pilot with a representative group. Include users who rely on shared calendars, delegate access to another mailbox, and send-on-behalf. Test Outlook's free/busy lookups, meeting responses across organizations, and calendar publishing, and confirm each against the grommunio documentation and the OX App Suite requirements for your version. Record which features work natively, which need a workaround, and which are missing. Ask each vendor, in writing, for the Outlook versions and protocol behavior they support and for their known limitations, so the gaps you find in testing are documented before the migration plan is signed off.
What keeping Outlook requires from the replacement
Outlook does not talk to a mail server in one way. Desktop clients, mobile devices and shared calendars each depend on a specific protocol, directory and data layout, so a replacement must match all of them. The cards below set out what to verify in your own Outlook builds before you commit to a migration.
MAPI/HTTP and RPC/HTTP access
Current Outlook for Windows connects to Exchange-compatible servers over MAPI/HTTP, while older builds and some Outlook Anywhere setups use RPC/HTTP. grommunio's Gromox server documents both, so the protocol list is a starting point, not proof. Confirm which transport your Outlook build and autodiscover settings use, and test a clean profile on each supported Windows client version, including the Outlook for Windows build your fleet actually runs.
EWS and Exchange ActiveSync
Exchange Web Services and Exchange ActiveSync are used by add-ins, Outlook features and native phone mail apps. grommunio states that its FAQ covers MAPI/HTTP, EWS and ActiveSync support, and its sync component serves native iOS and Android clients. Ask which Outlook add-ins and scheduled tools call EWS, since an add-in that works in Outlook may fail on the replacement server.
Directory integration with LDAP or AD
The exchange2grommunio migration path requires grommunio to use the same LDAP or Active Directory as the Exchange environment. Addresses, group membership and mailbox ownership must resolve identically, or Outlook autocomplete and delegate lookups will break. Confirm which directory attributes your Outlook profiles and global address list depend on before you change the identity source.
Shared calendars and delegates
Delegate access, shared calendars and free/busy lookups are where Outlook users notice a replacement most quickly. Open-Xchange documents its groupware features through the App Suite operations guide, but the exact delegate and free/busy behavior with Outlook must be tested with real mailboxes. Build a test matrix covering delegate send-on-behalf, calendar permissions and meeting responses from external invitees.
Folders, attachments and PST export
Folder structure, read and flag states, categories and attachments must survive the move. The grommunio migration script exports each Exchange mailbox to PST with New-MailboxExportRequest and imports it with gromox-pff2mt and gromox-mt2exm, so a PST import is the path to check. Compare item counts per folder after import and confirm that archive mailboxes, rules and category colors are handled as your users expect.
Outlook versions to test
Support for Outlook depends on the client build, not just the server protocol. Create a test list that names each Outlook version, Windows build, macOS client and mobile app in use, and record which features passed on each. Confirm the vendor's current client compatibility statement in writing before cutover, because client support changes as Microsoft updates Outlook.
How grommunio and OX App Suite handle Outlook connections
This table compares how grommunio and OX App Suite connect Outlook and mobile clients, and what each needs in your infrastructure. Read it as a list of things to confirm in a pilot, not as a guarantee that every Outlook feature behaves the same. The main takeaway is that grommunio is built to serve Outlook natively through MAPI/HTTP and EWS, while OX App Suite reaches Outlook through its ActiveSync connector and standard protocols, so shared calendar and delegate behavior must be tested on both.
| Area | grommunio | OX App Suite |
|---|---|---|
| Outlook connection protocols | RPC/HTTP (Outlook Anywhere), MAPI/HTTP and EWS through Gromox, the central groupware server | Exchange ActiveSync connector, IMAP and CalDAV; confirm the Outlook client path your version supports |
| Mobile clients | grommunio-sync provides Exchange ActiveSync for native iOS and Android clients | Exchange ActiveSync connector for native mobile clients; confirm supported device and OS versions |
| Calendar and contacts sync | grommunio-dav provides CalDAV and CardDAV alongside the native Exchange protocols | CalDAV for calendars; confirm how Outlook handles OX calendars and contacts over these paths |
| Shared calendars and delegates | Native MAPI behavior is the design goal; verify delegate permissions and free/busy with your Outlook versions | Depends on connector and protocol path; verify sharing, delegate access and free/busy in a pilot before assuming parity |
| Platform requirements | Appliance built on openSUSE from ISO or OVA with a setup wizard; manual and container installs also documented | v8 runs on Kubernetes with Helm 3.17.0 or newer, requires Istio (or basic ingress-nginx), Redis 7.4.x and MariaDB 10.6.x to 11.8.x |
| Storage and directory | MariaDB holds user metadata and SQLite stores mailboxes; must use the same LDAP or Active Directory as Exchange for migration | Persistent files need NFS or object storage such as S3, Ceph RadosGW or Scality RING for larger deployments |
| Licensing and support | Gromox is AGPL-3.0; free Community package for up to 5 users without manufacturer support; paid subscriptions sold through certified partners | Open-Xchange support commitment governs releases; certain modules may carry separate fees under the license agreement |
| Pilot checks before migration | Test Outlook versions, shared mailboxes, delegate rights and free/busy on the appliance or container build you plan to run | Test connector behavior with Outlook, Istio and Kubernetes upgrade paths, and shared calendar rights with your tenant layout |
Which Outlook features work, which need testing, and which may not carry over
Outlook behavior depends mostly on the protocol path between the client and the server, not on how the mailbox is stored. Shared calendars, delegate access, free/busy lookup, out-of-office settings, public folders and add-ins all rely on specific server-side services that the client calls. On grommunio, the relevant paths are MAPI/HTTP, RPC/HTTP (Outlook Anywhere) and Exchange Web Services, which Gromox implements. On OX App Suite, Outlook is typically connected through the Exchange ActiveSync connector, with IMAP and CalDAV covering other clients. A feature that works over one path may behave differently over another, so the first question for each Outlook capability is which path it uses in your deployment.
No supplied fact confirms feature parity for every Outlook capability on either platform, and this page does not claim it. Build a test matrix before any pilot. Include delegate permissions on a shared mailbox, sending as and sending on behalf, shared and delegated calendars, free/busy lookup across the organization, automatic replies set from the client, public or shared folders if you use them, and each Outlook add-in your staff rely on, including any that call Exchange Web Services directly. Run each case with a named pilot user on the exact Outlook build your organization deploys, and record the result, the protocol used and any error text. Ask the vendor or partner which of these paths they support and in which versions, and confirm the answers against your own tests.
Plan for the features most likely to fail quietly. Add-ins that depend on Exchange-specific APIs, calendar features that expect Exchange scheduling behavior, and rules or server-side transport logic that exist only in Exchange may not carry over unchanged. Decide in advance which of these are business-critical, which can be replaced by a different workflow, and which users accept a change for. Confirm with the vendor how their licensing treats any module or feature you intend to use, since OX App Suite's Operations Guide notes that some modules may be subject to custom packaging or separate fees. Keep the old Exchange environment available during the pilot so users can compare results side by side.
How to deploy an Outlook-compatible groupware server under your constraint
This sequence confirms the directory and Outlook client baseline, deploys either a grommunio appliance or an OX App Suite stack inside your own infrastructure, and proves Outlook behavior with named pilot profiles before any cutover. Each step ends with a check you can sign off before moving on.
Confirm directory source and Outlook client baseline
Your identity and infrastructure team records where users, groups and contacts are authoritative today, usually Active Directory or LDAP, and which Outlook builds and connection types (MAPI over HTTP, RPC over HTTP, or Exchange ActiveSync for mobile) are in use across the estate. For grommunio, the migration path depends on using the same LDAP or Active Directory as Exchange, so confirm that early. The step is done when you hold a signed inventory of directory sources, Outlook versions by department, and the mobile devices in scope.
Check prerequisites for the Exchange export script
If you plan to move mailboxes with grommunio's exchange2grommunio script, confirm the prerequisites in the migration documentation: grommunio must use the same LDAP or Active Directory as Exchange, the export must run from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, and a shared folder must be writable by Exchange and mountable on the grommunio server. Exchange administrators own this check. The step is done when a test export writes a file to the share and the grommunio host can mount it.
Choose the platform and size the target
Choose between the grommunio appliance and OX App Suite v8 based on your operating model and Outlook requirements, and confirm with each vendor which features your Outlook builds need, including shared calendars and delegate access. For grommunio, decide between the ISO or OVA appliance with its setup wizard, a manual install, or a container install. For OX App Suite, plan the Kubernetes cluster, Helm 3.17.0 or newer, Istio or the basic ingress-nginx option, Redis 7.4.x, a supported MariaDB version, and a distributed file system (NFS for small to mid-size deployments, or object storage for larger ones). The step is done when a written architecture note names every component and its owner.
Deploy the platform inside your infrastructure
Your platform engineers deploy the chosen stack in your own datacenter, private cloud or air-gapped network. For grommunio, boot the appliance from the ISO or OVA image and complete the setup wizard, then connect it to the directory. For OX App Suite, deploy the Helm charts to the cluster, then configure MariaDB, Redis and the file store. Record the versions you deployed, since support windows differ by release. The step is done when the server accepts MAPI/HTTP or EWS connections from a test Outlook profile and directory lookups return expected users.
Run a pilot with named Outlook profiles
Create named Outlook profiles for a small group of pilot users, covering each Outlook build and connection type in your inventory. Test sending, receiving, free/busy lookup, shared calendar access, delegate permissions, meeting invitations sent between pilot users and external recipients, and calendar sync to mobile devices. Log every gap, including features that rely on Exchange-specific behavior. The step is done when each test case has a recorded pass, fail or accepted-gap result that the business owner has signed.
Migrate pilot mailboxes and verify content
Export and import the pilot mailboxes using the chosen method, then compare item counts for mail, calendar, contacts and folders between source and target. Check that attachments, categories, read status and recurring meetings survive. Keep the export logs, because the script records successes and failures so runs can resume. The step is done when you can reconcile each pilot mailbox against its source and the discrepancies are documented.
Plan cutover and coexistence
Agree on a cutover window, mail routing changes, and how mail and free/busy will work for users still on Exchange during the transition. Confirm with your security team how antivirus, spam filtering and TLS policies apply to the new server, and document the rollback path. Clarify with the business owners what happens to shared calendars that span both systems. The step is done when a written cutover runbook has approvals from the infrastructure, security and business owners.
Questions buyers ask before keeping Outlook on a new server
Is grommunio free to run in production?
The grommunio Community package is free, but it is limited to up to 5 users and comes without manufacturer support. Above that, grommunio's pricing page lists Basic at 1.99 euros and Plus at 3.99 euros per user per month from 6 users, Business at 5.49 euros per user per month from 50 users, and custom Enterprise pricing from 1,000 users. Licenses are sold only through certified partners, so the paid tiers are a subscription you buy alongside your own infrastructure and staff time. Confirm with grommunio which package covers your user count, what support is included, and whether any features you need sit outside the tier you choose.
What drives the cost of keeping Outlook on a self-hosted server?
The main drivers are user count, the number of servers and storage you run, whether you need high availability, and how many clients and devices you must support. Recurring costs include the grommunio subscription for paid tiers, hosting, storage, backups and the staff who patch and monitor the system. One-time costs include the mailbox migration, directory integration and testing. Ask for a written quote that separates the subscription, infrastructure, storage growth, migration labor and ongoing support, so you can compare it fairly with your current Exchange licensing and hardware.
How long does a pilot take to run?
No fixed duration can be given because a pilot depends on your environment. The factors that matter most are the number of mailboxes, mailbox sizes, whether Active Directory or LDAP is already in place, how many Outlook profiles and mobile devices need testing, and whether shared calendars and delegates follow a complex pattern. Plan a pilot with a small group of real workflows, including meeting invitations, free/busy lookups, delegate access and mobile sync. Agree on the pilot's scope and exit criteria in writing before you start.
What does the work need from our internal team?
Your team needs to supply directory access, DNS and mail flow details, certificates, network rules between clients and the server, and a named contact who can approve cutover windows. For the Exchange migration path, the grommunio documentation requires the same LDAP or Active Directory as Exchange, an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, and a shared folder that Exchange can write to and grommunio can mount. Your administrators also need to test Outlook profiles and mobile devices, and to confirm which features matter to each user group before cutover.
Can our own IT team run this without outside help?
A capable team can run grommunio in-house if it has Linux administration skills, directory integration experience and time for testing and patching. Whether that is realistic depends on how many users you have, how strict your uptime and audit requirements are, and whether anyone has moved a mail system before. Many organizations split the work: internal staff own operations, while an implementation partner handles the migration, hardening and documentation. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms in your own infrastructure, under a fixed-scope written agreement, with ongoing support available as a retainer.
Does OX App Suite give Outlook users the same experience?
Not in the same way. OX App Suite is a web-based groupware suite with its own client, and it does not provide the native MAPI/HTTP or Exchange Web Services support that grommunio offers for Outlook. Outlook users can connect through IMAP and CalDAV, and mobile devices can use the Exchange ActiveSync connector, but shared calendars, delegate permissions and some Outlook-specific behavior need testing in your environment before you commit. If keeping the Outlook desktop client is a firm requirement, grommunio is the option to evaluate first, and you should confirm the specific features your users rely on.
What should we verify before choosing a path?
Verify the features your Outlook users depend on: MAPI/HTTP or RPC/HTTP connection, EWS needs for add-ins, ActiveSync for mobile, shared calendars, delegates, free/busy lookup and archive mailboxes. Confirm the subscription tier and what support it includes, the licensing terms for any OX modules you consider, and the hardware or Kubernetes requirements for your scale. Ask for a documented pilot with your own mailboxes before any production cutover. The grommunio documentation is the natural next read for the migration steps.
What to test before migrating Outlook users
Test the Outlook path before any mailbox moves, because the users who will not give up Outlook are the ones who will notice a broken workflow first. Start with the Outlook version and build in use across the business, since the connection method depends on it. Record which builds connect over MAPI/HTTP and which fall back to other protocols, and confirm the exact client builds with grommunio before the pilot. Then test a set of representative mailboxes, including the largest in the organization, and time how long a full synchronization takes on a laptop over the office network and over VPN. Mailbox size and cached mode interact closely: check that cached mode fills offline storage as expected, that search returns results across the whole mailbox, and that the .ost file size stays within what your endpoint management policy allows.
Next, test the collaboration features that Outlook users rely on daily. Create a shared mailbox and a shared calendar, then grant Full Access, Send As and Send on Behalf permissions to test accounts and confirm that each right behaves as expected in Outlook on Windows and on the web. Test delegate access to a manager's calendar, including meeting responses sent on behalf of the owner. Send calendar invitations to external recipients using Gmail, Microsoft 365 and a plain IMAP address, and check that free/busy lookups, updates, cancellations and attachments arrive correctly. Finally, test mobile sync on iOS and Android with ActiveSync, including push delivery and calendar updates after a password change. Record each result as pass, pass with workaround or fail, with the workaround written down. The results decide whether the platform fits the Outlook users you have, so confirm the required features in writing with the vendor before you commit.
Evidence to keep for the Outlook pilot and cutover
A keep-Outlook migration leaves a trail of test results, logs, mappings and decisions that you will need during cutover and afterward. The cards below list the artifacts to retain, what each one proves, and what to check before you sign off. DeployOpen can prepare this evidence as part of an engagement, but independent auditors and certification bodies are the parties who issue any attestation.
Outlook pilot results per build
Record which Outlook desktop builds, Outlook for Mac versions and mobile clients were tested against the platform, and for each one the results of sending, receiving, free/busy lookup, calendar invitations, delegate access and shared mailbox access. Keep the build numbers exactly as reported by each client, because Outlook behavior with MAPI/HTTP, EWS and ActiveSync can differ between builds. Re-run the pilot after any client update that falls inside your rollout window. A pass on one build is not evidence for another.
Migration script export and import logs
If you use the grommunio exchange2grommunio script, retain the logs it writes for each mailbox export to PST and each import over SSH through gromox-pff2mt and gromox-mt2exm. The script logs successes and failures so runs can resume, so the log set is your record of which mailboxes completed and which need a rerun. Check that the mailbox count in the logs matches the count in your Exchange inventory before you decommission anything.
Directory mapping records
Keep a record of how each Exchange object maps to the directory the new platform uses, including users, distribution groups, shared mailboxes, resource calendars and delegates. grommunio must use the same LDAP or Active Directory as Exchange for the migration script, so document the directory source and any attribute changes. Mismatched addresses or aliases are a common cause of mail routing failures and broken free/busy after cutover.
Signed-off list of unsupported features
Write down every Exchange feature that the pilot shows does not work or works only partially on the target, such as particular delegate permissions, public folders, mailbox archiving behavior or calendar sharing across organizations. For each item, record the workaround, the owner who accepted it and the date. Keep the list signed by the business owners as well as IT, so that a later complaint can be traced to a known and accepted gap.
Platform configuration records
Retain the configuration for the chosen platform, including server versions, protocol endpoints enabled for MAPI/HTTP, EWS and ActiveSync, certificate details, TLS settings, and the storage layout. For OX App Suite v8, this includes the Kubernetes and Helm chart versions, the MariaDB and Redis versions, and the distributed file system used for persistent data. Store these records in version control so each change has a dated history and a named approver.
Support and release commitments
Record the vendor support window for the release you deploy, because each standard release has a defined support period and an LTS release has its own end date. Confirm the support commitment in writing and note when you must upgrade. Retain the release notes you reviewed before each upgrade, since the Exchange-compatible client behavior may change between releases and your pilot evidence applies only to the version you tested.
How DeployOpen tests Outlook compatibility before a move
DeployOpen plans, implements, integrates and hardens self-hosted open-source platforms inside your own infrastructure, so Outlook compatibility is tested in your environment rather than assumed from a feature list. The work starts with a written scope that names which Outlook versions, mobile clients and shared calendar patterns must keep working.
How we scope
- Inventory the Outlook versions, platforms and connection types your users run today, including Outlook on the web and mobile clients.
- List shared mailboxes, delegate rights, room calendars and public folders that the move must preserve, with named owners for each.
- Agree the test matrix, deliverables and timeline in writing before any work starts, since engagements are fixed-scope.
How we build
- Stand up a test environment in your own cloud account, data center or air-gapped network that mirrors your directory and mail flow.
- Connect representative Outlook clients to the candidate platform and record which sync, free/busy and delegate actions succeed or fail.
- Test a sample of real calendar and contact migrations, then document gaps, workarounds and any features that need a different client.
How we hand over
- Deliver a compatibility report that lists each tested Outlook behavior, its result, and the exact configuration used to reach it.
- Provide runbooks for client profile setup, cutover sequencing and rollback, so your team can repeat the checks during rollout.
- Document the open items that need confirmation with the vendor or your own environment before the production migration.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so client behavior can be rechecked after each platform update.
- Retest Outlook builds after client updates or policy changes, and update the compatibility report and runbooks accordingly.
- Quotes follow from the written scope, so ask for the client versions, test cases and handover items to be listed explicitly.
