Migrate from Microsoft 365 to openDesk

Migrate from Microsoft 365 to openDesk: what the move involves

If your Microsoft 365 renewal, licensing change, residency rule or lock-in concern is pushing you toward openDesk, the short answer is that openDesk is a Kubernetes-deployed suite that replaces the cloud workloads, not the Office desktop applications, and the move is a multi-workload project with real export and sequencing work. Its components cover groupware through OX App Suite, files through Nextcloud, web office through Collabora, chat through Element, and video through Jitsi, so the mail, sites, OneDrive files and Teams history each need their own path. Most organizations run this with an internal platform team that owns the Kubernetes cluster and an implementation partner that handles the deployment, integration, identity federation and cutover plan. ZenDiS, the German federal Centre for Digital Sovereignty, maintains openDesk, and the deployment automation is Apache-2.0 licensed, but each bundled component keeps its own license, such as AGPL-3.0 for Nextcloud and GPL-3.0 for OpenProject, so your legal review should cover every component rather than the suite label alone.

The effort and risk sit in three places. First, the target platform: openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and a suitable volume provisioner, and production expects external PostgreSQL 15, MariaDB 10, Redis 7, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Second, the exports: Purview eDiscovery can export mailboxes as PST files and OneDrive and SharePoint content as native files with version history, but the export needs an E3 or E5 license and search export packages expire 14 days after creation, so plan exports in batches that fit that window. Third, identity: users, groups and mailbox permissions must map cleanly into the new directory before the first mailbox lands. Ask your partner to confirm which of these pieces they run, and which you own, in writing before the scope is fixed.

Sequencing decides whether the subscription lifecycle works for you or against you. Before you reduce or cancel licenses, confirm with Microsoft the retention and deletion timelines that apply to your tenant, and do not assume that data stays available after a license lapses. A practical order is to pilot a small group, validate mail, calendar and file round trips, then move departments in waves while the old tenant remains readable. Enterprise openDesk is the edition ZenDiS recommends for production, and it adds SLA-backed support and patches, so ask whether that support is part of your quote. Because openDesk upgrades are annual for majors and monthly for minors, with only the latest minor supported, build an upgrade calendar into your operating plan from the first day.

Which Microsoft 365 capabilities map cleanly to openDesk

This table maps the main Microsoft 365 workloads to the openDesk component that covers them, and marks each as clean, needs rework or gap. Use it to scope a pilot, then confirm feature parity for your openDesk version against the openDesk documentation before you commit to a cutover plan.

Microsoft 365 capability	openDesk component	Status	What to confirm
Exchange Online mail and calendar	OX App Suite (groupware)	Needs rework	Confirm mailbox migration tooling, shared mailboxes, delegation and resource calendars for your version
Outlook desktop and mobile clients	Web interface of OX App Suite	Gap	Confirm whether MAPI, EWS or ActiveSync clients are supported and which users must change clients
SharePoint document libraries and OneDrive files	Nextcloud for files	Needs rework	Confirm how library structure, permissions and version history map to Nextcloud folders and sharing
Word, Excel and PowerPoint for the web	Collabora as the web office	Clean	Confirm docx, xlsx and pptx fidelity for your templates, macros and tracked changes
Desktop Office applications	None in the bundle	Gap	Plan desktop Office licensing or alternatives separately from the openDesk deployment
Teams chat and channels	Element with Nordeck widgets	Needs rework	Confirm channel, guest and retention mapping, and whether Teams message history can be imported
Teams meetings and calls	Jitsi	Needs rework	Confirm recording, dial-in, large meeting limits and calendar invitation behavior
Teams client and Outlook add-in integrations	Not in the openDesk bundle	Gap	Confirm with the openDesk documentation which Microsoft client integrations exist, if any
Notes, wikis and project tracking	Notes, XWiki and OpenProject	Needs rework	Confirm whether content and permissions can be migrated, and which tool replaces each Microsoft workload

Which data exports and integrations need work

Moving off Microsoft 365 is less a single export than a set of separate workstreams: mail and files leave through a documented eDiscovery path, identities must be recreated on the openDesk side, and the mail and automation layer around Exchange has to be rebuilt. Each card below is a point where a cutover can stall if it is not scheduled and owned early.

