openDesk migration from Microsoft 365 or Exchange

What an openDesk migration involves

An openDesk migration maps each source workload to a specific target component, because openDesk is a suite of several systems. openDesk is a Kubernetes-based suite from ZenDiS, the federally owned German company that took over its development in January 2024. It bundles OX App Suite for mail, calendar and contacts, Nextcloud for files and Element for chat, along with other components. Exchange mailboxes and calendars move to OX App Suite, document libraries and file shares move to Nextcloud, and chat history from Microsoft 365 needs its own decision about what is kept and in what form.

Most public administration projects start from one of three triggers: an exit from Microsoft 365 or Exchange, sovereignty requirements for collaboration tools run inside state-controlled infrastructure, or consolidation of scattered file shares onto one platform. Each trigger changes the scope. An exit usually covers mail history and calendars for every user, while file share consolidation needs rules for which folders are migrated, archived or retired. Write the trigger down before the mapping starts, because it decides which workloads are in scope.

The migration cannot start until the target is running. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and production-grade external services such as PostgreSQL, Redis and an SMTP relay. Identity must also be in place, because every mailbox and file needs an existing openDesk user to attach to. Confirm with your architects which identity source applies to your directory, since Microsoft Entra ID requires Azure AD Domain Services before LDAP-based provisioning is possible.

Short answer: the platform build and the identity link are usually taken to a partner, while the content decisions and the cutover sign-off stay with the organization. A partner can deliver the cluster, the openDesk deployment and the directory import. Your team still decides which data moves, what is archived, which users belong in each pilot wave and when the business accepts the cutover. Ask for any quote to name these two responsibilities separately.

What the work includes

The migration runs as nine workstreams, each ending in a document or runbook your team keeps. The exact migration tooling and what it can move for each workload must be confirmed against your source versions before the plan is fixed.

Source inventory and data assessment

We catalog mailboxes, shared mailboxes, calendars, file shares, document libraries, chat history and the users and groups behind them, with size, age, ownership and external sharing. You receive an inventory report and a data assessment that flags items needing cleanup before any move. Confirm which Microsoft 365 or Exchange versions and hybrid setups are in scope.

Target mapping for mail and calendars

Mailbox folders, retention behavior, shared mailboxes, delegation and calendar invitations are mapped to their counterparts in OX App Suite. You receive a mapping document that records each source feature, its target equivalent and any loss or manual step. Confirm with the vendor which items, such as certain calendar metadata, can be carried across.

Files and libraries to Nextcloud

SharePoint and OneDrive libraries, file shares, version history, permissions and sharing links are mapped to Nextcloud folders, groups and shares. You receive a file mapping sheet covering path length limits, unsupported file names and permission translation. Confirm how version history and metadata columns will be handled for each library type.

Chat to Element

Teams channels, chats and their files are assessed for what can be exported and what must stay in the source for archive. Chat history rarely moves as a simple copy, so the decision is made per conversation type. You receive a chat transition decision record and a user communication plan. Confirm with the vendor what history, if any, can be imported into Element.

User and group provisioning

Identities, groups and mailbox attributes are planned for openDesk, including how the source directory feeds the openDesk identity provider. Entra ID needs a path through Azure AD Domain Services because it does not expose LDAP, so this choice shapes the whole schedule. You receive a provisioning runbook and an attribute mapping list. Confirm the directory type early.

Migration tooling and test runs

Migration tools are selected per workload and run against a copy of production data in a test environment. Each run measures throughput, error rates and item counts against the inventory. You receive a test report listing failed items, root causes and the remediation for each error class. Confirm what each tool can move for your exact source versions before committing to a method.

Pilot waves

A small group of users moves first, followed by larger waves sized to your help desk capacity and dependencies between teams. Each wave has entry and exit criteria, such as mail flow checks and sign-in verification. You receive a wave plan with user lists, owners and go or no-go gates. Mailbox size and shared resource dependencies usually determine the wave order.

Cutover and source decommissioning

