Which open-source option replaces Gmail for a company domain
For a company domain, the main self-hosted options for replacing Gmail and Google Calendar are OX App Suite, grommunio and Zimbra, and each fits a different situation. OX App Suite from Open-Xchange is a broad groupware platform that runs on Kubernetes with Helm charts, with its own email, calendar, documents, drive and tasks. grommunio is an Exchange-compatible server aimed at organizations that want Outlook clients and ActiveSync to keep working. Zimbra has a long history in self-hosted mail, but its current release and licensing position needs checking before you commit. If your renewal, data residency concern or lock-in worry is pushing you off Gmail, start by deciding which of these three matches the clients your staff already use and the operating model your team can support.
Most of what people call Gmail is three things: email, calendar and mobile sync. Those are what this section covers. Drive, Docs and Meet are separate modules with their own file storage, editing and video requirements, so treat them as a second decision and check the sibling pages in this group for them. Start by inventorying your users' clients. Outlook on Windows and macOS, native iOS and Android mail apps, and browser webmail each place different demands on the server, and grommunio's documented support for Outlook through MAPI/HTTP, EWS and ActiveSync is relevant only if that is your mix. Also confirm whether you need shared mailboxes, delegated calendars and resource booking, because not every platform handles these the same way.
Before you shortlist Zimbra, confirm three things with Synacor and in your own test environment. First, which features you need sit in the commercial license, since Zimbra states that high-availability clustering, encryption and large-scale sync are paid features. Second, the current release status: the Zimbra Releases wiki lists 10.0 and 9.0 as past their support windows, so you should verify which release line and patch level you would deploy. Third, the download model, because the Zimbra download page requires a new V10.1 license key, and the open-source build is compiled from source using zm-build rather than installed from packages. Ask for these answers in writing, because a platform choice made on an outdated release line is hard to reverse.
How Gmail and Calendar capabilities map to open-source options
This table maps the Gmail and Google Calendar capabilities a business relies on to OX App Suite, grommunio and Zimbra. Each row notes where a capability is documented, where it sits in a commercial tier, and what you must confirm in your own environment before you commit.
| Capability | OX App Suite | grommunio | Zimbra |
|---|---|---|---|
| Webmail and calendar | Email, calendar, tasks and documents are core components of the suite, deployed on Kubernetes with Helm charts (confirm feature parity with your Gmail usage) | Email, calendar, contacts and files are documented; grommunio positions itself as a Gmail-independent groupware platform with an Exchange-compatible core | Webmail and calendar are part of the open-source core server; confirm the web client version you deploy against your release |
| Calendar sharing and shared mailboxes | Calendar sharing is part of the core suite; confirm shared mailbox and delegation behavior with your Outlook and mobile clients | Shared mailboxes and delegation follow the Exchange model through MAPI/HTTP and EWS; confirm each delegation case in a pilot | Sharing is available in the core product; confirm delegation and shared folder behavior in your release before migration |
| Mobile sync (ActiveSync, CalDAV, CardDAV) | Mobile sync and CalDAV/CardDAV access must be confirmed for your device mix in the requirements and product guides | grommunio-sync provides Exchange ActiveSync for iOS and Android, and grommunio-dav provides CalDAV and CardDAV | ActiveSync mobile sync is listed as a Professional tier feature, so confirm whether your plan includes it |
| IMAP and POP access | Standard IMAP access should be confirmed with your mail stack configuration and client list | Gromox implements IMAP and POP3 alongside Exchange protocols | Core server supports standard mail protocols; confirm client settings against your release |
| Spam filtering and DKIM, SPF, DMARC | Filtering and DNS records are set in your own mail infrastructure; confirm the filter component and DNS policy during design | Filtering and DNS records are configured by your team; confirm the filter component and DMARC policy during design | Zimbra documents spam handling in its admin guides; confirm DKIM, SPF and DMARC setup for your domain |
| Admin and audit logging | Audit and admin logging depends on your deployment and logging stack; confirm retention and export options | Admin logging is set up on the appliance and host; confirm retention and export to your SIEM | Archiving and discovery are listed as Professional tier features, so confirm audit capabilities in your edition |
| Outlook client support | Confirm Outlook compatibility for your client versions; the suite is not positioned primarily for Outlook | Outlook clients remain supported through MAPI/HTTP, EWS and Exchange ActiveSync, per grommunio documentation | Outlook integration is listed as a Professional tier feature, so confirm the license before planning Outlook users |
Choosing between OX App Suite, grommunio and Zimbra
All three platforms can replace Gmail and Google Calendar for a company domain, but they differ in deployment model, licensing terms and where support comes from. OX App Suite is a Kubernetes-hosted suite with a fixed release cadence. grommunio aims for Exchange compatibility, and Zimbra splits an open-source core from commercial features. Use these trade-offs to shortlist options before you run a pilot.
OX App Suite runs on Kubernetes
OX App Suite v8 is delivered as Helm charts that reference container images, so your platform team must run a Kubernetes cluster within the supported version window. The suite requires Istio, with a basic ingress-nginx option where Istio cannot be used. It also expects MariaDB with InnoDB, Redis for caching and sessions, and a distributed file system such as NFS or S3-compatible object storage for Drive files and attachments. The trade-off is operational weight: you control every layer, but you also own mesh, database and storage upgrades. Confirm who runs them before you commit.
OX support cadence and LTS
A standard OX App Suite release is supported for 12 weeks, ending when the third following release becomes available, so standard builds suit test environments more than long-lived production. An LTS release is supported until the next LTS plus six months. Choose the LTS release line for production, and accept that it still requires planned upgrades. v8.35 is discontinued and v8.47 is the current LTS, so ask Open-Xchange to confirm the line you would deploy and its end date in writing before procurement.
OX licensing and source access
Open-Xchange publishes AGPL-3.0 mirrors of the App Suite frontend and middleware on GitHub, so your engineers can read the code that handles your mail. The Operations Guide notes that the right to use certain modules or features may depend on custom packaging, limitations or separate fees set in the license agreement. Ask for a written list of included modules, the fee status of every feature your users need, and whether support covers those modules. Source visibility and usage rights are separate questions, and only the contract answers the second.
grommunio and Exchange compatibility
grommunio presents itself as a native Exchange drop-in. Its Gromox server implements RPC/HTTP for Outlook Anywhere, MAPI/HTTP, Exchange Web Services, IMAP and POP3, so existing Outlook clients may continue to work. Native iOS and Android clients connect through grommunio-sync, and CalDAV and CardDAV come from grommunio-dav. The trade-off is that the compatibility claim is broad, so test your Outlook versions, shared mailboxes, delegation, calendar invitations and Exchange add-ins in a pilot before you accept it for every user.
grommunio delivery and pricing
grommunio ships as an openSUSE-based appliance in ISO or OVA form with a setup wizard, and its documentation also covers manual and container installs. A free Community package covers up to 5 users without manufacturer support. The grommunio pricing page lists Basic at 1.99 euros and Plus at 3.99 euros per user per month from 6 users, but licenses are sold only through certified partners, so compare support scope and who maintains the appliance. Confirm the Gromox version you will pin, since the most recent tag supplied is 3.12, dated October 2, 2026.
Zimbra open core and lifecycle
Zimbra is owned and sold by Synacor. Its core server is open source, while high-availability clustering, encryption and large-scale sync require a commercial license, and the Professional tier adds Outlook integration, ActiveSync and archiving. Version support is the main risk: Zimbra 10.0 reached end of general support on June 30, 2025, and the download page requires a new V10.1 license key. Teams that want to avoid packaged builds can compile their own from the zm-build scripts, which moves patching and testing onto their staff.
Keeping Outlook clients when leaving Gmail
Some teams want to leave Gmail but keep the Outlook desktop client and native phone mail apps their staff already use, so that users do not have to relearn a mail client during the move. The question to answer early is whether the target platform speaks the protocols those clients expect. grommunio states that organizations can keep their existing Microsoft Outlook clients through its MAPI/HTTP, EWS and Exchange ActiveSync support, and its Gromox server documents RPC/HTTP (Outlook Anywhere), MAPI/HTTP, Exchange Web Services, IMAP and POP3. Treat these as vendor claims to verify, not as a guarantee for your setup.
If you are comparing against an on-premises Exchange fallback, check your own lifecycle position first. Exchange Server 2019 reached the end of extended support in October 2025, and Microsoft points customers to Exchange Server Subscription Edition, which reached general availability on July 1, 2025, or to Exchange Online. An Exchange rebuild is therefore a separate decision with its own licensing and patching obligations, and it should be costed next to the self-hosted option rather than assumed to be the cheaper default. Ask your Microsoft account team to confirm which licensing applies to your estate.
Before you commit, test the exact Outlook builds and mobile devices your users run. Build a pilot group that includes the oldest supported Outlook version, the newest one, a Mac client if you have one, and iOS and Android phones with their native mail apps. For each, check account setup with autodiscover, calendar free/busy lookup, shared mailboxes, delegate access, large attachments, and how often the device re-syncs after a password change. Record which clients need a vendor-specific setting, and confirm support for each combination in writing with the vendor before you plan the cutover.
Running the new mail platform beside Google Workspace
Some organizations keep Google Drive, Docs and Meet and move only mail and calendar. This is the lowest-disruption option for the collaboration tools, but it creates a permanent split: documents and meetings stay in Google while mailboxes live elsewhere, so sharing links, calendar invitations and attachments cross two systems. Plan for that split as a long-term state, not a stepping stone, unless you have a dated decision to finish the move.
- Identity: Decide whether the new mail platform authenticates against the same directory as Google Workspace or its own. Two separate password stores are a common source of support tickets and access gaps.
- Domain ownership: The company domain's MX records stay pointed at Google, so the new platform only receives mail if you route specific addresses or aliases to it, which usually needs the platform's own gateway or a split-delivery design.
- Calendar: Users on the new platform will not see Google calendar availability by default. Confirm what free/busy sharing the platform supports with Google before users rely on it for meeting scheduling.
- Outbound mail: Keep SPF, DKIM and DMARC aligned for every sending service so both platforms can send from the same domain without failing checks.
- Exit point: Record what would trigger the mail cutover, such as license renewal or retention requirements, so the coexistence state does not become indefinite.
Before committing, test a pilot group end to end: sending to Gmail, receiving from Gmail, booking meetings across both systems and confirming sign-in works on mobile clients.
A hybrid period moves the mail domain to the new platform in stages while some mailboxes still sit in Google. The domain's MX records point to the new platform, and the platform forwards or relays mail for users still on Google. This works, but every inbound and outbound path must be mapped before the MX change, because a misrouted message can bounce or land in the wrong mailbox without a clear error.
- MX and routing: Lower the TTL on existing MX records well before the change so that rollback is quick. Confirm how the new platform forwards unknown recipients to Google, and test with a message to each mailbox type.
- Shared sign-in: Where the platform supports LDAP, Active Directory, OpenID Connect or SAML, use one identity source for both sides. Confirm exact support for each protocol in the platform documentation before design, since capability varies by product and version.
- Free/busy across two systems: Test free/busy lookups in both directions. Publish a clear rule for meeting organizers, because a meeting booked on one side may show as free on the other if lookups fail.
- Outbound reputation: Send from one sending path per domain where possible. Two outbound paths with different IP addresses can split sender history and trigger filtering, so keep DKIM selectors and SPF entries current on both sides.
- Monitoring: Watch bounce and deferral logs daily during the hybrid period and track any user-reported missing mail.
Ask the implementation partner for a written routing diagram and a rollback runbook before the first MX change.
A full cutover moves all mailboxes, calendars and sign-in to the new platform and leaves Google Workspace only for archive or retention access. The MX change, mailbox migration and sign-in switch are timed together, so the cutover window needs a defined start, a defined end and a named owner for each step. Keep Google access for the export period, because Workspace export tools have their own timing limits.
- Sequence: Migrate historical mail first, then run a final delta sync, then change MX records and sign-in in the same window. Document the order and who approves each step.
- Mobile clients: Confirm which mobile sync protocols the new platform supports for iOS and Android. Users may need to remove and re-add accounts, so plan the message and support load.
- Calendar and contacts: Confirm that calendar and contact exports carry recurring events, attendees and shared calendars. Recheck any meeting room or resource calendars after migration.
- Outbound reputation: Keep the same sending domain and DKIM signing set up before cutover, and warm up the new sending path if it uses different IP addresses. Watch for rejections from large providers in the first days.
- Retention: Keep the Google data export or archive until legal and records teams confirm retention is met.
Before the window, confirm with the vendor and your own environment which migration method, sync protocol and export formats apply to your mailbox count and edition.
Moving mailboxes, calendars and contacts off Gmail
This sequence moves a company domain's mail, calendars and contacts from Gmail to a self-hosted platform with a verified cutover. Each step ends with a check you can record, so the cutover date rests on evidence rather than assumption.
Inventory users, shared mailboxes and calendars
Your admin lists every primary account, Google Group that receives mail, shared mailbox, delegated mailbox, resource calendar and shared calendar on the domain, with its owner and size. Check which accounts have admin rights, which are service accounts and which mail is forwarded to outside addresses. The output is a signed-off inventory that maps each source to a target account on the new platform. Confirm with your Workspace admin which items the Data Export or Takeout will cover, since per-user exports depend on what each user is allowed to download.
Confirm export eligibility and timing
Super administrators can run the organization-wide Data Export, which delivers Gmail, Drive, Chat and Calendar data as zip files into a Cloud Storage bucket. The admin account must be at least 30 days old. Google's documentation says exports typically take about 72 hours and can take up to 14 days, and the default bucket is deleted after 60 days, so copy the files to your own storage before that window closes. Users without admin rights depend on Google Takeout, which Workspace administrators can switch off. Record who ran each export, when it finished and where the archive was copied.
Convert mail, calendar and contact data
Gmail exports arrive as mbox files, and calendars and contacts arrive as iCal and vCard files. Convert mbox into the format your target importer accepts, and check that message headers, attachments and folder labels survive the conversion on a sample mailbox. Keep iCal files intact for calendar import and validate vCard files for duplicate contacts. Note that the grommunio Exchange script described in the migration guide covers Exchange sources through PST files, so it does not apply to Gmail archives. The output is a tested conversion procedure and a sample mailbox that opens correctly in the target client.
Import data and run a pilot mailbox
Import the converted mail, calendars and contacts into the target platform, starting with a pilot group of a few users chosen by the business owner. Use the importer or migration tooling documented by OX App Suite or grommunio, and confirm with the vendor how each item type is handled. Compare message counts, folder structures, recurring events and contact fields against the source. Because OX App Suite and grommunio can both serve IMAP, you can also test sync directly from an IMAP client, but confirm which folders and labels sync before relying on it. The output is a pilot sign-off listing any items that did not move.
Verify DKIM, SPF and DMARC before cutover
Before routing live mail to the new platform, your DNS owner publishes the sending records the new server needs: an SPF record that includes the new sending hosts, a DKIM key with its selector, and a DMARC policy you have reviewed. Keep the existing Gmail records in place during the transition so mail from both systems authenticates. Confirm with your mail platform vendor which signing keys it generates and how it handles outbound relay. The output is a DNS change record and a check of each record with an external lookup tool.
Send test messages across all paths
Send test messages between the pilot accounts, from the pilot accounts to external Gmail and Microsoft addresses, and from external addresses back in. Check that messages land in the inbox rather than spam, that DKIM and SPF pass in the received headers, and that DMARC reports begin to arrive for the new sender. Test calendar invitations, free/busy lookups and mobile sync on iOS and Android clients, and confirm the mobile path with the platform's supported protocols. The output is a test log with each path, result and header evidence.
Cut over mail routing and live sync
Change the MX records to the new platform at an agreed time and keep the Gmail archive available for lookups. Run incremental IMAP sync for users who need mail that arrives during the transition, and assign each user a clear date for moving their clients. Watch the DMARC aggregate reports and the bounce logs during the first days, and fix any authentication failures before expanding the pilot. The output is a cutover record showing the MX change time, the users moved and the monitoring checks passed.
Retire the Gmail source after verification
Once all users are moved and the archive is verified, remove the Gmail routing and decide how long the exported archive is retained under your records policy. Keep the export files in your own storage, not in the Google bucket, and document where each archive sits and who can access it. Confirm with your compliance lead whether any legal hold or retention requirement applies before deleting the Workspace data. The output is a closure record that lists the retained archives and the owner of each one.
Spam filtering and deliverability on your own servers
Once mail leaves Google, your organization owns deliverability. Gmail handled sender reputation, inbound filtering and outbound authentication behind the scenes. On a self-hosted OX App Suite, grommunio or Zimbra server, the team becomes responsible for the public IP address reputation of the sending server, the reverse DNS record that matches its hostname, and the SPF, DKIM and DMARC records that tell receivers your domain's mail is genuine. Outbound TLS for submission and for server-to-server delivery also becomes your configuration to set and renew. Each of these is a one-time setup with recurring effort: keys rotate, IP ranges get listed on blocklists, DMARC reports arrive and need reading, and new sending services such as invoicing or marketing tools must be added to SPF before their mail starts failing.
Confirm the spam and antivirus components before you size the project. Each platform bundles a different set of mail filtering parts, and the reader should not assume any of them. Ask each vendor or partner which anti-spam engine, antivirus engine, greylisting or policy service, and quarantine tool ship in the default package, which ones they expect you to add, and whether the bundled components are the same in the community edition as in a paid tier. Also ask how bounce handling works, including how undeliverable messages are returned to senders and how backscatter is avoided. Without these answers, you cannot estimate the tuning work or the operating cost of the filter.
Plan for filter tuning as ongoing work, not a launch task. Spam rules, reputation lists and false positive rates change over time, and the first weeks after cutover usually bring complaints from staff about legitimate mail held or rejected. Assign a named owner for quarantine review, false positive handling and DMARC report review before go-live. Test inbound and outbound delivery to the major mailbox providers your customers use, and confirm the vendor's recommended sending and reputation practices in writing. Do not accept any claim about filter accuracy until you have measured it on your own mail.
What a self-hosted Gmail replacement costs and needs
What cost components does a self-hosted Gmail replacement have?
A self-hosted replacement has five cost components: infrastructure, software licenses or subscriptions, migration work, support, and internal staff time. Infrastructure covers servers or a Kubernetes cluster, storage for mailboxes and attachments, backups and network capacity, and it recurs every month. Software is either free (for example, AGPL or GPL components you run yourself) or sold as an enterprise subscription with support, and that fee recurs. Migration, support and staff time are mostly one-time or variable effort, paid to whoever does the work. Ask each vendor and integrator to price these lines separately so you can compare the totals fairly.
What drives the effort of replacing Gmail up or down?
The main drivers are mailbox volume, the number of users, how much history must move, and how many services depend on mail. Large archives, shared mailboxes and delegated calendars add migration steps. Integration with single sign-on, directory synchronization, mobile sync, mail routing for applications, and spam and deliverability setup all add configuration work. Your team's experience with mail servers, DNS records (SPF, DKIM and DMARC) and certificate management also changes the amount of outside help you need. A smaller, well-documented user base with simple sharing usually takes less effort than a large organization with many shared resources.
How long does migrating company email from Gmail take?
No duration for mail migration is supplied here, so confirm the timeline with the vendor or in a scoped plan before you commit. The time depends on total mailbox volume, the number of users, the import method (IMAP sync or export files), throughput of your network and target servers, and how many cutover rounds you run. Ask for a phased plan that separates a pilot group, bulk history import, delta sync and the final DNS cutover, and ask what each phase requires from your staff. Treat any single number you hear as provisional until the plan is written against your own mailbox counts.
Can our own IT team replace Gmail without outside help?
Yes, if your team already runs mail, directory and DNS services and can own the platform after go-live. Teams without that experience usually need help with deliverability, spam filtering, high availability and backup restore testing, which are the areas where mistakes are hardest to see. Open-source options differ in how much they assume: grommunio ships as an appliance with a setup wizard, while OX App Suite v8 runs on Kubernetes with Helm charts, MariaDB, Redis and a distributed file system. Choose based on the skills you already have, and budget for training if they are missing.
What should we ask for in a written quote?
Ask for a written scope that lists the platform version, the deployment target (on-premises, private cloud or Kubernetes), and the integrations included, such as directory, single sign-on, mobile sync and archiving. The quote should state which migration method is used, how many mailboxes and how much data are covered, and what is excluded. Request the support model, response expectations, upgrade approach, backup and restore testing, and documentation handover. Also ask which third-party licenses or modules are required, since OX has noted that certain features may carry separate fees under the license agreement. DeployOpen issues fixed-scope quotes from a written scope, so the scope document is the basis for every line.
Is Google Takeout or Data Export enough to move our email on its own?
Neither is enough on its own. Google Takeout lets individual users export their own data, and Workspace administrators control whether users can use it. The admin Data Export tool lets super administrators export organization data, including Gmail, into a Cloud Storage bucket, but the admin account must be at least 30 days old, exports typically take about 72 hours and can take up to 14 days, and the default bucket is deleted after 60 days. Those files still need to be converted and imported into the target system, and the import step, delta sync, calendar conversion and shared resources need their own plan. Use the export as the source of data, not as the whole migration.
What recurring costs should we expect after go-live?
Recurring costs include infrastructure, storage growth, backups, enterprise subscriptions or support contracts if you choose them, patching and upgrade effort, and monitoring of mail delivery. Subscription tiers differ by vendor and by user count, so ask for the price list that applies to your user count and for what each tier includes. grommunio publishes per-user monthly prices for its paid packages, sold through certified partners, and Nextcloud offers enterprise subscriptions for support and additional features. Ask the vendor how upgrades are supported, since the support windows for each release line differ.
License and support terms to check before you commit
Before you fix scope, get written terms for the platform you pick, because the open-source label does not settle what you can use or who supports it. OX App Suite is published with AGPL-3.0 source mirrors on GitHub, but Open-Xchange's Operations Guide states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask Open-Xchange or your partner to list every module in your target design, confirm which ones carry separate fees, and get those fees in the order form rather than assuming the core is the whole product.
grommunio's free Community package covers up to 5 users without manufacturer support. Its 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 from 50 users, and custom Enterprise pricing from 1,000 users, and licenses are sold only through certified partners. Confirm the tier that matches your headcount and growth, which partner you will buy through, and whether support terms are bundled with the license. Zimbra's core server is open source, but its high-availability clustering, encryption and large-scale sync sit behind a commercial license, and its Professional tier adds Outlook integration, ActiveSync and archiving. Check each feature you need against that split before you design around it.
Read the support commitment for the exact release you plan to deploy. Open-Xchange supports a standard release for 12 weeks and an LTS release until the next LTS plus six months, and the current LTS is v8.47. Zimbra 10.0 reached end of general support on June 30, 2025, and Zimbra 10.1.0 reached general availability on July 16, 2024. Ask each vendor for the end-of-support date of your chosen version, the upgrade path and whether security fixes are signed and delivered separately, then write those dates into the project plan so the platform does not expire during rollout.
How DeployOpen scopes and delivers a Gmail replacement
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted mail and calendar platforms inside your own infrastructure. Each Gmail replacement starts from a written scope that covers your domain, directory, mail flow and migration window before any work begins.
How we scope
- Inventory of mail domains, aliases, shared mailboxes, calendars and resource booking needs for your organization
- Decision on OX App Suite, grommunio or Zimbra based on directory, client and mobile sync requirements
- Written statement of deliverables, timelines and exclusions agreed before work starts, with a quote following from that scope
How we build
- Deployment into your own cloud accounts, data centers or air-gapped networks, with the platform sized to your user count
- Configuration of SPF, DKIM and DMARC records, spam filtering and directory integration against your existing identity source
- Security testing of the deployed mail service and documentation of the controls you need for compliance readiness
How we hand over
- Migration runbook covering IMAP sync, PST or export file imports, and a cutover plan with a fallback path
- Operator documentation for administrators, backup and restore procedures, and upgrade steps for the chosen release
- Handover session with your platform, security and service desk teams, followed by a sign-off against the agreed scope
How we support
- Ongoing support, upgrades and continuous testing available as a retainer after handover
- Periodic review of deliverability, spam filtering and certificate and mail record health against your scope
- Clear escalation path and a written record of changes to mail infrastructure over time