Purview eDiscovery export of mail

Mailboxes can be exported from Microsoft Purview eDiscovery as PST or .msg files, which is the documented route for pulling mail out of Exchange Online. Exporting requires a Microsoft 365 E3 or E5 license, so confirm that your tenant holds one before planning the export window. Search export packages expire 14 days after creation, so download and stage each package to your own storage promptly and record checksums. Confirm with your Microsoft account team which licenses your administrators hold.

SharePoint and OneDrive content export

eDiscovery can also export SharePoint and OneDrive content as native documents, and you can choose whether to include version history. Decide before export which versions matter for records and which only add volume, because version history multiplies the data you must move and verify. Map the exported folder structure onto the target file platform's paths, and check that long file names and special characters survive the transfer.

Recreating identities in Nubus

openDesk authenticates users through Nubus for portal and identity management, so user accounts, groups and role assignments must exist there before any mailbox or file is imported. Map Entra ID groups to openDesk groups and document which group grants access to which workspace. Confirm whether you will federate with an external identity provider or create accounts directly, since that choice determines how leavers are deprovisioned.

Federating with an external identity provider

If your existing directory remains the source of truth, openDesk can be configured to federate with an external identity provider. Test sign-in for every user group, including administrators and any service accounts, before cutover. Verify that group membership changes in the source directory reach openDesk on the schedule you expect, because stale group membership is a common cause of access errors after migration.

SMTP relay and mail delivery

openDesk expects an external SMTP relay for production, so outbound mail for notifications and mailbox delivery depends on infrastructure you must provide. Plan SPF, DKIM and DMARC records for the sending domain before cutover, and test that existing partner and line-of-business applications can still send through the new relay. Confirm ownership of the relay and its allowlists with the network team.

ClamAV over ICAP for malware scanning

Production openDesk deployments expect ClamAV to be reachable over ICAP so uploaded and synchronized files are scanned. Confirm that the scanning service is sized for the migration volume, since a bulk import of files generates scanning load that ordinary daily use does not. Agree in advance how quarantined files from the migration are reported to owners and who clears them.

Rebuilding mail flow rules and Power Automate flows

Exchange transport rules, mail flow connectors, Power Automate flows and third-party app connections do not move with mailboxes. Inventory each one from the admin center and from business owners, then decide whether it is retired, rebuilt on openDesk components or replaced by an integration layer. Name an owner for every flow, because flows that run unnoticed after cutover are the ones that break invoices, approvals and alerts.

The migration sequence from inventory to decommission

This sequence moves a Microsoft 365 tenant to openDesk in controlled stages, so every mailbox, site and file is accounted for before any subscription change can remove data. Each step has a defined output that gates the next one.

Inventory mailboxes, sites, OneDrive and retention holds
Your Microsoft 365 administrators and the compliance lead list every mailbox, shared mailbox, Teams channel, SharePoint site, OneDrive account and active retention or legal hold, with owners and approximate data volumes. Confirm which workloads carry regulatory retention and which users are on leave or leaving. The output is a signed inventory that maps each workload to an openDesk component: groupware, files, chat or video. Do not proceed until every hold is recorded, because holds determine what must be exported first.
Start user exports before subscription changes
Before any license is reduced, cancelled or allowed to lapse, start exports for held and high-risk content. Purview eDiscovery can export mailbox items as PST or .msg files and SharePoint and OneDrive content as native documents, with version history selectable, but exporting requires an E3 or E5 license and search export packages expire 14 days after creation. Confirm the license state with Microsoft before scheduling exports, and verify package hashes and item counts against the inventory. The output is a verified export archive held in your own storage.
Build the pilot openDesk cluster on Kubernetes
Your platform team, with DeployOpen or another implementer, stands up a pilot environment on 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. Production expects external PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, so provision those before deploying openDesk. Confirm current component versions against the openDesk requirements. The output is a healthy pilot stack that passes deployment checks.
Migrate a pilot user group
Select a small group of willing users with mixed workloads, including one shared mailbox and one Teams-linked site, and import their exported mail, calendars, files and chats into the pilot. Test sign-in through your identity provider, mail flow, calendar invitations, document editing in the web office and sharing permissions. Record every defect and the user feedback in a log. The output is a signed pilot acceptance report that names the fixes made and any gaps still open, such as desktop Office features with no direct equivalent.
Run mail and file sync in parallel
Keep Microsoft 365 active for the pilot group and the remaining users while you sync changes into openDesk for a defined overlap period agreed by the project board. Monitor mail delivery, groupware calendar free/busy accuracy, file sync conflicts and access logs daily. Reconcile item counts between source and target at fixed points. The output is a reconciliation report showing zero unexplained differences for each workload, which becomes the entry gate for cutover.
Cut over each user group in sequence
Move the remaining user groups in waves, updating MX records, client profiles and DNS only after the group's final delta sync is complete. Keep the rollback path documented and tested for each wave. Communicate changes to users, and confirm that shared mailboxes, distribution lists and external sharing links resolve correctly. The output is a per-wave cutover record signed by the business owner, listing the users moved, the sync timestamp and any exceptions.
Verify and decommission Microsoft 365 workloads
After all waves are complete and the retention obligations recorded in step one are satisfied from the openDesk or archive store, confirm that no business process still depends on the tenant. Remove mailboxes, sites and OneDrive accounts only through a documented change, and retain any archive that legal or compliance requires for the period your policy defines. Confirm with your compliance and legal teams how long exports must be kept. The output is a decommission certificate that records the final inventory check and where each archive is stored.