The cutover covers the final delta sync, DNS and mail routing changes, and the switch of user access to openDesk. Decommissioning of the source follows only after retention and legal hold requirements are met. You receive a cutover checklist and a rollback procedure with defined trigger conditions. Confirm the retention rules with your legal and records teams before setting any shutdown date.

Hypercare after go-live

Support staff watch mail flow, sign-ins, sync errors and user tickets for an agreed period after each wave. Issues are triaged against the mapping document so that known losses are not reopened as defects. You receive a hypercare log, a closure report and a handover to your operations team. The length and staffing of hypercare should be agreed in the written scope.

What drives cost and duration

This table lists the factors that change migration effort for openDesk, why each one matters, and how to keep it under control before quoting.

Driver	Why it matters	How to reduce it
Mailbox and user count	Each mailbox is a separate move with its own validation, and user count sets the number of pilot waves and provisioning runs.	Group users into waves by department, confirm the in-scope list early and remove inactive or leaver accounts before the first move.
Mailbox and file volume	Large mailboxes and file shares lengthen synchronization windows and raise the risk of throttling or failed items during cutover.	Measure sizes per user, archive or delete old content, and move bulk file data in advance of the final sync.
Shared mailboxes	Shared mailboxes carry delegation, send-as and send-on-behalf rights that must be mapped to openDesk equivalents, which are often configured by hand.	Inventory every shared mailbox and its permissions, then decide which ones keep their function and which are retired.
Distribution lists and resources	Lists, rooms and equipment calendars feed routing and booking rules, so each one needs a target object and membership check.	Export membership and ownership, consolidate duplicate lists and confirm which resources must be recreated in OX App Suite.
Document versioning and permissions	Version history, sharing links and item-level permissions in SharePoint or OneDrive do not map one-to-one to Nextcloud, so the mapping needs review.	Set a rule for how much version history to keep, clean up broken or unused sharing links and review permissions on the top-level folders first.
Chat history expectations	Teams chat history is not a simple export, and the business need for old messages determines whether any migration is required at all.	Agree in writing whether chat history moves, is archived read-only or starts fresh in Element, and scope only what the agreed rule requires.
Number of source tenants or forests	Each Microsoft 365 tenant or Active Directory forest adds its own identity mapping, routing and cutover sequence.	Consolidate sources where the organization allows it, and document the mapping of each tenant or forest to openDesk before scoping.
Identity source (Entra ID, Active Directory or LDAP)	Entra ID does not expose LDAP, so the Nubus Directory Importer needs Azure AD Domain Services or another LDAP path, which is a major effort and cost driver.	Confirm early whether Azure AD Domain Services is available, or whether an existing Active Directory or LDAP source can feed the importer, and document the path before scoping.
Exchange hybrid	A hybrid setup means mail routing, free/busy and mailbox locations span on-premises and cloud, which complicates coexistence and cutover timing.	Decide the coexistence period and mail flow changes before scoping, and check whether on-premises mailboxes can be moved in the same waves.
Custom integrations	Line-of-business apps that send mail, read calendars or use SMTP relays must be found and repointed, and each one adds testing.	Build an inventory of applications and mail senders from logs and owners, then decide which integrations move and which are retired.
Edition choice (Community or Enterprise)	ZenDiS recommends Enterprise for production and offers SLA-backed support, while Community is supported only by the community, which changes the support scope around cutover.	Ask for quotes for both editions against the same written scope, and confirm which support level applies during the migration window.
Number of environments	Separate test, pilot and production environments each need their own identity, mail and data loads, and the number multiplies test runs.	Limit environments to what the risk requires, and reuse the pilot environment for rehearsal runs of the cutover.

Project phases and outputs

The sequence moves mail, calendars, files and chat from Microsoft 365, Exchange or file shares into openDesk, and each phase closes with a signed output that the next phase depends on.

