Which self-hosted groupware fits your team and your Exchange situation
If your organization wants to keep Outlook and mobile clients while leaving Exchange, grommunio is the option built to act as a drop-in replacement. If you are a service provider hosting mail and collaboration for other organizations, OX App Suite is the option built for that model. SOGo fits teams that want a lighter groupware server with ActiveSync and Outlook paths and can handle more of the integration themselves.
grommunio is positioned as a native Exchange drop-in replacement, with MAPI/HTTP, Exchange Web Services and Exchange ActiveSync support so existing Outlook clients can stay in place. Its Exchange migration tooling requires the same LDAP or Active Directory as Exchange and runs from an elevated Exchange Management Shell, so confirm your directory layout before planning a move. Its appliance-based delivery is a practical fit for teams without a container platform, while its paid tiers are sold through certified partners, so ask for the partner quote in writing.
OX App Suite is designed for hosting providers, telcos and ISPs, and v8 runs on Kubernetes using Helm charts, with Istio required and an ingress-nginx option where Istio cannot be used. That is a platform commitment: plan for cluster operations, Redis, MariaDB and a distributed file system for persistent data. SOGo is a GPL and LGPL groupware server with native ActiveSync and an Outlook path through the Outlook CalDav Synchronizer, which suits smaller teams with simpler operations. Zimbra and Carbonio are the other suites many readers weigh, and the verdict depends on the license and support model each team can accept, so compare those terms directly before you shortlist.
Which groupware option suits each scenario
This table maps common groupware scenarios to the platform that fits best and the supplied fact that drives the choice. Read each row against your own identity, Outlook, hosting and staffing constraints, because the fit changes quickly when any one of them changes.
| Scenario | Best fit | Why |
|---|---|---|
| Exchange-to-open-source migration that must keep Outlook | grommunio | Describes itself as a native Exchange drop-in, supports MAPI/HTTP, EWS and Exchange ActiveSync for existing Outlook clients, and ships an Exchange migration script. The script needs the same LDAP or Active Directory and a Windows admin host. |
| Hosting provider or telco white-labeling mail | OX App Suite | Positioned as a white-label platform for hosting providers, telcos and ISPs, deployable on premises, in public cloud or as OX Cloud. Confirm the module licensing terms in the license agreement. |
| Small team with a limited platform budget | SOGo | Free under GPL and LGPL with calendars, contacts, webmail and ActiveSync. Confirm the Outlook CalDAV Synchronizer setup and your support needs, since commercial support is optional. |
| Organization already on Active Directory or LDAP | grommunio | Documents compatibility with LDAP and Active Directory as a core feature. SOGo also integrates with directories, so confirm your authentication method against your own environment. |
| Team that wants to avoid a Kubernetes platform | SOGo or grommunio appliance | OX App Suite v8 is designed for Kubernetes with Helm 3.17.0 or newer and Istio or ingress-nginx. grommunio ships as an openSUSE appliance with ISO or OVA images and a setup wizard, and also documents manual installation. |
| Team that must run a Kubernetes-based suite with Exchange-style clients | OX App Suite | Requires Kubernetes, Istio (or basic ingress-nginx), Redis 7.4.x and MariaDB, with NFS or object storage for files. Plan for platform staff who already run these components. |
What OX App Suite, grommunio and SOGo each are
These five options cover most groupware shortlists. OX App Suite, grommunio and SOGo are open-source servers you can run in your own infrastructure, while Zimbra and Carbonio raise licensing questions to settle before you compare them. Each card names the license, the buyer the product targets and the deployment shape it implies.
OX App Suite
OX App Suite is a white-label email, productivity and collaboration platform built for hosting providers, telcos and ISPs. It can run on premises, in a public cloud or as the managed OX Cloud. The v8 architecture ships as Helm charts for Kubernetes, with Istio or a basic ingress-nginx option, Redis 7.4.x for caching and sessions, MariaDB, and persistent data on NFS or object storage. The source mirrors are AGPL-3.0, but the Operations Guide says some modules may carry separate fees set in the license agreement, so confirm which modules your license covers before you plan around them.
grommunio
grommunio is a European open-source collaboration platform that describes itself as a native Exchange drop-in replacement. Its groupware server, Gromox, is AGPL-3.0 and implements Outlook Anywhere, MAPI/HTTP and Exchange Web Services, so existing Outlook clients can stay in place. It ships as an openSUSE appliance in ISO or OVA form with a setup wizard, and it also documents manual and container installs. The free Community package covers up to 5 users without manufacturer support. Paid packages are sold only through certified partners, so confirm the partner, support tier and user count in writing.
SOGo
SOGo is a free groupware server licensed under GPL and LGPL version 2 or later, developed by its community and by Alinto. It provides webmail, calendars, address books and resource sharing over IMAP, CalDAV and CardDAV. It adds native Microsoft ActiveSync for phones and tablets, so desktop Outlook needs its own test: Outlook support runs through the Outlook CalDav Synchronizer, which you should check against your calendar and contact workflows early. Alinto offers premium support alongside community support. Mailcow ships SOGo as its webmailer and CalDAV and CardDAV interface.
Zimbra Collaboration
Zimbra Collaboration is an established suite, and many organizations now plan moves to other self-hosted suites after its 10.x licensing changes. The Zimbra download page offers Zimbra Collaboration Daffodil version 10 and states that a new V10.1 license key is required to run it. The zm-build repository holds scripts for a FOSS build, with examples for 10.1.0 and 10.0.8, which you compile yourself from source. Treat the packaged release as not OSI open source, and confirm with Zimbra what the key covers and what the FOSS build supports.
Carbonio
Carbonio is a mail and collaboration suite that may appear on your shortlist beside Zimbra and OX App Suite. Its license, paid editions, deployment model, Exchange compatibility and supported clients are not covered by the sources behind this section, so confirm each with the vendor before you compare it. Ask for the license terms in writing, the paid tiers and what each includes, the deployment shapes it supports, and its Outlook and mobile client support. Then measure those answers against the same criteria used for the other four options.
How Exchange compatibility differs across the options
grommunio documents the broadest Outlook path of the three. Its Gromox server implements RPC/HTTP (Outlook Anywhere), MAPI/HTTP and Exchange Web Services alongside IMAP, POP3 and an SMTP local delivery agent, and grommunio's FAQ says existing Microsoft Outlook clients can stay in place through MAPI/HTTP, EWS and Exchange ActiveSync. For mobile, grommunio-sync provides Exchange ActiveSync for native iOS and Android clients, and grommunio-dav provides CalDAV and CardDAV. Confirm which Outlook builds and mobile OS versions your fleet runs against that protocol list, since documented support does not establish how each client behaves on your mailboxes.
SOGo takes a different route, and its Outlook path is narrower. SOGo documents native Microsoft ActiveSync support so phones and tablets can sync email, contacts, events and tasks, and it lists Outlook compatibility through the Outlook CalDav Synchronizer. That is a calendar and contact bridge, not a MAPI or EWS server, so desktop Outlook users should expect a different experience from an Exchange-protocol deployment. Ask Alinto or the SOGo community which Outlook versions and calendar sharing features have been exercised with that synchronizer before you commit. For OX App Suite, the supplied material does not settle which Outlook and mobile clients it supports, so confirm that scope directly with Open-Xchange and in its requirements documentation.
Test shared mailboxes and public folders before any commitment. Outlook behavior for delegation, shared calendars, free/busy lookups and public folders varies by client version and by protocol, and none of the sources above guarantee parity for those features. Build a pilot with your current Outlook versions, your iOS and Android builds, and a copy of a real shared mailbox, then check send-as rights, calendar invitations and mobile sync conflicts. Record the results per client version so the decision rests on your own evidence.
How the groupware options compare on capability
This table sets OX App Suite, grommunio and SOGo side by side on license, support model, latest release, Outlook and mobile paths, directory integration, storage and deployment shape. Where the supplied facts do not answer a question, the cell tells you to confirm it with the vendor before assuming an answer. Zimbra and Carbonio are not in these columns because no capability facts were supplied for them, so confirm their Outlook, mobile, directory and storage behavior directly with each vendor.
| Capability | OX App Suite | grommunio | SOGo |
|---|---|---|---|
| License | AGPL-3.0 source mirrors for frontend and middleware; use of some modules set by license agreement | AGPL-3.0 for Gromox, the central groupware server | GPL and LGPL, version 2 and later |
| Paid editions or support | Commercial license terms; standard releases supported 12 weeks, LTS until next LTS plus six months | Free Community package up to 5 users without manufacturer support; paid tiers per user per month via certified partners | Free software; premium support from Alinto alongside community support |
| Latest supplied release | v8.53 (first shipment 2026-09-23); LTS v8.47 (FCS 2026-03-18) | Gromox 3.12, tagged October 2, 2026 | SOGo 5.12.12, published October 13, 2026 |
| Outlook path | Not stated in supplied facts; confirm Outlook support and connector type with Open-Xchange | MAPI/HTTP, RPC/HTTP (Outlook Anywhere) and EWS, so existing Outlook clients can stay | Calendar sync through the Outlook CalDav Synchronizer; confirm the Outlook mail path with Alinto |
| Mobile sync path | Not stated in supplied facts; confirm native iOS and Android sync with Open-Xchange | grommunio-sync supports Exchange ActiveSync for native iOS and Android; CalDAV and CardDAV via grommunio-dav | Native Microsoft ActiveSync for email, contacts, events and tasks |
| LDAP or Active Directory | OpenID Connect and SAML documented for sign-in; directory sync options to confirm with the vendor | Compatible with LDAP and Active Directory; migration needs the same directory Exchange uses | Not stated in supplied facts; confirm directory integration with the vendor |
| Storage and database | MariaDB with InnoDB (10.6, 10.11, 11.4, 11.8; Galera supported); Redis 7.4.x; NFS or object storage for files | MariaDB for user metadata, SQLite for individual mailboxes | Not stated in supplied facts; confirm supported databases and mail storage with Alinto |
| Deployment shape | Kubernetes with Helm 3.17.0 or newer, Istio or basic ingress-nginx; Kubernetes N-1 and N-2 supported | openSUSE appliance as ISO or OVA with setup wizard; manual and container install; Gromox scales across hosts | Sits between users and existing servers; mailcow bundles SOGo as its webmailer |
What each license and paid edition gives you
The source mirrors for the App Suite user interface (appsuite-frontend) and middleware (appsuite-middleware) are published on GitHub under AGPL-3.0, so the code you can read is open under a strong copyleft license. Running that code in production is a separate question. Open-Xchange states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in your license agreement, so module rights are a contract matter, not something the mirrors settle. Support follows Open-Xchange's support commitment, where a standard release is supported for 12 weeks and an LTS release is supported until the next LTS release plus six months.
- Source mirrors: AGPL-3.0 covers the published frontend and middleware code, which you can inspect and build from.
- Module rights: Ask which modules and features your agreement covers, and whether any carry separate fees.
- Standard releases: Plan upgrades inside the 12-week window of each standard release.
- LTS windows: Confirm which LTS line you will run and its end date under the support commitment.
- Hosting model: Check whether your deal covers on-premises, public cloud or the managed OX Cloud, since the commercial terms may differ.
Before you sign, ask Open-Xchange to map each feature you need to a license term, and to state the support tier that goes with it.
grommunio publishes a tiered pricing page. A Community package is free for up to 5 users, but it comes without manufacturer support. Paid tiers are priced per user per month: Basic at 1.99 euros and Plus at 3.99 euros per user per month from 6 users, and Business at 5.49 euros per user per month from 50 users. Custom Enterprise pricing applies from 1,000 users. grommunio sells licenses only through certified partners, so the buying path runs through a partner rather than directly from the vendor.
- Community: Free for up to 5 users, with no manufacturer support.
- Basic: 1.99 euros per user per month, from 6 users.
- Plus: 3.99 euros per user per month, from 6 users.
- Business: 5.49 euros per user per month, from 50 users.
- Enterprise: Custom pricing from 1,000 users, quoted by a certified partner.
Prices are per user and recur monthly, so multiply the tier by your headcount and confirm whether the price list includes VAT and whether the tier boundaries are applied per tenant or per organization. Ask your partner which tier includes the support you need, what the support response terms are, and whether migration help is part of the license or a separate service.
SOGo is free and open-source groupware released under GPL and LGPL version 2 and later. The license cost is zero, so your spend goes to the servers, the people who run them and any support contract you choose. The project is developed by its community and Alinto, and the sogo.nu site links both premium support from Alinto and community support. The support tier is the paid layer; the software is the same either way.
- Free license: GPL and LGPL version 2 and later cover the server, with no per-user license fee in the supplied materials.
- Premium support: Alinto offers premium support, which is the main paid option named on the project site.
- Community support: Free channels exist alongside the paid option, suited to teams that run their own operations.
- Scope of coverage: Confirm whether a support contract covers the Outlook CalDav Synchronizer and ActiveSync components you depend on.
- Bundled deployments: Some distributions, such as mailcow, ship SOGo as part of a larger stack, so check which license and support terms apply to the bundle.
Ask Alinto for a written description of what premium support includes, its response terms and whether it covers upgrades and the mobile sync path. Confirm these in writing before you rely on them.
Zimbra's download page offers Zimbra Collaboration Daffodil version 10, and it states that a new V10.1 license key is required to run it. The commercial path therefore depends on a license key tied to the release line, and you should confirm the key terms before deployment. Zimbra's zm-build repository holds scripts to create a FOSS build of Zimbra Collaboration, with examples for 10.1.0 and 10.0.8. That build is compiled by the user rather than downloaded as a package, so the open route moves build, test and patch work onto your team.
- Daffodil 10: The download page offers this version, which requires a V10.1 license key to run.
- License key: Confirm the key scope, term and what happens at renewal.
- FOSS build: The zm-build scripts produce a free build, with examples for 10.1.0 and 10.0.8.
- Build responsibility: Users compile the FOSS build themselves, so budget engineering time for builds, testing and patching.
- Support boundary: Ask what vendor support covers a self-compiled build, if anything.
Before you choose a path, ask Zimbra which license key terms apply to your deployment, and ask your own team to estimate who will own the build pipeline and security patching over time.
What running each groupware stack takes from your team
OX App Suite v8 is a platform deployment, not a mail server install. It 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. Your platform engineers own the cluster, the ingress choice (Istio where you can run it, or the basic ingress-nginx option where you cannot), Redis 7.4.x for caching and session storage, and a MariaDB database using InnoDB, where the supported versions are 10.6.x, 11.4.x, 11.8.x and 10.11.x. Persistent files such as OX Drive content and PIM attachments need a distributed file system, NFS for smaller deployments or object storage for larger ones, so storage design is a day-one decision. Upgrade cadence is set by Open-Xchange's support commitment: a standard release is supported for 12 weeks, while an LTS release is supported until the next LTS plus six months. Confirm which LTS line you will sit on and budget a recurring upgrade window against it.
grommunio and SOGo shift the work to the mail and directory side. grommunio ships as an openSUSE-based appliance delivered as ISO or OVA images with a setup wizard, and it also documents manual and container installation. The appliance path keeps the platform engineering light, but your mail administrator still owns Exchange migration, the LDAP or Active Directory integration that the migration script requires, and the Outlook, Exchange ActiveSync and CalDAV client configuration. SOGo is different again: it sits between your existing mail servers and directory services to present one interface, so the work is integration and permissions, with mailcow as one common host that bundles it. Before committing, confirm with the vendor how each product handles directory changes and client certificate or profile updates, since those recur every time users or policies change.
Plan for three roles and a recurring cost base. A platform engineer carries the cluster, database, storage and upgrade work for OX App Suite. A mail administrator owns mailbox lifecycle, client support and, for grommunio, the migration waves. An identity owner controls the LDAP or Active Directory source that all three products rely on, and that role is often the one missing from the project plan. One-time costs include the initial build, migration and integration. Recurring costs include upgrades, support contracts, monitoring, backup testing and staff time, and they rise with user count and the number of clients. Ask any vendor or partner for a written scope that separates build, migration, run and upgrade effort, and for the support tier and release windows that apply to your version.
How to choose and pilot a groupware option
This sequence turns a shortlist of OX App Suite, grommunio, SOGo and any other candidate into a documented go or no-go decision, using real client versions, your own directory and one tested mailbox move before anyone commits to a platform.
Inventory Outlook and mobile client versions
The messaging lead and the endpoint team list every Outlook build, Outlook for Mac version, and iOS and Android mail client in use, noting which users rely on Exchange-specific features such as shared mailboxes, delegation, public folders or out-of-office rules. Confirm with each candidate vendor in writing which client protocols it supports for those versions: grommunio documents MAPI/HTTP, EWS and Exchange ActiveSync for existing Outlook clients, while SOGo documents native ActiveSync and an Outlook CalDAV synchronizer. Done when every client version has a supported protocol path or a named gap with an owner.
Test directory integration with LDAP or Active Directory
The identity engineer connects a pilot instance to a copy of your LDAP or Active Directory and tests user lookup, group membership, password policy behavior, and account disablement for a leaver. Note that grommunio's Exchange migration path requires the platform to use the same LDAP or Active Directory as Exchange, so the test should use your production directory structure, not a lab tree. Done when a test user signs in on each client type, a disabled account loses access, and the group-based permissions in the pilot match your access model.
Decide whether the platform team can run Kubernetes
The platform lead compares the candidate architectures against the team's current operating skills. OX App Suite v8 is delivered as Helm charts for a Kubernetes cluster, requires Helm 3.17.0 or newer, expects Istio or a basic ingress-nginx option, and uses Redis and MariaDB with a distributed file system for persistent data. grommunio ships as an openSUSE appliance with ISO or OVA images and also supports manual and container installs, while SOGo runs on a conventional mail and web stack. Done when the team records a written yes or no on Kubernetes operations, with named owners for the database, storage and certificate tasks.
Test a single mailbox migration
The migration engineer moves one representative mailbox from a staging copy of your current system to the pilot platform. For grommunio, the documented path runs exchange2grommunio.ps1 from an elevated Exchange Management Shell on Windows Server 2012 R2 or newer, exports each mailbox to PST with New-MailboxExportRequest, and imports it over SSH using gromox-pff2mt piped into gromox-mt2exm. Confirm the shared folder is writable by Exchange and mountable on the grommunio server, and check the success and failure log. Done when the test mailbox shows matching item counts, folders, calendar entries and contacts on an Outlook client and a phone, and the failure log is reviewed.
Run a shared calendar and resource test
The collaboration owner creates a shared calendar, a meeting room resource and a delegated mailbox, then has users in different time zones book, accept, decline and reschedule meetings from Outlook, a web client and a phone. Include a free and busy lookup across two groups and a resource conflict check. Ask each vendor to show how resource booking and permission handling work, since SOGo documents resource sharing with permission handling and grommunio's calendar behavior should be verified against your own rules. Done when every booking scenario produces the same result on all client types and the test results are signed off by the business owner of the calendars.
Confirm license and support terms in writing
The procurement lead and legal reviewer collect the license and support terms for the chosen platform and any paid tier you might need. Verify which features sit in each edition. grommunio's public pricing lists a free Community package for up to 5 users without manufacturer support, paid per-user tiers from 6 users, and custom Enterprise pricing from 1,000 users, with licenses sold only through certified partners. OX App Suite notes that some modules may carry separate fees set in the license agreement, and SOGo links to premium support from Alinto alongside community support. Ask for a quote built from the written scope, and confirm support windows and upgrade policy in the contract. Done when the quote, license terms and support scope are on file and match the pilot.
Set a go or no-go checkpoint
The steering group reviews the pilot evidence against the criteria agreed in the first step: client coverage, directory behavior, operating skills, migration results, calendar outcomes and contract terms. Record each criterion as met, partly met or not met, with the named owner for any open item. A go decision names the rollout owner and the rollback path; a no-go decision names what would need to change for the platform to return to the shortlist. Done when the written decision is filed with the pilot evidence, so the choice can be audited later.
What buyers ask before choosing groupware and hiring help
What drives the cost of running grommunio or SOGo, and what is one-time versus recurring?
Software licensing is only one line. For grommunio, the published Community package covers up to 5 users without manufacturer support, while Basic, Plus and Business are priced per user per month from 6 users, with licenses sold only through certified partners. The one-time work is installation, directory integration, migration and client testing. Recurring costs include licenses or support subscriptions, hosting, backups, patching and the staff time to run them. For SOGo, the software is free under GPL and LGPL, and premium support is available from Alinto, so the recurring cost is mostly infrastructure and administration. Ask any vendor or partner to split the quote into one-time project work, licenses or support, and ongoing operations.
Can a team run grommunio or SOGo without an implementation partner?
Yes, a capable in-house team can run either platform, but the decision depends on the migration and client work you need to absorb. SOGo is a standalone groupware server with IMAP, CalDAV, CardDAV and ActiveSync support, and it is often deployed beside mail servers such as mailcow, which ships SOGo as its webmailer and CalDAV and CardDAV interface. grommunio is an appliance built on openSUSE, delivered as ISO or OVA with a setup wizard, and it also documents manual and container installation. A team moving off Exchange still needs Active Directory or LDAP alignment, Outlook client testing and a mailbox migration plan. If those skills or staff hours are missing, a fixed-scope engagement with written deliverables can cover them. DeployOpen implements and supports self-hosted platforms in the client's own infrastructure.
What should a groupware implementation quote include?
A useful quote lists the scope in writing before work starts, with each item tied to a deliverable. Ask for these parts:
- Architecture and sizing, including the platform version, database and storage design
- Directory integration with Active Directory or LDAP, including sign-in and address book behavior
- Migration scope: source system, number of mailboxes, calendars and contacts, and how exports and imports are validated
- Client testing for Outlook, iOS and Android, with named test users and the protocols each client uses
- Hardening, backup and restore testing, and documentation
- Support tier, response expectations and what happens after go-live
DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope.
How long does a groupware pilot take?
Duration depends on the drivers, not a fixed number. The main factors are the number of users in the pilot, how many Outlook and mobile client types must be tested, whether directory integration is already in place, the size of the mailboxes being moved, and how many calendars, shared resources and delegations need to keep working. Mailbox export time depends on data volume and the source system's throughput, so it should be measured during planning rather than assumed. Ask any partner for a timeline tied to a written scope and a named set of test users, and check which milestones depend on your own approvals or access.
What does the client team need to provide for a groupware project?
Most of the risk sits in access and test coverage, so prepare these before work starts:
- Active Directory or LDAP access, with the service accounts needed for sign-in and directory lookups
- Exchange administrator access, if migrating from Exchange, including permission to run the Exchange Management Shell
- A shared folder that Exchange can write to and the grommunio server can mount, which the grommunio migration documentation requires
- Scheduled time for mailbox export, which can run for a long period on large mailboxes
- Outlook test users across the versions your organization uses, plus iOS and Android test devices
The grommunio migration guide also requires the same LDAP or Active Directory source for both systems. Confirm each item against your environment before the project plan is signed off.
Does Zimbra's V10.1 license key or a FOSS build change the groupware decision?
It changes the cost and support model, so verify it before you decide. The Zimbra download page offers Zimbra Collaboration Daffodil version 10 and states that a new V10.1 license key is required to run it. Zimbra's zm-build repository holds scripts to create a FOSS build of Zimbra Collaboration, with examples for 10.1.0 and 10.0.8, but users compile that build themselves rather than downloading a package. That means your team owns the build pipeline, testing, patching and any support you arrange. Before comparing it with grommunio or SOGo, confirm the current license terms with Zimbra, check the build's maintenance status, and count the internal effort a self-compiled stack will need over its life.
Which option should an engineer evaluate first for Exchange compatibility?
Start with the client protocols your users actually depend on. grommunio states that organizations can keep their Microsoft Outlook clients through MAPI/HTTP, EWS and Exchange ActiveSync support, and its Gromox server implements RPC/HTTP (Outlook Anywhere), IMAP and POP3. SOGo provides native Microsoft ActiveSync support for phones and tablets and offers Outlook compatibility through the Outlook CalDav Synchronizer. Test calendar sharing, free and busy lookups, delegations and shared mailboxes on each client type, because these are where compatibility gaps tend to appear. Record each test result in the project plan so the decision rests on evidence from your own environment.
What operating work recurs after groupware go-live?
Recurring work falls into four areas: patching the groupware server and its operating system, maintaining the database and storage layer, monitoring mail flow and directory sync, and handling user changes such as joiners, leavers and new devices. grommunio is delivered as an appliance, which can reduce installation work, but it still needs updates and backup verification. SOGo runs on the stack you assemble around it, so the team owns more of the integration. Ask any partner or vendor which upgrades they will run, how restores are tested, and whether support or retainer work is priced separately from the initial project.
How DeployOpen scopes groupware selection and implementation
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so groupware choices are tested against your directory, mail flow, client mix and hosting constraints before any commitment. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory current Exchange, Outlook and mobile client use, plus the directory (LDAP or Active Directory) groupware must authenticate against.
- Confirm which mail, calendar and contact features users rely on, and which Outlook or ActiveSync behaviors must survive the move.
- Agree the written scope, deliverables and timeline for the chosen platform, including which edition or license terms the work assumes.
How we build
- Size the database, file storage and mail or sync components against the platform's documented requirements, then confirm them with the vendor.
- Configure directory integration, client access paths and backup routines in a test environment that mirrors your production network.
- Test mail flow, calendar sharing, contact sync and mobile clients with a pilot group before any mailbox moves.
How we hand over
- Document the deployed architecture, configuration decisions, access model and the runbooks your administrators will use day to day.
- Run a migration rehearsal with logged success and failure reports, so mailbox moves can be checked and resumed if needed.
- Deliver operational handover sessions covering upgrades, backups, restore tests and the items your team owns after go-live.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial implementation.
- Plan upgrades around the vendor's published support windows, so your team knows which release line is maintained and when to move.
- Ask for a written quote that lists the scope, the licensing responsibilities and which recurring support items are included.