What drives cost and duration in this migration

This table lists the cost and effort drivers for moving a Microsoft 365 tenant to openDesk, and whether each one is mostly one-time or recurring. Use it to build the questions you put to any implementation partner, and to see which inputs you must measure in your own tenant before a quote is meaningful.

Driver	Why it changes cost or effort	One-time or recurring, and what to request
Mailbox and file volume	Export time, transfer bandwidth and target storage grow with total mailbox and OneDrive or SharePoint data. Purview exports are packaged per search and expire after 14 days, so large exports may need several batches.	One-time for transfer. Ask the quote to state the measured data volume per workload and the export batching plan.
Sites and version history retained	Each SharePoint site, library and retained prior version adds mapping work and storage. Keeping all versions multiplies the files to move and verify.	One-time for migration, recurring for storage. Ask which versions are kept and how the target storage is sized.
Teams chat and meeting history depth	openDesk chat runs on Element, not Teams, so Teams messages and recordings need a separate export and mapping decision. Deeper history means more data to convert or archive.	One-time. Ask whether history is migrated, archived read-only or dropped, and who signs off on that choice.
Integration count	Each line-of-business app, connector, mail flow rule, add-in or Power Automate flow that depends on Microsoft 365 needs a replacement, a reconfiguration or retirement.	One-time for rework, recurring if integrations need ongoing support. Ask for an inventory and a per-integration effort line.
Identity complexity	Users, groups, guest accounts and federation with an external identity provider affect how Nubus and the portal are configured and how users are sequenced. Confirm the identity federation design in the openDesk federation documentation.	One-time. Ask for the identity design, group mapping and the number of federated sources.
Kubernetes and production services	openDesk expects PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server, plus a Kubernetes cluster at v1.33 or later. Each service is a platform you run, patch and back up.	Mostly recurring for running these services, one-time for build. Ask who operates each service and what it costs in your own infrastructure.
Community or Enterprise Edition	ZenDiS recommends Enterprise Edition for production. It adds SLA-backed second and third level support, Enterprise-only modules and security patches, and it is sold as SaaS or for on-premises installation. Community Edition leaves support and patching to your own team.	Recurring subscription for Enterprise. Ask which edition is quoted, what support tier applies and who patches the bundled components.
Migration and cutover sequencing	Users and workloads moved in waves, plus parallel running and rollback planning, add effort. Mail, files and chat often have different cutover dates.	One-time. Ask for the wave plan, the subscription end date assumed, and the deletion timeline your tenant follows.

How to run Microsoft 365 and openDesk in parallel before cutover