Inventory sources and mailboxes
Your team and DeployOpen list every mailbox, shared mailbox, calendar, file share and chat history in scope, along with add-ins, retention rules and mail flow dependencies. Confirm early whether chat history is migrated at all. Output: a source inventory signed off by data owners, with volumes, named owners and items to exclude. The step is done when every source has an owner and a disposition.
Design the target and mapping
Map each source to its openDesk destination: mail and calendars to OX App Suite, files to Nextcloud and chat to Element. Decide namespaces, naming conventions, folder structures and retention settings, and record which items will not move. Output: a signed target design and a mapping workbook that the migration tooling will follow in later phases.
Build the platform on Kubernetes
Stand up openDesk on a CNCF-certified Kubernetes cluster at v1.33 or later, with an ingress controller, cert-manager, a volume provisioner for RWO volumes, Helm and Helmfile. Connect external production services, including PostgreSQL, Redis, object storage and an SMTP relay. Pin the current minor release at build start, since only the latest minor is supported and in-place upgrades between majors are not guaranteed, and plan the upgrade path now. Output: an environment with a version record.
Federate identity or import the directory
Choose OIDC federation with your existing identity provider, matching users by username or an attribute such as mailPrimaryAddress, or import users from LDAP or Active Directory with the one-way Nubus Directory Importer. Microsoft Entra ID does not expose LDAP, so confirm the Azure AD Domain Services route early if it applies. Output: test users who sign in through the chosen route, with agreed provisioning rules.
Build and rehearse migration tooling
Build import jobs for mail, calendars, files and chat against the mapping, then run full rehearsals in a non-production environment using copies of the inventoried data. After each run, measure errors, throughput, item counts and folder fidelity, and correct the mapping before the next rehearsal. Output: a runbook with validated counts, known exceptions and a rollback procedure.
Run pilot and full migration waves
Move a small pilot group first, then migrate remaining users in waves, each with a freeze window and user communication agreed with the business. Compare item counts and sample content after every wave, and collect feedback on mail, calendars and file access. Output: a wave report per group that the operations team and data owners accept before the next wave starts.
Cut over, decommission and hand over
Switch mail routing and DNS to openDesk at cutover, keep the source tenant in its agreed state until the exit point, then retire Microsoft 365 or Exchange licenses, connectors and mailboxes. Hand runbooks, monitoring, backup and upgrade procedures to the operations team with named owners. Output: a signed cutover record, decommissioning evidence and an operations handover.

What stays in-house and what goes to a partner

This table shows who typically owns each part of an openDesk migration from Microsoft 365 or Exchange and which skills each part needs, so you can split the work between your team and a partner.

Work area	Typical owner	Skills the work needs
Source tenant administration	In-house	Microsoft 365 or Exchange administration, tenant policies, licensing, export permissions and retention settings
Kubernetes and Helmfile operations	Shared	Kubernetes operations, Helm 3 and Helmfile, ingress, cert-manager and storage; in-house owns day-to-day operations after handover
Identity and directory work	Shared	Directory design, OIDC federation with the Keycloak-based IdP, and Nubus Directory Importer or Azure AD Domain Services for Entra ID sources
Mail routing and DNS	In-house	MX, SPF, DKIM and DMARC changes, SMTP relay configuration, coexistence routing and change control with the mail provider
Data migration tooling	Partner	Mailbox, calendar, contact and file migration tooling, mapping rules for OX App Suite, Nextcloud and Element, and error handling
Rehearsal runs	Partner	Test migrations on representative data sets, measuring error rates and fixing mapping defects before any production run
Change management and communications	In-house	Stakeholder planning, user notices, service desk scripts and governance of pilot waves and go or no-go decisions
User training	Shared	Training content design and delivery; in-house staff usually know the business context, while a partner can supply material for openDesk features
Business owners for each data set	In-house	Decisions on what data moves, retention and archive rules, and acceptance of migrated mail, files and chat per department
Cutover sign-off	In-house	Authority to accept the cutover, approve rollback criteria and confirm that migrated data meets agreed checks

What usually goes wrong

Most openDesk migration problems come from data and identity details that look simple in a plan but behave differently in a live tenant. Each risk below lists what to check before the pilot wave and at cutover.

Identity matching and sync scope

