Migrate from Microsoft Exchange to openDesk: what the move involves
Moving Exchange mail and calendars into openDesk is a platform-level migration that needs a Kubernetes foundation, identity planning and a staged mailbox cutover. It is not a mailbox copy. openDesk is a Kubernetes-based suite: its deployment is Helmfile and Helm based, and it bundles OX App Suite for groupware alongside Nextcloud for files, Element for chat, Jitsi for video and Nubus for portal and identity. Mail is therefore one workload among several, and its users, groups and sign-in depend on the directory design you choose before the first mailbox moves. Most of the work sits with the client's platform team (cluster, ingress, certificates, storage, SMTP relay and external services) and its messaging team (mailbox inventory, client behavior and cutover), usually supported by an implementation partner. The deployment is offered as a Community edition and an Enterprise edition, and ZenDiS recommends the Enterprise edition for production.
Effort and risk are driven less by the mailbox volume than by the platform decisions. The openDesk requirements call for 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, and production expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Confirm with ZenDiS and the openDesk documentation whether your Exchange sources, Outlook clients and mobile devices need connectors that OX App Suite supports in openDesk, and how your existing directory will federate with the Nubus identity layer. Plan a staged cutover with coexistence, and ask for a written test plan covering shared calendars, delegates and client profiles before scheduling any mailbox moves. Also check the openDesk requirements for the current versions, because the platform moves on a fixed release cadence and in-place upgrades between majors are not guaranteed.
Which Exchange capabilities map to openDesk and which need rework
This table maps Exchange capabilities to their openDesk equivalents and marks each row as clean, needs rework or gap. Read it as a starting point for a workshop with your mail, compliance and identity owners, not as a feature certification, and confirm client protocol support against the OX App Suite and openDesk documentation before you commit to a cutover plan.
| Exchange capability | openDesk equivalent | Status and what to confirm |
|---|---|---|
| Mail and calendar | OX App Suite groupware (email, calendar, tasks) | Clean for core use. Confirm which mail and calendar protocols the OX release in your openDesk version supports for each client. |
| Contacts | OX App Suite address book | Needs rework. Plan contact export and import from PST or vCard exports and test sync to phones and desktop clients. |
| Shared mailboxes and delegates | OX App Suite shared folders and delegation options | Needs rework. Confirm how shared mailboxes, send-as rights and delegate access map to OX permissions before migrating. |
| Retention and eDiscovery | No direct openDesk equivalent in the suite | Gap. Define retention and legal hold controls with your records team and assess an external archive or eDiscovery tool. |
| Outlook and mobile client access | OX clients, IMAP, CalDAV and ActiveSync options through OX App Suite | Needs rework. Outlook does not behave as it does with Exchange. Test MAPI-dependent features, add-ins and mobile sync with the OX and openDesk documentation. |
| SharePoint-style files and libraries | Nextcloud for files, with Collabora Online for web office | Needs rework. Map site structures, permissions and version history to Nextcloud folders and groups, then test large migrations. |
| Teams-style chat | Element with Nordeck widgets | Needs rework. Chat history, channel structure and user onboarding need a separate migration plan. |
| Teams-style video meetings | Jitsi | Needs rework. Confirm room, recording and scheduling integration with calendar invitations. |
| Directory sign-in and identity | Nubus for portal and identity and access management, with optional external IdP federation | Needs rework. Confirm how your existing directory and federation design maps to Nubus before cutover. |
Which data exports exist and which integrations must be rebuilt
Moving from Exchange to openDesk is two separate jobs: getting data out of the old systems and rebuilding everything that talked to Exchange. The cards below cover the export paths that Microsoft documents, the mail-side work that a file export does not solve, and the inventory of mail flow and third-party dependencies that teams most often miss before cutover.
Purview eDiscovery mailbox export
Microsoft Purview eDiscovery can export Exchange mailbox items as PST or .msg files, which is the documented route for pulling mail out of Exchange Online. Search export packages expire 14 days after creation, so downloads must be scheduled and verified in the same working window. Exporting requires a Microsoft 365 E3 or E5 license, so confirm entitlements with the Microsoft account team before the project starts.
SharePoint and OneDrive file export
eDiscovery can export SharePoint and OneDrive content as native documents with selectable version history. Decide early whether version history must move, because it affects package size and the import effort on the target. Check permissions, sharing links and folder structure separately, since native exports do not carry the full access model into Nextcloud or openDesk Files.
Mailbox move is a separate task
Moving mail, calendars and contacts into OX App Suite is an export and import task of its own, not a side effect of the file export. Calendars and contacts need more than IMAP, because IMAP alone does not carry them, so the migration plan must name the method used for each object type. Plan a coexistence period for free/busy lookups and shared calendars during cutover.
Transport rules and journaling
Transport rules, journaling and archiving policies often enforce retention, disclaimers and regulatory capture, and they rarely appear in user documentation. Export the rule definitions from Exchange admin tools, then decide for each one whether the target provides an equivalent, a gateway replacement or a documented accepted gap. Records officers should sign off on any gap before users are moved.
SMTP relays and device senders
Scanners, line-of-business applications, monitoring tools and printers often send mail through an Exchange SMTP relay with fixed IP allowances. Inventory every sender, its authentication method and its destination, then recreate those paths on the new mail platform and the openDesk SMTP relay that production deployments require. Missing a single device sender usually surfaces only after cutover.
Mobile policies and third-party apps
Mobile device policies, ActiveSync-dependent apps, and integrations such as ticketing, HR or document approval tools each hold their own connection to Exchange or Microsoft Graph. List each app with its owner, protocol and credentials, and confirm which ones can point to a new endpoint. Confirm with each vendor which mobile clients they support before setting a cutover date.
Migration sequence from inventory to Exchange decommission
This sequence moves mail and calendars from Exchange into openDesk in controlled stages, so each group is verified before the next one moves. Each step has a defined output, and the final step retires Exchange only after archive retention is in place.
Inventory mailboxes, shared resources and integrations
Your messaging and identity team lists every mailbox, shared mailbox, room and equipment resource, distribution list, delegate permission, and public folder, along with retention and legal hold settings. They also record every application that sends mail through Exchange, such as scanners, line-of-business systems and monitoring alerts, and every device type connecting through ActiveSync or Outlook. Done when you have a signed-off register that maps each item to an owner, a target group and a cutover wave, and when the list of mail-sending integrations has each one assigned to a team that will test it.
Build the openDesk reference environment
Your platform team provisions a CNCF-certified Kubernetes cluster at v1.33 or later, with an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, and an RWO volume provisioner. Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later are installed, and production-grade external services are provided: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. ZenDiS recommends planning production on the openDesk Enterprise Edition, so confirm licensing and support terms before sizing. Done when the reference environment deploys cleanly and the mail flow to and from the SMTP relay is tested end to end.
Connect identity and run a pilot group
Your identity team federates the openDesk identity layer with your existing directory, following the external IdP federation guidance, so pilot users sign in with their current credentials. A small pilot group, chosen by the business owner and not by IT alone, migrates mail, calendar and contacts using the agreed export and import method. Confirm that Outlook or mobile clients connect as expected, that shared calendars and delegates behave correctly, and that inbound mail reaches the pilot users without delay. Done when the pilot users sign off on a defined test script and every defect has a recorded fix or workaround.
Run a parallel period with coexistence
Both platforms stay live while users move in waves. Your team configures mail routing and free/busy lookups so users on either side can see each other's availability, and keeps a documented rule for which system owns each mailbox at any point. Monitoring covers mail queues, the SMTP relay, antivirus scanning through ClamAV and delivery failures, and each change is logged. Done when routing rules and coexistence behavior have been tested for every type of recipient, and when the rollback steps for each wave are written and rehearsed.
Cut over mailboxes group by group
Each business group moves in a planned wave with a final delta sync, a freeze on the Exchange mailbox, a DNS and routing change, and a validation pass that checks item counts, folder structure, calendar entries and delegate rights against the inventory. Users receive guidance on reconfiguring clients and on what to expect from shared resources. Done when every group in the register shows a completed validation record and no open high-severity defects remain.
Retire Exchange with archive retention
Once all waves are validated, your team confirms that retention and legal hold obligations are met, exports required archives in a format your records and legal teams accept, and stores them in a location with its own access controls. Microsoft Purview eDiscovery can export Exchange items as PST or .msg files, but its search export packages expire 14 days after creation, so copy them to retained storage before that window closes. Only then are Exchange connectors removed, the server or subscription is decommissioned, and licenses are cancelled. Done when the archive is verified as readable, the decommission record is signed by the data owner, and no mail flow still depends on Exchange.
How openDesk's identity and directory layer changes sign-in
The first decision in this section is which directory stays the source of truth during coexistence: Active Directory, Entra ID, or openDesk's own identity store. openDesk uses Nubus for portal and identity and access management, and the openDesk federation documentation describes how it can federate with an external identity provider. Until you have confirmed that federation pattern against your own Active Directory or Entra ID tenant, do not move user objects or change sign-in flows. Ask ZenDiS or your openDesk implementation partner which attributes Nubus expects, how account creation and deprovisioning propagate, and what happens to users who exist in both directories during the transition. Write that answer down as a named decision with an owner, because mailbox migration, Outlook profile changes and password policy all depend on it.
Group and role mapping deserves the same care as user federation. Exchange environments often grant mailbox access through distribution groups, shared mailbox permissions and delegate rights that were built over years. Each of those must be mapped to openDesk groups and roles before cutover, or users will open the new suite and find shared calendars and team folders empty. Confirm with the openDesk documentation how group membership from your source directory is represented in Nubus and in each bundled application, and test a shared mailbox and a delegate calendar in a non-production tenant first. The GroupSync and Admin Console features are listed among the Enterprise Edition modules, so confirm whether your target design depends on them before choosing the Community Edition for any production role.
Plan the sign-in experience as a user-facing change, not only an infrastructure task. Single sign-on across Nextcloud, OX App Suite, Element and the other bundled applications depends on the identity layer working for every one of them, so a federation fault appears as many separate login failures. Ask for a test matrix that covers password change, multi-factor enrollment, account lockout, session expiry and offboarding, and run it against each application. Confirm how the chosen identity provider handles certificates and metadata rotation, and who in your organization holds the operational runbook for that rotation. Treat these checks as exit criteria for the identity workstream, and do not schedule the mail cutover until they pass.
What drives cost and duration in an openDesk migration
This table lists the cost components of moving Exchange mail and calendars into openDesk, who is paid for each, and what makes each one larger or smaller. Read it as a checklist for a written scope, since production sizing is only settled after a scoped assessment of your users, data and services.
| Cost driver | What makes it larger | How to keep it down |
|---|---|---|
| Kubernetes cluster and operations | Production sizing for user count, high availability across nodes, and staff who run Kubernetes 1.33 or later with cert-manager and an ingress controller | Confirm whether your platform team already operates a compliant CNCF cluster; ask the implementer to scope cluster sizing separately |
| Evaluation hardware (12 x64 cores, 32 GB RAM, 10+ GB disk) | This is the published minimum for an evaluation deployment only, not a production sizing; ARM is not supported yet | Use the evaluation footprint for a pilot in a non-production environment, then size production through a written scope |
| External production services | openDesk expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, each with its own operations | Reuse services your organization already runs and monitors, and confirm versions and support windows before buying anything new |
| Storage and backup | Mailbox volume, archive and retention rules, Nextcloud file volume and the backup target for each stateful service | Measure Exchange mailbox and archive sizes first; set retention policy before migration so only needed data moves |
| Enterprise Edition subscription | Enterprise Edition is recommended for production and adds SLA-backed 2nd and 3rd level support, patches and closed-source modules; sold as SaaS or on-premises | Ask for a line-item quote comparing on-premises and SaaS delivery and which support tiers are included |
| Implementation and integration | Identity federation with your existing directory, SMTP and mail flow changes, customization, and the number of openDesk components enabled | Fix scope in writing before work starts, limit the first wave to mail and calendar, and add chat, video and files later |
| Mailbox migration tooling and testing | Number of mailboxes, shared mailboxes, delegates, public folders, and the amount of calendar and contact data that needs validation | Run a pilot with a small user group, agree acceptance tests for calendar invitations and delegates, and script repeatable exports |
| User training and change | Number of users moving from Outlook and Exchange habits to openDesk clients and workflows across mail, files and chat | Plan role-based training, publish short guides, and confirm which client access paths your users will rely on |
| Exchange licensing during coexistence | Exchange Server or Exchange Online licenses continue until mailboxes, retention and compliance holds are moved and verified | Set the decommission date in the scope, then ask your licensing advisor to confirm the parallel-run terms for your agreement |
How the migration differs by organization size and starting point
Moving the whole suite at once means mail, files, chat and video cut over in a planned sequence, with one identity model and one support model from day one. Moving mail first keeps Exchange in place for files and chat while mailboxes and calendars move, which lowers the number of changes users see at each step but adds a period where two systems must coexist.
- Whole-suite cutover: Files, chat and video are prepared alongside mail, so the team tests document links, shared folders and meeting access in the same window.
- Mail-first cutover: Calendar free/busy and shared mailboxes must work across both systems until Exchange is retired, so coexistence testing becomes a project in its own right.
- Coexistence period: Mail-first plans need a defined end date for the second system, or Exchange licensing and hosting costs recur longer than expected.
- Support load: A single cutover concentrates helpdesk demand in one window, while staged moves spread it out.
- Dependencies: Line-of-business applications that send mail through Exchange need their SMTP relay settings changed in whichever phase they belong to.
Before choosing, confirm with ZenDiS or your openDesk partner which components your sequence will activate first and how the Groupware and Files pieces can be phased.
An on-premises Exchange estate usually means mailbox data sits in databases your team controls, and the migration starts with an inventory of mailboxes, archives, public folders, distribution groups and the Active Directory objects that feed them. Exchange Server 2016 and 2019 extended support status should be checked against the Microsoft lifecycle pages, because it affects how long the existing servers can be run safely during the project.
- Mailbox export: Export tooling works against the server, so the team needs administrative access to the Exchange organization and a file share with the right permissions for export output.
- Archives and large mailboxes: Primary and archive mailboxes are often exported separately, and very large mailboxes need their own schedule.
- Directory dependencies: Groups, delegates and address book entries rely on Active Directory, so the identity design for openDesk must be settled before the first mailbox moves.
- Hybrid configuration: Any hybrid connector to Exchange Online must be removed or reviewed before the on-premises servers are switched off.
- Hardware and licensing: Ongoing server and license costs continue until decommissioning, which is a factor in choosing the cutover date.
Confirm which Exchange version runs in your estate and which export method your administrators can run under your change control rules.
For Exchange Online tenants, the usual starting point is an export through Microsoft Purview eDiscovery, which can produce PST or .msg files for mailbox items and native documents for SharePoint and OneDrive content with selectable version history. Export packages expire 14 days after creation, and exporting requires a Microsoft 365 E3 or E5 license, so the export window and license position must be confirmed before the project plan is fixed.
- Export package handling: Download and verify each package within the 14-day expiry, and schedule exports so a failed package can be re-run without a gap.
- License position: Confirm which users hold the license needed to run exports, and whether that license continues after the move.
- Scope of export: Purview covers the content that search returns, so mailboxes, sites and version history need to be checked against the source list.
- Storage and handling: Exported PST files contain sensitive mail, so they need encrypted storage with access logging in your own environment.
- Tenant retention: Confirm how retention and legal hold policies interact with deletion after cutover.
Ask your Microsoft account team and your compliance lead which export scope and retention settings apply to your tenant.
An organization that already runs a Kubernetes platform can deploy openDesk into a cluster its operators already know, which shifts effort toward the openDesk requirements and integrations. openDesk expects a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile at the versions listed in the requirements, and it is tested on kubespray clusters rather than OpenShift.
- Version gap: Check whether the existing cluster meets the minimum version and whether the chosen ingress controller is supported.
- Shared services: openDesk expects production-grade PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, which may already exist or need to be provisioned.
- Platform fit: OpenShift-based platforms need a separate assessment because openDesk is not tested there.
- Operations: Upgrades follow openDesk's release model, so the platform team must plan minor and major upgrades around it.
- Isolation: Namespace and network policy design should be agreed with your security team before data is loaded.
If no Kubernetes platform exists, the cluster build becomes a prerequisite project with its own sequencing and operating costs.
An organization without a Kubernetes platform has to build the cluster and its supporting services before any mailbox can move, so the first phase is platform work rather than data work. The openDesk requirements describe what the cluster must provide, and an evaluation deployment has its own minimum hardware, but a production deployment depends on external services that must be operated, backed up and patched.
- Platform build: Cluster design, node sizing, storage and networking are one-time costs that also recur as the platform is patched and upgraded.
- Hardware minimum: The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, with ARM not yet supported, which is a floor for testing rather than a production sizing.
- Supporting services: Databases, caches, the SMTP relay, antivirus and TURN services need owners, backup policies and monitoring from the start.
- Skills: Plan for staff who can operate Kubernetes, Helm and the openDesk deployment, or for a support arrangement that covers them.
- Sequence: Run an evaluation deployment first, then move to production with Enterprise Edition if your policy requires SLA-backed support.
Ask for a written scope that separates cluster work, openDesk deployment and data migration, so each phase has its own acceptance criteria.
What usually goes wrong and how to prevent it
Migration failures in this project rarely come from the software alone. They appear at the edges: delegate rights that do not survive export, identities that do not line up, platform choices outside supported configurations, and licensing or export deadlines that run out mid-project. Each card names one failure, why it matters for this move, and the check that prevents it.
Delegates and Outlook behavior
Delegate rights, shared mailbox permissions and calendar ownership are stored per account and often do not follow a mailbox through an export and import. After cutover, assistants may lose the ability to send on behalf of an executive, and shared calendars may show stale free/busy data. Outlook profiles can also cache old settings and show unexpected behavior, such as duplicate calendars, until users recreate them. Build an inventory of delegates and shared mailboxes from Exchange, then pilot each pattern with live Outlook clients and confirm the delegate behavior in your own openDesk tenant before the first wave.
Directory and openDesk identities diverge
openDesk handles portal and identity management through Nubus and can federate with an external identity provider. If user principal names, primary email addresses or group memberships in the source directory do not match what openDesk expects, mail can route to the wrong account or users can be locked out after cutover. Map each attribute before migration, decide which directory holds the source of truth, and test federation with a sample of accounts that includes shared and service mailboxes.
Skipped minor releases compound
openDesk plans monthly minor releases, but only the latest minor version is supported, and in-place upgrades between majors are not guaranteed. A team that deploys once and then falls several minor versions behind may need intermediate upgrade steps that were not in the plan. Pin chart versions in your Helmfile configuration, track the release notes, and run each upgrade in a staging cluster before production. Ask the implementation partner to include upgrade rehearsals in the written scope.
Unsupported Kubernetes distribution
openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, and it is tested on kubespray clusters, not OpenShift. Many public sector platform teams already run OpenShift, so the gap often surfaces late, when ingress, storage or security context assumptions fail in a test environment. Confirm the distribution, the ingress controller choice (haproxy-ingress or the deprecated Ingress nginx), cert-manager and the RWO volume provisioner against the requirements before selecting a cluster.
Exchange licensing in a long parallel run
Coexistence is where Exchange costs grow without anyone noticing. Keeping Exchange servers and client access licenses running alongside openDesk for months adds to the total cost, and Exchange 2019 extended support ended in October 2025, so older servers add security risk as well as expense. Ask Microsoft or your reseller which licensing terms apply to Exchange Server SE servers and CALs during coexistence. Shorten the window by moving mailboxes in defined waves, and write the decommission date into the project plan.
Export packages expire before download
Microsoft Purview eDiscovery search export packages expire 14 days after creation, and exporting requires a Microsoft 365 E3 or E5 license. If a package is generated and not downloaded within that window, the team must rerun the search, and the results may differ if mail has changed since. Record the search query, download each package to a controlled store within the window, and verify file counts and checksums before import. Schedule downloads as a tracked project task, not an ad hoc step.
Questions buyers ask before moving Exchange to openDesk
What does an Exchange to openDesk migration cost, and what drives the price?
The cost depends on the written scope, so there is no fixed figure to quote here. The main components are the Kubernetes cluster and its supporting services (PostgreSQL, MariaDB, Redis, object storage, an SMTP relay, ClamAV and a TURN server), the openDesk subscription if you choose Enterprise Edition for production, planning and integration work, the mailbox and calendar migration itself, and training and cutover support. Recurring costs include infrastructure, subscriptions and any retainer for upgrades. Ask every quote to split one-time work from recurring costs, to state how many mailboxes, shared calendars and archives are in scope, and to name which identity source is connected. DeployOpen does not publish a price list. A quote follows from the written scope.
How long does a move from Exchange to openDesk take?
Duration depends on scope rather than on a standard timeline. The factors that matter most are the number of mailboxes and archives, how many shared mailboxes and resource calendars need rebuilding, whether identity federation with an external identity provider is in place, how much of the rest of the suite (files, chat, video) moves in the same programme, and how many integrations with line-of-business systems must be retested. Coexistence during cutover also adds time. Ask for the proposed phases and the deliverables for each in the written scope, and ask your own team to confirm the infrastructure lead time, since the cluster and its services often set the start date.
What must our team provide before an openDesk project starts?
Your team needs to provide the environment and the decisions. On the infrastructure side, that means a CNCF-certified Kubernetes 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. Production also needs the external services listed in the requirements, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. On the decision side, you must name the identity source, the domain and DNS plan, the retention rules, the legal hold owner and the list of users and shared mailboxes. Confirm the cluster version and the tested platform (openDesk is tested on kubespray clusters and not on OpenShift) against the current requirements before you commit.
Can our own IT team migrate Exchange to openDesk without outside help?
A capable platform team can run openDesk, but a first migration of mail, calendars and contacts across an enterprise usually needs experienced help with coexistence, data validation and cutover. The deployment automation is Helmfile and Helm based and is published under Apache 2.0, so the tooling is available to you. What is harder to staff is the testing: confirming that calendars, delegation, shared mailboxes and mobile clients behave as users expect, and rolling back cleanly if they do not. You can split the work. Your team can own the cluster, the identity and the user communications, while an implementation partner takes the migration tasks named in a fixed-scope agreement. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and support is available as a retainer.
Does openDesk support Outlook the way Exchange does?
Confirm this before you commit, because openDesk's groupware is OX App Suite, and the client behavior depends on the protocols the chosen setup exposes. Exchange gives Outlook MAPI, Exchange Web Services and ActiveSync natively, with shared calendars, delegates and free/busy handled by the server. Check each of these against your own tests: whether the Outlook client you need connects through the supported protocol, how shared calendars and delegate access appear, how free/busy lookups work across the organization, and what mobile devices receive. If Outlook is a hard requirement for a user group, test it with that group's real workflows before the project is scoped. Also ask whether a Microsoft-compatible connector is part of the agreed scope.
How do we handle retention, archives and legal hold during the move?
Treat retention and legal hold as a scoped deliverable, not a side effect of the mail move. Start by listing which mailboxes, archives and shared folders are under legal hold or retention rules in Exchange, and who owns those decisions. Microsoft Purview eDiscovery can export Exchange mailbox items as PST or .msg files, and SharePoint and OneDrive content as native documents with selectable version history, but search export packages expire 14 days after creation and exporting requires a Microsoft 365 E3 or E5 license, so plan the export window. Confirm with your legal and records team which format and metadata they must keep, and agree how held content is preserved in openDesk. Ask the implementation partner to document the chain of custody for each export and import.
Does DeployOpen issue audit reports or certifications for our openDesk environment?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. In practice, DeployOpen can help you document configuration, access controls, backup and logging evidence and the operating procedures an assessor will ask to see, so your auditor has a clear record to review. Ask the auditor which framework and control scope they will use before the design is fixed, and confirm in writing which evidence DeployOpen will produce as part of the fixed scope.
Is openDesk Enterprise Edition needed for production, and what does it add?
ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses as Community Edition 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 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. Ask your procurement team to compare the subscription against the support model in the written scope, and confirm which features your users need on day one.
How DeployOpen scopes and runs an openDesk migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including openDesk. For a move off Exchange, we treat mail and calendar cutover as one part of a wider suite change that also covers files, chat, video and identity.
How we scope
- Written scope covers mailbox, calendar and contact migration from your Exchange estate into openDesk groupware.
- Scope also records which Exchange features, shared mailboxes and delegates need a documented replacement or workaround.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We plan the openDesk deployment on Kubernetes in your cloud account, data center or air-gapped network.
- We integrate openDesk with your existing identity provider and directory, and test sign-in before any mailbox moves.
- We run pilot migrations, validate mail, calendar and contact counts, and test cutover and rollback steps.
How we hand over
- You receive documentation of the deployed architecture, configuration, integrations and migration runbooks.
- Security hardening decisions and compliance-relevant evidence are recorded so your auditors can review them independently.
- Knowledge transfer covers administration, backup and upgrade procedures for your own operations team.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Retainer scope should specify which openDesk releases, upgrade paths and support levels your team needs.
- Ask us to confirm in writing which parts of your environment remain under our support and which stay with your team.