Plan the coexistence period around one question: which workloads must work in both systems, and for how long. A practical split is to keep Exchange Online and Teams as the system of record until each user group is moved, while openDesk runs as a pilot tenant with its own identity source. Mail routing is the riskiest piece. Before any group moves, confirm with ZenDiS documentation how openDesk's groupware (OX App Suite) and the SMTP relay you run will accept inbound mail for domains that still point at Microsoft 365, and whether forwarding or split-domain routing is supported. Files are the second risk: do not allow two-way sync between OneDrive and Nextcloud on the same documents unless the vendors document that pattern, because conflicting edits are hard to unpick later. Confirm which federation options openDesk offers for your identity provider using the openDesk federation documentation, since that determines whether one sign-in can serve users on both sides.

Move users in groups rather than by department alone, and record the cutover order in a written runbook. A workable sequence for an illustrative organization with a few thousand users is a small pilot group of IT and records staff, then business units with low external mail volume, then the largest groups last. Each wave needs a checklist: confirm the mailbox export is complete, verify the target account, test shared mailboxes and calendars separately, and agree which Teams chats stop receiving new messages. Keep the Microsoft 365 tenant in place with its licenses until the retention and legal hold obligations for each group are met. Export and retention decisions depend on the license tier and the 14-day package expiry described in the export section, so set those dates before the first wave.

Plan the target against openDesk's release model, which shapes how long coexistence can last. ZenDiS plans major releases annually in Q3, minor releases monthly and patch releases on demand, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Build the project around a pinned release, then schedule a checkpoint before each major release to confirm upgrade steps and any intermediate versions. Check the current release at the time of planning in the openDesk release list. Ask your implementation partner and ZenDiS, in writing, which coexistence features exist for mail, files and chat, and which steps are manual. Any scope of work for running the two systems in parallel should be fixed in writing before the pilot begins.

What usually goes wrong and how to prevent it

Most failed Microsoft 365 moves to openDesk fail on time, not technology. Holds, expiring exports, lifecycle deletions and target platform choices all close off options that are hard to reopen. Each card names one failure mode and the check that prevents it.

Missed eDiscovery holds and expiry

Mailboxes and sites under legal hold can be exported, but only if the hold and the search are in place before the migration team starts copying. Export packages expire 14 days after creation, so a package generated early and downloaded late can disappear before the import is validated. Prevention: before each export wave, confirm the hold scope in Purview, record the search and package names, and download and checksum each package within the 14-day window.

Data deleted before export

Tenant data is not preserved automatically when a subscription lapses or a user leaves, so the migration timeline must finish before any licence or account change. Sequence the most important mailboxes and sites first, and confirm with Microsoft what retention applies to your subscription and to deleted accounts. Prevention: freeze licence changes for migrating users, keep a dated inventory of what has and has not been exported, and do not cancel the subscription until a verified copy exists in the target.

Outlook and Teams expectations

openDesk uses OX App Suite for groupware and Element with Nordeck widgets for chat, so users will not get Outlook or Teams desktop clients by default. Desktop Office habits, Teams meetings and Outlook add-ins will need replacements or a stated retirement date. Prevention: list the Outlook and Teams features your users rely on, test each against the openDesk components in a pilot group, and confirm with ZenDiS or your integrator which client protocols and integrations are supported before communicating a cutover date.

Version history loss

SharePoint and OneDrive version history is exported only if you select it, and a flat copy of the current file looks complete while losing the audit trail. Documents with approval or regulatory retention needs are the most exposed. Prevention: set the eDiscovery export to include version history for regulated libraries, verify version counts on a sample of files after import into Nextcloud, and record which document sets were migrated without history.

Unsupported Kubernetes or OpenShift targets

openDesk runs on Kubernetes and has documented prerequisites for the cluster, ingress, certificates and volumes. It is tested on kubespray clusters and not on OpenShift, so an existing OpenShift estate cannot be assumed to work. Prevention: check the requirements page against the target cluster before procurement, confirm the Kubernetes version and ingress controller in writing, and treat any OpenShift deployment as a separate validation project.

Skipping openDesk minor versions

openDesk ships monthly minor releases, supports only the latest minor version and does not guarantee in-place upgrades between majors. Installing an older snapshot and jumping several minors forward can require intermediate steps that are easy to miss. Prevention: pin the exact release in your deployment configuration, read the release notes for every minor between your start and target version, and rehearse the upgrade path in a non-production environment before go-live.