Federation matches users by username or another attribute such as mailPrimaryAddress, so a changed or differently cased address can leave a mailbox without a matching account. Limit directory sync to the agreed organizational units before the first run, then confirm that every pilot mailbox maps to exactly one openDesk identity.

Unmapped Exchange and Microsoft 365 data

Shared mailboxes, delegated permissions, retention holds and litigation holds often fall outside what standard mailbox tooling carries across. Inventory these objects from Exchange or Microsoft 365 before the pilot, decide for each one whether it moves, is recreated or stays in archive, and verify the result on a test mailbox set.

File permissions lost on move

Copying files from file shares or SharePoint into Nextcloud does not guarantee that access rights, group memberships and link shares arrive intact. Map source groups to Nextcloud groups and shares first, run a sample migration, and compare effective access for users in each department against the source before any wave goes live.

Chat history expectations

Teams chat history, channel posts and attachments rarely map one to one into Element and its widgets. Agree in writing which conversations, retention periods and attachments move, tell pilot users what will be visible on day one, and check a sample of rooms and files after import.

Mail flow, DNS and rollback at cutover

MX, SPF, DKIM, DMARC, autodiscover and SMTP relay changes land in the same window as mailbox moves, and one missed record can stop inbound mail. Lower DNS TTLs before the window, test inbound, outbound and internal delivery for each wave, and rehearse returning DNS and routing to the previous platform from a tested restore point.

Unplanned version gap

openDesk supports only the latest minor version and does not guarantee in-place upgrades between majors. A deployment that falls several minor releases behind may need intermediate steps before its charts apply cleanly. Pin the target release at project start, record the upgrade path in the plan, and rehearse upgrades on a non-production cluster.

How the work differs by starting point

Entra ID is the identity source, and it does not expose LDAP, so the directory path differs from an on-premises setup.

Identity: Decide early whether users sign in through OIDC federation with an existing identity provider or are provisioned from a directory copy.
Directory path: Entra ID needs Azure AD Domain Services before the one-way Nubus Directory Importer can read users over LDAP.
Extraction: Confirm with the tenant administrator which mailbox, OneDrive, SharePoint and Teams content will move, and what Graph or export throttling applies.
Mapping: Match users by username or by an attribute such as mailPrimaryAddress, and map shared mailboxes and groups explicitly.
Cutover: Confirm the MX change window and that the SMTP relay accepts mail for each migrated domain before records change.

What the client needs to provide

Before the build starts, the client supplies the platform and the people who can make decisions. The first item is a CNCF-certified Kubernetes cluster at v1.33 or later, with 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 these versions against the openDesk requirements page at the time of the build, because the minimum changes between releases. Clusters are tested on kubespray and not on OpenShift, so check the distribution early.

The client also supplies the production services that openDesk expects outside the cluster: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Ask who operates each service, where backups are kept and how they are restored. Access to the source tenant or servers needs a named administrator who can grant export rights and answer questions about mailboxes, shared mailboxes and file permissions during discovery.

Directory access and the identity decision come next. The client decides whether openDesk users come from an existing identity provider through OIDC federation or from Active Directory or LDAP through the Nubus Directory Importer, and confirms which attribute matches users, such as username or mailPrimaryAddress. Entra ID requires Azure AD Domain Services because it does not expose LDAP. DNS and mail flow ownership must also be named, since MX, autodiscover and routing changes decide when cutover is possible.

The client keeps the decisions about what is migrated, what is archived and what is deleted. For each data set, a data owner defines retention, approves the scope of each wave and accepts the result. The client also chooses the openDesk edition for production, since ZenDiS recommends Enterprise Edition for production, and names a sign-off owner for each wave. Without these owners, waves stall at the first disputed mailbox or folder.

Frequently asked questions

How much does an openDesk migration from Microsoft 365 cost?

