Migrate from Google Workspace to openDesk: what the move involves
A public sector or regulated buyer who needs Gmail, Drive, Docs, Meet and Chat outside a US-operated cloud should treat openDesk as a platform the organization runs itself. It is a Kubernetes-based suite, so the migration is a platform build plus a data move, not a login change. Users keep working while the platform team stands up the stack, maps accounts and imports content into it. The work is usually done by an internal platform team with an implementation partner. The platform team owns the Kubernetes cluster, the ingress controller, cert-manager, storage and the external production services, while the partner typically helps with deployment, identity integration and cutover planning. The openDesk deployment repository describes the Helmfile and Helm model in detail. Before any timeline is set, confirm with your own platform team how many services you can run and staff, because that, not the software, sets the pace. Ask for a written scope that names each component and each data source. The risk sits in the data move and in the production baseline. The evaluation footprint is small, but production expects PostgreSQL, MariaDB, Redis, an SMTP relay, ClamAV, object storage and a TURN server to be provided as production-grade services. Plan the Google export window around the admin Data Export timing, which depends on the account age and the bucket retention rules covered in the sibling export guide. Decide early whether to use openDesk Enterprise Edition for production, since ZenDiS recommends it for support and patches.
Which Google Workspace capabilities map cleanly to openDesk
This table maps each Google Workspace capability to the openDesk component that typically takes it over, and marks it as clean, needs rework or gap. Read the status as a starting point for scoping: every row still needs a pilot against your own tenant, domain, policies and users before you commit to a migration plan.
| Google Workspace capability | openDesk component | Status | What to confirm |
|---|---|---|---|
| Gmail mail and Google Calendar | OX App Suite (groupware, email and calendar) | Needs rework | Confirm mail import path, calendar sharing model and how mailbox data moves from the Data Export or IMAP sources with your team |
| Google Drive files and sharing links | Nextcloud (files) | Needs rework | Check that shared drive structure, link sharing and permissions map to Nextcloud groups and folders, and plan for links that will break |
| Google Docs, Sheets and Slides editing | Collabora (web office) | Needs rework | Test conversion of native Google files to Office or OpenDocument formats and confirm co-editing behavior for your largest documents |
| Google Chat spaces and direct messages | Element with Nordeck widgets | Needs rework | Confirm how Chat history from the Data Export is carried over, since chat content is not a direct import into Element |
| Google Meet video meetings | Jitsi | Clean | Confirm TURN server and network requirements for your users, and test with external participants |
| Google Workspace identity and user directory | Nubus (portal and IAM) | Needs rework | Confirm how users, groups and SSO are provisioned and whether federation with an external identity provider fits your model |
| Google Workspace admin policies (Workspace-specific settings) | No direct equivalent | Gap | List every admin policy in use, such as device, data region and app access rules, and confirm each has a documented replacement or a decision to drop it |
| Apps Script and Sheets-based automations | No direct equivalent | Gap | Inventory scripts and automations, then confirm with the vendor and your development team which ones need rewriting or an alternative workflow |
| Google Vault style retention and eDiscovery | Not covered by a single openDesk component | Gap | Confirm your legal hold and retention needs with your compliance team and plan a separate archive approach if required |
Which Google data exports cleanly and what must be rebuilt
Google Workspace data leaves through two different routes, and several things never leave as files at all. Plan the export window around the admin Data Export and per-user Takeout, then size the work for identity, shared access and API integrations, which must be rebuilt against openDesk components.
Admin Data Export tool
The super administrator runs Data Export for the whole organization, producing zip files of Gmail, Drive, Chat and Calendar delivered to a Cloud Storage bucket. The admin account must be at least 30 days old, and the default bucket is deleted after 60 days, so download and verify every archive before that deadline. Ask whether your edition and admin account meet the requirements before the window opens.
Per-user Takeout and admin restrictions
Individual users can export their own Gmail, Drive documents and Calendar data through Google Takeout. Workspace administrators control whether users can use it, so confirm the setting early. Takeout covers personal scope only, so it cannot replace an organization-wide export for mailboxes and files owned by departed staff.
Identity federation through Nubus or an external IdP
openDesk authenticates users through Nubus for portal and identity management, or through a federated external identity provider. Decide which source of truth owns accounts, groups and MFA before mailboxes are created, because Gmail addresses and Google sign-in do not transfer. Confirm the federation approach in the openDesk federation documentation for your identity provider.
Shared drives and sharing links
Google shared drives and link-based sharing do not map one to one onto Nextcloud folders and permissions. Inventory which folders are shared with groups, which links are public, and which files have external collaborators. Each permission must be recreated in openDesk, and public links should be reissued or retired rather than copied blindly.
Google Docs, Sheets and Slides conversion
Native Google files are not stored as Office documents, so they must be exported to formats the openDesk web office can edit, such as .docx, .xlsx and .pptx. Formatting, comments and suggested edits can shift during conversion. Test a sample of complex documents with the users who own them before committing to a cutover date.
Integrations that call Google APIs
Apps Script add-ons, scheduled jobs, Gmail filters, Calendar integrations and third-party SaaS connectors that call Google APIs stop working when the tenant is retired. Each one must be rebuilt against openDesk components such as the OX App Suite, Nextcloud or the openDesk APIs, with new credentials. Build an inventory of these integrations before the export window opens.
The migration sequence from inventory to decommission
This sequence moves Google Workspace data and users to openDesk in controlled stages, so each team can verify its data before the old tenant is shut down. Each step produces a written artifact that the next step depends on.
Inventory users, data and sharing
Start by listing every Google Workspace user, shared drive, Group, mail-routing rule, third-party app connection and the Google Chat spaces in use. Ask a super administrator to confirm the admin account that will run the export is at least 30 days old, because the Data Export tool requires that. Record which data sets must move, which can be archived and which owners must approve retention. The output is a signed inventory that lists owners, data volumes and the openDesk component that will receive each data set.
Schedule the Data Export window early
Run the organization-wide Data Export early, because exports typically take about 72 hours but can take up to 14 days. Export the zip files to a Cloud Storage bucket and download them before the default bucket is deleted after 60 days. Plan the window so that delays do not push the migration past the bucket deletion date, and note that user Takeout is a fallback for individual accounts only. The output is a verified local copy of every archive with checksums recorded.
Stand up the openDesk evaluation environment
Build a Kubernetes cluster that meets the documented requirements, including a supported version, ingress controller, cert-manager and Helmfile-based deployment. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, but production needs external PostgreSQL, MariaDB, Redis, object storage, an SMTP relay, ClamAV and a TURN server. Confirm the Community or Enterprise Edition choice with ZenDiS-aligned partners before production. The output is a running evaluation system with tested login and mail flow.
Pilot with a small user group
Choose a small group of users who represent the main workflows, such as mail, shared documents and calls. Import their mail, calendar and files into the openDesk components that cover them, and convert Google-native Docs, Sheets and Slides to Office or OpenDocument formats in Collabora. Ask pilot users to test sharing, mobile sync and meetings for a fixed period agreed in your project plan. The output is a pilot report listing defects, workarounds and any data loss, with each item assigned to an owner.
Run old and new in parallel
Keep Google Workspace active while users work in openDesk for their daily tasks, and synchronize changes from the export where your tooling allows. Route inbound mail so both systems receive messages during the transition, and check spam filtering, deliverability and DNS records. Track open issues daily and confirm that each data set in the inventory has been reconciled. The output is a reconciliation sign-off per data set, with the list of any items that still need manual handling.
Cut over users and shared resources
Move the remaining users in agreed batches, update mail routing, calendar links, Meet and Chat bookmarks, and shared drive permissions. Communicate the new addresses and sign-in path to every user before each batch, and keep a rollback plan for mail routing until the batch is confirmed. The output is a cutover log showing each batch, its date, the owner who approved it and the open issues carried forward.
Decommission Google Workspace
After the parallel run closes and archives are verified, remove Google Workspace licenses, disable connected apps and revoke domain delegations. Keep an offline, access-controlled copy of the export archives under your retention policy, and confirm with legal and compliance owners what must be retained. The output is a decommission record that lists revoked services, retained archives, their location and the date each retention period ends.
What drives cost and duration in a Google Workspace to openDesk move
This table lists the main factors that raise or lower the cost and time of moving from Google Workspace to openDesk, with how to keep each one in check. Read it as a checklist to bring into scoping, since most of these drivers are set by your own user base, data and integrations rather than by the software. The evaluation minimum of 12 x64 cores, 32 GB RAM and more than 10 GB disk is a starting point for testing only, not a production sizing.
| Driver | Why it moves cost or effort | How to keep it down |
|---|---|---|
| User and mailbox count | Mailbox and account volume drives the size of the groupware migration, the number of accounts to provision in the identity layer and the user training load. | Migrate in waves by department, and confirm with the vendor how user and mailbox volumes map to the production sizing before the quote. |
| Data volume in Drive | Large Drive trees extend Data Export or Takeout run time, increase object storage needs in openDesk and lengthen file validation after import. | Archive or delete stale content before export, and confirm the object storage capacity needed for production with your platform team. |
| Shared drives and sharing links | Each shared drive needs a matching structure and permissions in Nextcloud, and broken or external sharing links must be reviewed one by one. | Inventory shared drives and external shares early, and map them to groups rather than individual users. |
| Integrations to rebuild | Apps, scripts, calendar feeds, SMTP relays and single sign-on connections that point at Google must be reconfigured or replaced, which is often the largest unplanned effort. | List every integration before scoping, and confirm with the vendor which identity federation path your external identity provider supports. |
| Kubernetes platform readiness | openDesk requires a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile. Missing platform pieces add work before any application is installed. | Confirm cluster version and supporting components against the requirements documentation before scoping, and note that OpenShift is not a tested target. |
| Production services around openDesk | The evaluation footprint does not include PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage or a TURN server, all expected for production. Each one adds build, backup and monitoring work. | Reuse existing enterprise services where approved, and ask for each external service to be listed as a separate scope item in the written quote. |
| Community or Enterprise Edition | ZenDiS recommends Enterprise Edition for production. It adds SLA-backed support, patches and closed-source modules, which adds a recurring subscription cost but reduces the in-house support load. | Compare the support model you need against your in-house skills, and ask the vendor to price both editions in the same quote. |
What usually goes wrong and how to prevent it
Most failed moves off Google Workspace to openDesk come from timing, version assumptions and under-scoped infrastructure rather than from the software itself. The cards below cover the five risks we see most often in planning, and each one names the check that prevents it.
Missed export window
Google Workspace's Data Export delivers zip files into a Cloud Storage bucket, and the default bucket is deleted after 60 days. Exports typically take about 72 hours but can take up to 14 days, so a late start can leave you with no copy at all. Schedule the export with buffer, copy the archives to your own storage immediately, and confirm the bucket retention in your own account before you rely on it.
Treating major upgrades as in-place
openDesk plans major releases annually in Q3, and in-place upgrades between majors are not guaranteed. Treating a major release as a routine patch can break bundled components that depend on each other. Keep a staging environment that mirrors production, and confirm the upgrade path with ZenDiS release notes before you schedule any cutover-adjacent change.
Skipping minor versions
Only the latest minor version is supported, and skipping several minor versions may require intermediate steps. Teams that freeze a deployment during a long validation period often find they must upgrade across several releases at once. Record the installed version, track monthly minor releases in a calendar, and plan one upgrade step per cycle so the target stays on a supported version.
Underestimating production services
The evaluation footprint is not a production footprint. Production openDesk expects external, production-grade PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each is a separate system with its own backup, patching and staffing needs. Ask your integrator to list every external service in the written scope, with an owner and a recovery target for each.
Mail deliverability at cutover
Moving a company domain to new mail infrastructure can send legitimate messages to spam or bounce them. Sender reputation, SPF, DKIM and DMARC records, the SMTP relay and reverse DNS all affect delivery. Warm up the new sending path well before cutover, keep the old mailbox active during overlap, and test delivery to major external providers and to your own partner domains before you change the MX record.
How the migration changes by organization type and starting point
Public administrations with a federal or national mandate are the closest fit for openDesk, because the suite was built for that context and is developed by ZenDiS, a federally owned company. The planning question is less whether the suite covers the work and more how much of the bundle the mandate requires and who supports it in production. Evaluation sizing is a starting point only, and a production estate needs external services and an Enterprise decision made early.
- Edition decision: ZenDiS recommends the Enterprise Edition for production, which adds SLA-backed second and third level support and patches. Confirm with the vendor whether your procurement rules accept a SaaS or on-premises Enterprise delivery.
- Components that matter most: Nextcloud for Drive, OX App Suite for Gmail and Calendar, and Collabora for Docs and Sheets usually carry most of the user-facing change. Element and Jitsi replace Chat and Meet.
- Identity and federation: Plan the Nubus identity layer and any federation with an existing identity provider before user migration starts, since it shapes every other cutover step.
- Effort shift: Work moves from licensing and tenant administration to operating a Kubernetes estate with external databases, mail relay and object storage.
Before committing, ask for a written scope that names each bundled component, the Enterprise features you depend on, and who carries upgrade work between annual majors.
A regulated private firm, such as a bank, insurer, healthcare provider or critical infrastructure operator, usually moves for a data residency or control requirement rather than a mandate. The suite is the same, but the decisions center on where data and keys sit, which components touch regulated records, and what evidence the compliance team can show. DeployOpen can prepare systems and evidence for assessments, but independent auditors issue any audit report.
- Residency design: Choose the hosting location and confirm that every bundled component, including the external PostgreSQL, Redis, object storage and SMTP relay, runs inside the approved boundary.
- Scope of data: Mail and Drive often hold the highest-risk records, so sequence their migration after the controls for access logs, retention and backup are tested.
- Edition and support: Compare the Community and Enterprise Edition support model against your third-party risk requirements, and confirm the patch cadence for each bundled component.
- Effort shift: Expect more time on security review, access design and evidence collection, and less on feature parity with Google.
- Retention: Google's default bucket deletion window does not apply to your own storage, so plan where export archives are kept and for how long.
Ask the vendor and your auditor which controls each component provides natively and which you must configure yourself.
A mid-size organization with a small platform team faces the largest gap between the suite's footprint and its staffing. openDesk is a full stack, not a single application, so the question is whether the team can run Kubernetes, ingress, certificate management and the bundled services well enough to keep upgrades on schedule. For many organizations of this size, a narrower path built on Nextcloud with Collabora Online and OX App Suite may fit better than the full bundle, and the openDesk comparison should be weighed against that option.
- Staffing: Check whether the team already operates a CNCF-certified Kubernetes cluster at the required version, with ingress, cert-manager and an RWO volume provisioner.
- Partial adoption: Decide whether you need every component on day one, or whether Drive and documents can move first while groupware and chat follow.
- Upgrade rhythm: Major releases arrive yearly, minor releases monthly, and in-place upgrades between majors are not guaranteed, so budget regular upgrade windows.
- Support model: A managed or retained support arrangement may replace hiring specialists, and that trade-off should be priced from a written scope.
- Effort shift: Most work is front-loaded in platform build and user migration, then recurs as upgrade and patch operations.
Ask for a sizing estimate tied to your user count and the components you choose, and confirm which parts of the team's time the quote covers.
Questions buyers ask before moving from Google Workspace to openDesk
What drives the cost of moving from Google Workspace to openDesk?
The cost is driven by the Kubernetes platform you run openDesk on, the production services you must supply, the openDesk edition you choose, and the people who plan and migrate the data. openDesk itself is open source under Apache 2.0 for the deployment automation, and each bundled component keeps its own license. Recurring costs typically include infrastructure, the external production services openDesk expects (such as PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay and object storage), staff time, and any subscription. Ask ZenDiS or your integrator for a quote that separates one-time migration work from recurring operations, and ask which Enterprise Edition support tier is included. Compare this with your current Workspace per-user fees, which you should take from your own contract.
How long does a migration to openDesk take?
The duration depends on the volume and shape of your data, the number of users, how many shared drives and sharing links you have, and whether the target platform is already running. The vendor publishes no migration timeline in the facts available here, so treat any duration as something to agree in writing. Export timing is a fixed constraint: Google's Data Export can take about 72 hours and up to 14 days, so that window alone shapes the plan. Ask for a scope that lists export runs, test imports, cutover, and rollback, and confirm the expected duration with ZenDiS or your integrator against your own data sample.
What does our team need to supply before the work starts?
Before work starts you need a CNCF-certified Kubernetes cluster at version 1.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. You also need production-grade external services, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Identity planning matters too, because openDesk supports federation with an external identity provider. Your team should also supply a complete user and group list, domain and DNS records, a data classification of what moves, and named owners for each business unit. openDesk is tested on kubespray clusters and not on OpenShift, so confirm your platform before scoping.
Can our own team migrate from Google Workspace to openDesk without a partner?
Your team can do it alone if it already runs Kubernetes at production quality and has people who can operate Helm, Helmfile, identity federation and mail routing. The deployment is documented in the openDesk repository, but the production services, backups, security hardening and data migration all need owners. A first step is an evaluation deployment, which needs 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, with ARM not yet supported. DeployOpen can plan, implement, integrate, harden, back up and document a deployment in your own infrastructure under a fixed scope, and it offers retainers for ongoing upgrades. Decide the split of work in writing before you start.
When do we need openDesk Enterprise Edition instead of Community Edition?
ZenDiS recommends Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. 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 with advanced full-text search, and OpenProject Enterprise add-ons. Community Edition suits evaluation and testing. Confirm the Enterprise pricing, SLA terms and whether it is sold as SaaS or for on-premises use directly with ZenDiS.
How should we plan the Google Data Export window?
Plan the export around three Google constraints. The super administrator account must be at least 30 days old, exports typically take about 72 hours but can take up to 14 days, and the default Cloud Storage bucket is deleted after 60 days. Start with an export of a test subset, verify that Gmail, Drive, Chat and Calendar files open correctly, then schedule the full run well before your cutover date. Copy the zip files to storage you control before the 60-day deadline. Keep Gmail and Drive running in parallel until the openDesk import is verified, and confirm the current Data Export terms with Google because they can change.
What happens to shared links and Chat history after the move?
Google's Data Export carries Chat data and Drive files, but sharing links and permissions do not move automatically to another platform, so each shared item needs a mapped owner and permission in openDesk. Chat history is exported as data, and openDesk uses Element with Nordeck widgets for chat, so confirm with ZenDiS which Chat formats can be imported and how history will be presented to users. Plan a notice to users with the new links and a list of shared folders to recreate. Test a sample of shared links and Chat threads before cutover, and document the results as migration evidence.
Does openDesk cover Gmail, Drive, Docs, Meet and Chat?
openDesk covers the same work areas through different components. Nextcloud handles files, OX App Suite handles groupware for mail and calendar, Collabora provides web office for documents, Jitsi provides video meetings, and Element with Nordeck widgets handles chat. Each component has its own feature set and admin model, so compare them feature by feature with your current Workspace use. Confirm details such as document co-editing, calendar sharing and mobile sync with ZenDiS or your integrator before you commit to a migration scope.
How DeployOpen scopes and runs a Google Workspace to openDesk migration
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, which for an openDesk move means the cloud accounts, data center or air-gapped network where the Kubernetes cluster will run. Most engagements are fixed-scope. Before any work starts, the scope, deliverables and timelines are agreed in writing, and a quote follows from that written scope. For a buyer comparing implementation partners, the useful first request is a written scope that names each openDesk component in use (Nextcloud for files, OX App Suite for groupware, Element for chat, Jitsi for meetings and Collabora for the web office), the identity source that Nubus will federate with, and which Google Workspace data sets are in the migration wave.
The scope also needs to settle the decisions that drive most of the work. Confirm whether the target is openDesk Community or Enterprise Edition, since ZenDiS recommends Enterprise for production, and whether the cluster meets the stated requirements, including the 12-core, 32 GB evaluation minimum and the external production services such as PostgreSQL, Redis, an SMTP relay and object storage. The export window should be written into the plan with the dates, bucket owner and retention settings in hand, so that data lands in a bucket that will not be deleted before the import is verified. Ongoing support, upgrades and continuous testing are available as retainers, which matters because openDesk ships major releases once a year and minor releases monthly, and in-place upgrades between majors are not guaranteed.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies, so the written scope should list the evidence the client's assessor will expect, such as configuration baselines, access reviews and backup test records, and state who produces each item. Ask for the list of deliverables in the same document as the timeline and the acceptance criteria. Any figure you intend to rely on for budgeting, including duration or effort, should be confirmed in that written scope rather than inferred from this page.