Underestimating identity and integration rebuilds

Entra ID groups, conditional access, mail flow rules, DLP policies and line-of-business connections to Exchange or SharePoint do not move with the mailbox data. openDesk identity runs on Nubus, and federation with an external identity provider is a separate configuration task. Prevention: inventory every integration that calls Microsoft Graph or SMTP, assign an owner and a rebuilt equivalent for each, and test user provisioning and federation before any mailbox is moved.

How the migration differs by organization size and starting point

Public administration and critical infrastructure bodies usually start with residency and accountability requirements that shape the whole project. openDesk was built for public administration, so the suite itself is a natural fit, but the hosting location, operators and support model must be settled before any mailbox moves. Scope often grows to cover records retention and legal hold obligations that exist inside the Microsoft 365 tenant today.

Hosting decision first: Confirm which data centers, cloud accounts or government networks will host the Kubernetes cluster and who holds administrative access.
Records and holds: Inventory retention labels and litigation holds in Purview, then decide how each category is preserved in the target system.
Enterprise edition: ZenDiS recommends the Enterprise Edition for production, which adds SLA-backed support and patches. Ask whether your regulator or internal policy requires a supported stack.
Longer sequencing: Pilot groups, sign-off on exports and approval of the cutover window usually take more calendar time than the technical copy.
Dependencies: Identity federation, SMTP relay and external services must be approved by the same bodies that approve the hosting.

Before committing, ask your DeployOpen contact or the openDesk team to confirm in writing which components of your data flow are covered by your residency rules.

Questions buyers ask before moving from Microsoft 365 to openDesk

How much effort and cost should we expect for a move to openDesk?

The cost depends on the scope you set, not on a single product fee, because openDesk is open-source software you install in your own infrastructure. The main components are the Kubernetes platform, the external production services openDesk expects (PostgreSQL, MariaDB, Redis, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server), the implementation and migration work, and ongoing operations. The ZenDiS documentation recommends the Enterprise Edition for production, which adds SLA-backed support and is sold as SaaS or for on-premises installation, so ask ZenDiS or a partner for its current terms. Costs rise with user count, storage volume, number of workloads moved and the number of integrations with identity, mail and line-of-business systems. Ask for a quote built from a written scope that lists each component, who pays for it and what recurs each year.

How long does a Microsoft 365 to openDesk migration take?

The duration varies with tenant size, data volume, the number of mailboxes and sites, how much history you keep, and how many Teams and SharePoint structures must be reshaped. Mailbox export is usually not the bottleneck; mapping permissions, groups and external sharing, and testing with pilot users, often is. Plan the platform build first, then pilot groups, then waves. Your timeline should also account for the subscription lifecycle, since your Microsoft 365 data must be exported before the tenant's retention and deletion rules apply. Ask any implementer for a phased plan with milestones and a named set of acceptance tests for each wave before accepting a date.

What must our internal team provide for an openDesk project?

Your team supplies the decisions and the access that an implementer cannot make for you. That includes the target cloud account, data center or air-gapped network; a Kubernetes cluster at v1.33 or later with an ingress controller, cert-manager and an RWO volume provisioner; identity source data and an approach for federation with your existing identity provider; DNS, TLS certificates and an SMTP relay; and named business owners who approve folder structures, retention rules and access groups. Your security team should also define logging, backup and patching responsibilities before go-live. Confirm these requirements against the current openDesk requirements documentation, since they change with each release.

Can our own team run openDesk without outside help?

Yes, it is possible to run openDesk with an internal team, because the deployment is open source and built on Helmfile and Helm charts licensed under Apache 2.0. The hard part is operating the stack continuously: openDesk plans annual major releases in Q3, monthly minor releases and on-demand patches, supports only the latest minor version, does not guarantee in-place upgrades between majors, and may require intermediate steps when skipping minor versions. Each bundled component also keeps its own license and upgrade path. Assess whether your team has Kubernetes, database and identity skills at production depth. If not, ask for a retainer covering upgrades, testing and support, and confirm whether ZenDiS Enterprise support is needed.

Will Outlook and desktop Office still work after moving to openDesk?