The price follows from the written scope, so no figure is given here. The main cost drivers are the number of mailboxes, the volume of mail, calendars, chat history and files, and how much source data must be cleaned or mapped before it moves. Other drivers include the number of migration waves, custom retention or folder rules, integrations with other Microsoft services, and the readiness of the target Kubernetes cluster and external services such as PostgreSQL, object storage and an SMTP relay. Ask for a quote that itemizes these items, separates one-time migration work from recurring subscriptions and operations, and states what your team must provide.

How long does an openDesk migration from Exchange take?

Duration depends on the inventory and the number of waves, so no figure is given without a scoped inventory. The inventory should list mailboxes, shared mailboxes, calendars, file shares and sites, chat history to be carried over, total data volumes, and the users who need access before and after cutover. Each wave adds pilot checks, user communication, cutover and a rollback window. Larger or more complex estates usually need more waves. Ask the partner to confirm the inventory method and the wave plan in writing before a timeline is agreed.

Can our own IT team migrate from Microsoft 365 to openDesk alone?

Yes, a team with the skills listed in the in-house skills table on this page can run the migration, provided it has a named owner and time for pilot waves. The work spans identity, mail routing, calendar and contact mapping, file transfer, Kubernetes operations and user support. Teams without recent Kubernetes or directory experience may want outside help for the platform build or the cutover. Decide early which tasks your team will own and which you will buy, and write that split into the scope so nothing falls between the two.

Can openDesk use Microsoft Entra ID directly for user provisioning and sign-in?

Not through LDAP, because Microsoft Entra ID does not expose an LDAP interface. The recommended route for directory-based provisioning is the one-way Nubus Directory Importer, which reads users from LDAP or Active Directory. For an Entra ID tenant, one option is Azure AD Domain Services, which provides a managed domain with LDAP access that the importer can read. Sign-in can also be federated over OIDC between your existing identity provider and openDesk's Keycloak-based IdP, with users matched by username or another attribute such as mailPrimaryAddress. Confirm with your identity team which attributes will match and who owns the sync.

Should production openDesk run on Community or Enterprise Edition?

Enterprise Edition is the option ZenDiS recommends 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, sold as SaaS or for on-premises installation. Enterprise-only features include Collabora automatic load scaling, GroupSync and Admin Console, and Nextcloud Enterprise security patches. Community Edition is supported only by the community on openCode, with no SLA. Compare the subscription against your need for support response, patching and in-house capacity.

How does an openDesk upgrade affect data migrated earlier?

An upgrade changes the software that holds your migrated data, so it should be planned as its own project. openDesk ships annual major releases, monthly minor releases and patches on demand, and only the latest minor is supported. In-place upgrades between majors are not guaranteed, and skipping several minor versions may need intermediate steps. Back up each component's data before every upgrade, rehearse on a staging environment built from the same release, and confirm that the migration mappings still hold for the target version. Ask the partner to document the upgrade path for your installed versions.

How DeployOpen scopes and delivers this work

DeployOpen plans and implements openDesk migration from Microsoft 365 or Exchange inside infrastructure you control, mapping mail, calendars, files and chat to the openDesk components and moving them in pilot waves before cutover. Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.

How we scope

The written scope lists which mailboxes, calendars, file shares and chat history move, and from which source system.
Scope records the target mapping to OX App Suite, Nextcloud and Element, and what is out of scope.
Identity decisions are documented up front, including how users are provisioned and federated into openDesk's IdP.

How we build

We prepare the Kubernetes cluster, ingress, cert-manager and external production services against openDesk's documented requirements.
We run migration tests on non-production data and record results for mail, calendar, file and chat content.
Pilot waves are defined by user group, with rollback steps and verification checks agreed before each wave runs.

How we hand over

Deliverables include the runbook for each migration wave, cutover checklist, configuration records and Helmfile deployment documentation.
Your team receives a verification report showing what migrated, what was excluded and what needs manual follow-up.
Knowledge transfer sessions cover day-two operations, including how to apply openDesk's monthly minor releases.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the migration closes.
Post-cutover support can cover mailbox issues, user provisioning changes and migration remediation, as set out in the written scope.
Ask whether your deployment will use Community or Enterprise Edition, since support levels differ and are defined by ZenDiS.