When Google Workspace or openDesk is the better choice for your organization
Google Workspace stays the better choice when your organization wants a managed suite with little operating work, when its users depend on Gmail, Docs and Meet working the same way they do today, and when the renewal terms and data region options meet your requirements. openDesk fits when a public body or regulated buyer needs a sovereign, self-operated suite inside its own infrastructure, and when the team can run a Kubernetes platform and accept several bundled components with their own release cycles. The question is rarely which product is better in general. It is which operating model your organization can support for the next several years. Three decisions should settle the matter early. First, can your platform team operate Kubernetes at the level openDesk requires, including an ingress controller, cert-manager, Helm and Helmfile upgrades on a fixed cadence? If not, a managed Workspace tenancy or a partner-run deployment may fit better. Second, do you need a sovereign or on-premises suite because of law, procurement rules or data residency, or do you mainly need a cheaper or more flexible contract? Third, can you accept a bundled suite in which Nextcloud handles files, OX App Suite handles groupware, Element handles chat and Collabora provides the web office? Each component keeps its own license, so you inherit several upgrade paths.
Be cautious about the evaluation footprint. openDesk's documented evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and production expects external PostgreSQL, Redis, an SMTP relay, object storage and other services. Ask ZenDiS and your integrator what the production architecture costs in people and infrastructure, and whether the Enterprise Edition support model covers your SLA needs. openDesk's Enterprise Edition documentation lists the paid modules and support tiers you should compare against your current Workspace contract. Confirm the answer to each of these questions in writing before you commit to a migration window.
Which scenario favors Google Workspace and which favors openDesk
This table matches common buyer situations to the platform that usually fits better, with the reason tied to supplied facts about openDesk requirements, editions and lifecycle. Read each row as a starting point, then test it against your own staffing, data location and evidence needs.
| Scenario | Better fit | Reason |
|---|---|---|
| Small team with no platform operations staff | Google Workspace | openDesk needs a CNCF-certified Kubernetes cluster at v1.33 or later, plus cert-manager, an ingress controller and external production services. Without people to run that stack, a managed suite is easier to operate. |
| Public agency that must keep data in its own data center | openDesk | openDesk is designed for public administration and deploys into your own Kubernetes environment with Helmfile and Helm, keeping mail, files and chat under your control. |
| Regulated firm needing controlled admin evidence | openDesk, if the team can staff operations | openDesk ships a security document and a Enterprise Edition with SLA-backed support, but evidence comes from your own logging and configuration. Confirm what admin audit output each option gives your assessor. |
| Organization wanting Gmail, Drive, Docs, Meet and Chat with minimal change | Google Workspace | Users already work in these tools. openDesk covers similar ground through Nextcloud, OX App Suite, Collabora and Jitsi, but it requires retraining, new clients and a platform migration project. |
| Public sector buyer needing vendor-backed production support | openDesk Enterprise Edition | ZenDiS recommends Enterprise Edition for production, with SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. |
| Buyer that must avoid a US cloud provider for all content | openDesk | Google Workspace data location depends on edition and region options. openDesk runs in infrastructure you choose, so confirm the hosting location in your own environment. |
| Team that needs fast, self-service admin changes at small scale | Google Workspace | Google's admin console is managed for you. With openDesk, upgrades follow ZenDiS release management: annual majors, monthly minors and only the latest minor supported. |
| Migration planned on a short timeline with Google Data Export | Plan before choosing openDesk | Data Export takes about 72 hours and can take up to 14 days, and the default bucket is deleted after 60 days. Build a full openDesk evaluation and cutover plan before committing to a date. |
Community versus Enterprise Edition: what production support changes
ZenDiS recommends openDesk Enterprise Edition for production, and the reason is operational rather than legal. Both editions use the same open-source core licenses, so the bundled components such as Nextcloud (AGPL-3.0), OpenProject (GPL-3.0) and Collabora (MPL-2.0) carry the same terms in either edition. What Enterprise adds is a closed-source module layer, an Enterprise-only registry and license file that the deployment must reference, and SLA-backed second and third level support and patches. Those patches matter most for components where Enterprise ships security fixes on a separate track, such as Nextcloud Enterprise security patches. Enterprise is sold either as SaaS or for on-premises installation, so the first decision is where the platform runs and who holds the license file.
The Enterprise-only features are the practical test. They include Collabora branding and automatic load scaling, the Element AdminBot, GroupSync and Admin Console, the Nextcloud Guard app, OX S3 storage and advanced full-text search, OpenProject Enterprise add-ons, and XWiki Pro apps. For a Google Workspace replacement, GroupSync and the Admin Console determine how identities and group membership stay aligned with your directory, and automatic load scaling determines how the web office behaves at peak editing. Ask ZenDiS and your integrator which of these you need on day one, and confirm in writing which features your chosen edition includes, since the list changes between releases.
Community Edition can suit a non-production evaluation, such as a proof of concept on the 12-core, 32 GB minimum hardware that the requirements list for evaluation, provided you accept that no vendor SLA or Enterprise-only patch track applies. It is not a basis for live Gmail, Drive or Chat data. Before you move production users, plan the external services that openDesk expects for production, such as PostgreSQL, SMTP relay and object storage, and confirm with your integrator who supports each component. Ask for a quote that separates Enterprise subscription fees, integration and hardening work, and the internal staff time needed to run upgrades.
What the 12-core, 32 GB evaluation minimum means before production
The openDesk evaluation footprint is a starting point for a test installation, not a production sizing. Each card below covers one part of what a team must plan for before moving real mailboxes and documents onto the platform.
Evaluation hardware floor
The evaluation deployment needs 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk. ARM hardware is not supported yet, so Apple silicon or Arm servers cannot be used for this footprint. Treat these figures as the minimum for a test environment and ask ZenDiS or your integrator how load, user count and retention change the sizing for production.
Kubernetes version and cluster
openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later. It is tested on kubespray clusters and not on OpenShift, so a Google Workspace migration team with an existing OpenShift platform must confirm a supported cluster before procurement. Check the cluster version against the release you plan to deploy, since in-place upgrades between majors are not guaranteed.
Ingress, certificates and storage
The platform expects an ingress controller, either haproxy-ingress or the deprecated Ingress nginx, plus cert-manager for certificates and an RWO volume provisioner for persistent storage. Each of these is a cluster-level component your team must install, patch and back up. Confirm which ingress and storage classes your infrastructure team already supports, because they affect how users reach webmail, file sync and the web office.
Helm and Helmfile toolchain
Deployment uses Helmfile 1.0.0 or later with Helm 3.17.3 or later, but below Helm v4. Engineers who run the deployment must pin these versions in their build pipeline and keep the same toolchain for upgrades. Mismatched Helm major versions are a common reason a first deployment fails, so record the exact versions in the handover documentation.
External production database and cache services
For production, openDesk expects you to supply PostgreSQL 15, MariaDB 10, Redis 7, Memcached and Cassandra as external, production-grade services rather than running them as evaluation pods. Each one needs its own backup, patching and high availability plan. Ask your operations team who owns these services and how they are monitored before committing to a production design.
Mail, malware scanning and object storage
Production also needs an SMTP relay for outbound mail, ClamAV reached over ICAP for malware scanning of uploads, an object storage service and a TURN server for video and calls. Mail relay and TURN are often outside the Google Workspace migration team's experience, so assign owners early. Confirm that your object storage is S3-compatible and that your ClamAV and TURN deployments meet your network and data residency rules.
How openDesk licensing and release cadence affect upgrade planning
The licensing of openDesk has two layers, and upgrade planning depends on both. The deployment automation, built on Helmfile and Helm charts, is licensed under Apache-2.0. Each bundled component keeps its own license: AGPL-3.0 for Nextcloud and Nubus, GPL-3.0 for OpenProject and MPL-2.0 for Collabora. Your legal and procurement team should therefore review each component's obligations separately, particularly if you modify Nextcloud or Nubus code or distribute changed builds to partner agencies. If you choose openDesk Enterprise Edition, confirm with ZenDiS which parts are closed-source modules and how the Enterprise-only registry and license file affect your ability to run the stack in an air-gapped network.
The release model sets the upgrade rhythm. ZenDiS plans major releases annually in Q3, minor releases monthly and patch releases on demand. Only the latest minor version is supported, so an organization running an older minor version must plan to move forward before support lapses. In-place upgrades between major versions are not guaranteed, and skipping several minor versions may require intermediate steps. Build a staging environment that mirrors production, rehearse each upgrade against your own bundled components, and record which intermediate versions the release notes call for. Confirm the support window and the upgrade path in writing before you commit to a version.
At research time the latest release was v1.19.1, published on 2026-10-06, following v1.19.0 on 2026-10-01. A release published days apart signals that a fast patch cycle is in place, so budget regular change windows for a monthly minor and an on-demand patch. Ask your implementation partner how they will track upstream changes to each bundled component, test them against your identity federation and storage configuration, and document the rollback plan. Clarify who in your team owns each upgrade decision, and whether a retainer covering upgrades, testing and documentation is needed to keep pace with that cadence.
How a move from Google Workspace to openDesk runs in phases
The sequence runs from confirming the Kubernetes platform through evaluation, production planning, data export, import, pilot validation and cutover, so each phase closes with a check the client can sign off.
Confirm the Kubernetes platform and requirements
Your platform team checks that the target environment meets the openDesk requirements: a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. Confirm that your distribution is one openDesk is tested on, since the project documents kubespray clusters and states it is not tested on OpenShift. Done when a written requirements check lists every item as met or as a gap with an owner.
Run an evaluation deployment
Your platform staff deploy openDesk with Helmfile and Helm into a non-production cluster. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet. This phase tests the bundled components, identity federation and admin tasks, not production load. Done when the team can sign in, create test users and send and open files in each component you plan to keep.
Plan the production services and support model
Decide which external services your production deployment will run, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Decide whether to run openDesk Community Edition or Enterprise Edition, which ZenDiS recommends for production and which adds SLA-backed support. Ask vendors and ZenDiS to confirm current terms in writing. Done when a signed-off architecture document and support decision exist.
Plan the export window around Data Export limits
Your Google Workspace super administrator checks that the admin account is at least 30 days old, since Data Export depends on it. Google's documentation says exports typically take about 72 hours but can take up to 14 days, and the default Cloud Storage bucket is deleted after 60 days, so copy the archive to your own storage before that point. Schedule a freeze date for new mail and file changes. Done when the export is scheduled and the archive location is owned by your staff.
Convert and import mail, files and calendars
Export the Gmail, Drive and Calendar archives, then convert native Docs, Sheets and Slides files into formats Collabora and OX can open. Import mail and calendars into OX App Suite, load files into Nextcloud and map Google sharing links to Nextcloud shares. Your staff own the mapping rules and exception list, and DeployOpen can script and repeat the import. Done when a sample of mailboxes and folders matches the source counts and spot checks pass for shared content.
Validate with pilot users
Move a small group of pilot users first and have them run their normal work for an agreed period. They check mail delivery, calendar invites, file access, document co-editing and chat or video calls against the bundled Element and Jitsi components. Record defects with owners and retest. Done when pilot users confirm the core workflows and the open defect list has no unresolved blockers.
Cut over and retain a fallback
Switch mail routing, domain records and user sign-in to openDesk, then announce the change and retire the Google Workspace services on an agreed date. Keep the exported archive and the Google account until your records team confirms the retention position. DeployOpen can support the cutover and hardening, and your staff approve the change record. Done when all users sign in to openDesk, mail flows normally and the cutover record is signed.
Questions buyers ask before choosing openDesk over Google Workspace
What drives the cost of moving from Google Workspace to openDesk?
The main cost drivers are the Kubernetes platform you run, the production services openDesk expects you to supply, and the people who deploy and operate the stack. Google Workspace is a recurring per-user subscription, so its cost follows headcount and edition. openDesk is open source, but your costs recur through infrastructure, staff time and any support subscription you buy. Production needs PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, each with its own sizing and operating effort. Ask any vendor or partner for a quote built from a written scope that lists these components, the one-time migration work and the recurring support terms.
How long does a migration from Google Workspace to openDesk take?
Timing depends on data volume, the number of users, how much history you must carry over and how much of the production platform you already run. The openDesk requirements list external production services and a Kubernetes cluster at v1.33 or later, so the platform work often sets the critical path before any data moves. On the Google side, the admin Data Export tool runs for a window that the Google Workspace Admin Help describes as typically about 72 hours and up to 14 days, and the default Cloud Storage bucket is deleted after 60 days. Plan the export window around those limits, and confirm current figures in Google's documentation before you commit to a date.
Can our team deploy openDesk without outside help?
A team with strong Kubernetes and Helm experience can attempt an evaluation deployment alone, but the evaluation and production paths differ. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, with ARM not yet supported. Production adds stateful services, identity federation, mail delivery, backup and upgrade planning, and ZenDiS notes that in-place upgrades between major releases are not guaranteed. Ask whether your staff can own these tasks over time. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and supports self-hosted open-source platforms in your own infrastructure, typically under a written, fixed-scope agreement, and ongoing support is available as a retainer.
What does openDesk need from our Kubernetes and identity teams?
Your Kubernetes team must provide a CNCF-certified cluster at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. openDesk is tested on kubespray clusters and not on OpenShift, so confirm your platform before scoping. Your identity team should plan how users authenticate, since openDesk includes Nubus for portal and identity management and documents federation with an external identity provider. Agree on who owns user lifecycle, group mapping and certificates before deployment begins.
Do we need openDesk Enterprise Edition for production?
ZenDiS recommends Enterprise Edition for production. The Community and Enterprise editions share the same open-source core licenses, but Enterprise adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Enterprise-only features include Collabora branding and automatic load scaling, Element AdminBot, GroupSync and Admin Console, Nextcloud Enterprise security patches and the Guard app, OX S3 storage and advanced full-text search, OpenProject Enterprise add-ons and XWiki Pro apps. Decide whether your security and compliance requirements need the vendor-backed patch commitment, and ask ZenDiS or a partner to confirm which features your use case depends on.
How do Google Data Export and Takeout limits affect the plan?
Data Export is the admin route for organization-wide data, and Takeout is the per-user route. The admin account must be at least 30 days old, and only super administrators can run Data Export, which delivers zip files to a Cloud Storage bucket. Google's Takeout documentation says administrators control whether users can use it, so your policy determines whether individuals can export their own data. Build the plan around the export window, the 60-day bucket deletion and the need to download and verify archives before deletion. Check current limits in Google's documentation, because they can change.
Will openDesk cover every Google Workspace feature we use?
Not necessarily one for one. openDesk maps mail and calendar to OX App Suite, files to Nextcloud, documents to Collabora as the web office, chat to Element and video to Jitsi, while XWiki, OpenProject and CryptPad add knowledge, project and notes tools. Some Workspace features, such as Apps Script, Google-specific sharing behavior and third-party add-ons, may need redesign or may not carry over. Build a feature inventory from your current tenant and confirm each mapping in a proof of concept before committing to a timeline.
What recurring operating work the self-hosted suite adds
The recurring cost of openDesk is mostly operating work, not licences. On the Google side, the recurring line is the per-user Workspace subscription, and the cost question is which edition you need. Some controls your buyer may require, such as data region choices or client-side encryption, are tied to higher editions, so confirm the edition and per-user price in writing before comparing. On the openDesk side, the software is open source under Apache 2.0 for the deployment automation, and each bundled component keeps its own licence. The recurring costs are the Kubernetes cluster, the ingress, certificate and volume layers, the external production services that openDesk expects (PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server), backups, monitoring and staff time for upgrades.
The largest one-time cost is the migration itself: exporting from Google (the admin Data Export or per-user Takeout), converting files, moving mail and calendars, and running parallel operation. Ask any implementer for the export window and the bucket handling, because the Data Export tool's run time and the 60-day bucket deletion both set the schedule. Recurring work on the openDesk side includes applying monthly minor releases, since only the latest minor version is supported, and planning intermediate steps when you skip several minor versions. Major releases arrive annually in Q3, and in-place upgrades between majors are not guaranteed, so budget a test cluster and a rehearsal each year.
Enterprise Edition is the cost driver most likely to change your totals. ZenDiS recommends Enterprise Edition for production, and it adds SLA-backed 2nd and 3rd level support, Nextcloud Enterprise security patches and features such as the Guard app, GroupSync and the Admin Console. Ask ZenDiS or a partner to quote three items separately: the Enterprise subscription, the SaaS or on-premises delivery model, and any extra support tiers. Then ask for the staff-time estimate for running the stack in your own environment. Costs go up with the number of user groups, data volume, high availability and the number of external services you host yourself, and they go down when you use a managed service for the databases, object storage or mail relay.
How hosting and data control differ between the two options
Google Workspace is a Google-managed cloud service. The organization does not choose the servers, the operating system or the patch cycle, and hosting arrangements are set by Google's terms and the edition the organization buys. Administrators control users, sharing, device policies and data retention through the admin console, but the underlying infrastructure stays with Google. Exit is supported through tooling rather than through a self-managed copy of the platform.
- Managed hosting: Google operates the infrastructure, so hosting location, failover and platform patching are governed by Google's documentation and contract, not by the client's own change process.
- Admin controls: Super administrators can set sharing, device and retention policies centrally, and these settings are applied by Google across the tenant.
- Data regions: Confirm with Google which data regions and which edition apply to your tenant, since the regions available depend on the product and plan.
- Data Export: The admin Data Export tool produces zip archives of Gmail, Drive, Chat and Calendar data into a Cloud Storage bucket, and the admin account must meet the age and edition requirements in Google's documentation.
- Takeout: Individual users can export their own data through Takeout, and administrators decide whether users may use it.
Ask Google for written documentation of data location, subprocessors and deletion timing for your edition, and check the export timing and bucket retention before relying on either tool for an exit.
openDesk is an open-source suite that the client deploys and runs inside its own infrastructure, whether that is its cloud account, a data center or an air-gapped network. Data stays where the client places the storage, the databases and the object store, and the client holds the operational responsibility for hosting, backup, patching and access. ZenDiS publishes the deployment automation and component licenses, so the client can inspect what runs in its environment.
- Self-hosted placement: The client chooses the infrastructure and the storage locations, so the data residency decision sits with the client and its own architecture.
- Identity federation: openDesk documents how to federate with an external identity provider, so user accounts can remain under the client's existing directory and authentication policies.
- Security documentation: ZenDiS publishes security documentation in the deployment repository, which the security team should review against its own threat model before go-live.
- Production services: The evaluation minimum is not a production design, and production expects external, production-grade databases, an SMTP relay, object storage and related services that the client must operate.
- Support model: Community operation leaves hardening, backup and upgrades to the client, while the Enterprise Edition adds SLA-backed support and patches.
Confirm which openDesk services will hold personal data, where backups are kept, and who in your organization holds administrative rights over the Kubernetes cluster.
Hosting choices change which controls you inherit and which ones you must evidence yourself. With Google Workspace, Google's own assurance reports and contract terms cover the managed platform, and your evidence focuses on tenant configuration and user behavior. With openDesk, the client's controls cover the cluster, the storage, the network, the backups and the identity integration, so the evidence set is larger and sits in your own environment. Neither option makes an organization compliant by default.
- Inherited controls: Map which controls Google covers for your edition and which controls fall to your team for each openDesk component.
- Evidence ownership: Under a self-hosted model, your team produces configuration records, access reviews, patch records and backup restore tests.
- Data location: Document data locations for each service and for each backup copy, including any support access from outside the operating jurisdiction.
- Assessment scope: Define the system boundary before the assessment, including the Kubernetes platform, the identity provider and the external services.
- Certification needs: DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Your organization must confirm its certification needs with its auditors and certification bodies.
Bring the list of required frameworks to your auditor before comparing the two options on evidence effort.
How DeployOpen helps evaluate, implement and migrate to openDesk
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Google Workspace to openDesk, we start with a written scope that matches your regulatory, data residency and export requirements.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which openDesk components would take over Gmail, Drive, Docs, Meet and Chat for your user groups.
- We confirm the Kubernetes cluster, ingress, storage and external services your environment can provide before design begins.
How we build
- We deploy the openDesk evaluation environment in your cloud account, data center or air-gapped network first.
- We plan production services such as PostgreSQL, SMTP relay, ClamAV, object storage and TURN separately from the evaluation setup.
- We integrate identity federation with your existing identity provider and test authentication before any user data moves.
How we hand over
- You receive documentation of the deployed configuration, the component versions and the upgrade path for your chosen release.
- We plan the export window around the Google Workspace Data Export timing and the bucket retention period, and run test exports first.
- We prepare compliance-ready evidence and controls for your assessors, without issuing audit reports or certifications ourselves.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can help you decide between the Community and Enterprise Edition by reviewing your support and patch requirements in writing.
- Upgrades between openDesk major releases may need planned intermediate steps, and we scope that work as a separate item.