Confirm this before you commit, because openDesk does not provide Microsoft's desktop Office applications or a direct Outlook replacement. openDesk's groupware is built on OX App Suite, and its web office is Collabora, which edits ODF and Microsoft formats including .docx, .xlsx and .pptx. Users who rely on Outlook clients, Outlook add-ins, Teams meeting integrations or Office macros need a plan for each. Test those workflows with pilot users and check whether OX App Suite and Collabora support the protocols and features your users rely on. Document the gaps as explicit scope items, since they often drive training and change management costs.

How do eDiscovery exports from Microsoft 365 depend on our license?

Purview eDiscovery export requires a Microsoft 365 E3 or E5 license, so the cost of the export depends on the licenses you hold at the time you run it. Microsoft's documentation says export can produce PST or .msg files for mailbox items and native documents with selectable version history for SharePoint and OneDrive content. Search export packages expire 14 days after creation, so plan to download them within that window. Ask Microsoft or your reseller to confirm which licenses apply to your tenant and whether any add-on or consulting charges would apply to your case. Keep a record of export dates, scope and checksums for legal and compliance review.

What happens to our data if the Microsoft 365 subscription ends?

Data remains in Microsoft 365 only for as long as your contract and retention settings allow, so the safe approach is to export before the subscription lifecycle starts deleting data. Your tenant's contract terms, retention policies and any legal holds determine how long data is kept after cancellation, and those terms should be confirmed in writing with Microsoft or your reseller. Sequence users and workloads so that exports complete before deadlines, and verify restored content in openDesk against the exported set. Do not assume that an exported PST or document set is complete without checking counts, permissions and version history.

Primary sources for the export and openDesk requirements

Read three primary sources before you size anything: the Microsoft Learn page on exporting eDiscovery search results, the openDesk requirements and release management documents, and the openDesk Enterprise Edition documentation. Together they settle what you can extract from the tenant, what the target platform needs underneath it, and which support model you are buying. Assumptions made from marketing pages tend to surface late, when a mailbox export has already expired or a cluster is one Kubernetes version short.

Start with the Export search results in eDiscovery page. It confirms that mailbox items export as PST or .msg files and that SharePoint and OneDrive content exports as native documents with selectable version history. Two constraints matter for scheduling: search export packages expire 14 days after creation, and exporting requires an E3 or E5 license. Confirm with your Microsoft account team which licenses sit behind the eDiscovery roles you will use, and record who holds them, because a lapsed license or an unassigned role will stop the export before any data moves.

Then read the openDesk requirements and release management documents side by side. The requirements list the Kubernetes version floor, ingress and cert-manager choices, and the external PostgreSQL, MariaDB, Redis, SMTP, ClamAV and object storage services expected for production. The release notes state that only the latest minor version is supported and that in-place upgrades between majors are not guaranteed. Pin your target release and your upgrade path in the migration plan. Finally, read the Enterprise Edition documentation, which ZenDiS recommends for production. It settles which features and SLA-backed support come only with Enterprise, so the operating model is a decision you make now, not after cutover.

How DeployOpen works on this

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Microsoft 365 to openDesk move, we start with a written scope that maps each Exchange Online, SharePoint, OneDrive and Teams workload to its openDesk component before any data moves.

How we scope

Inventory mailboxes, sites, OneDrive accounts and Teams chats in scope, with owners and retention needs for each
Confirm the target Kubernetes cluster, ingress, storage and external services against openDesk requirements before design starts
Agree the export route for each workload, including whether Purview eDiscovery licensing is already in place

How we build

Deploy openDesk on your own Kubernetes infrastructure using the Helmfile and Helm deployment, with production services in place
Configure identity federation with your existing identity provider and test user sign-in before migrating any data
Run test migrations of sample mailboxes and sites, then check counts, permissions and document formats against the source

How we hand over

Deliver runbooks for the cutover order, user communication, rollback steps and the deletion dates set by your subscription
Document configuration, component versions, backup jobs and the upgrade path between openDesk releases
Provide evidence of tests and controls in a form your internal and external auditors can review

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Ask any provider, including us, to confirm in writing which openDesk edition, support level and patch process applies to your environment

Migrate from Microsoft 365 to openDesk