How to use a digital workplace suite requirements checklist
Before a team chooses openDesk or a Nextcloud-centred stack, it needs to settle each requirement as a decision that can be verified, not as a wish list. This checklist works that way: every line names a component, a setting, an owner and the evidence that proves the choice holds. Work through it in a fixed order: scope the components, settle identity and directory, fix the Kubernetes platform, define external services, choose the edition and support model, plan data migration, set security hardening, and finally fix the rollout order. Each step depends on the one before it. For example, the identity decision determines how users, groups and roles reach every bundled application, so it should not be left until rollout.
Different people own different lines. The CISO or security lead owns hardening and access control, the identity team owns directory federation and attribute mapping, the platform team owns the cluster and its external databases, caches, object storage, SMTP and antivirus services, and the business owner of each function owns migration and rollout order. Assign a named owner to every line before the first vendor call, because most open items in these projects are ownership gaps rather than technical ones. Treat the checklist as a starting point. Confirm each item with the vendor's current documentation and with your own environment, including your network, hosting location and procurement rules. Exact versions, hardware sizes, supported database releases, support hours and subscription terms change between releases, so ask each vendor for those values in writing and record the source document and date next to each answer.
Which components the workplace must cover and how to verify them
This table maps each workplace function to the open-source platforms named in our research, their licenses and how to confirm they fit your needs. Read it as a shortlist to test, not a verdict: the right candidate depends on the feature gaps and license terms you confirm in writing. openDesk bundles several of these components under different licenses, so license review must cover the bundle as well as each component.
| Component | Candidate platforms and licenses | Why it matters | How to verify |
|---|---|---|---|
| Files and sync | Nextcloud (AGPL-3.0), Seafile (GPLv2 with OpenSSL linking permission) | Files are the most sensitive store in the suite and drive sharing, retention and client sync rules. | Pilot sync and sharing with your largest folders, and confirm client, sharing and retention features in writing. |
| Office editing | ONLYOFFICE Docs (AGPL-3.0), Collabora Online (MPL-2.0), Nextcloud Office in some stacks | Office Open XML compatibility and co-authoring determine whether users keep working in familiar formats. | Test your real templates, macros and large spreadsheets in both editors, and confirm the license terms for your deployment model. |
| Mail and calendar | Stalwart (AGPL-3.0, optional Enterprise License), mailcow (GPL-3.0) | Mail carries retention duties and deliverability depends on DNS, reputation and relay design. | Run a coexistence pilot with your domain, test calendar invites with external providers and confirm retention and archiving options. |
| Chat | Mattermost (MIT compiled releases, AGPL-3.0 source), Rocket.Chat (MIT except ee directories), Synapse (AGPL-3.0) | Chat history can be records, and federation or enterprise features vary by edition. | Confirm message retention, export, SSO and any enterprise-only features in writing, and test federation only if you need it. |
| Video conferencing | Jitsi Meet (Apache-2.0), BigBlueButton (LGPL-3.0) | Video needs TURN and bandwidth planning, and recording rules differ by sector. | Load test with your remote user mix and confirm TURN, recording storage and browser support in a pilot. |
| Projects | OpenProject (GPL-3.0), Plane (AGPL-3.0) | Project data often holds commercial and personal details that need access control. | Map your workflows and permission model to the tool, and confirm edition differences for the features you need. |
| Wiki | BookStack (MIT), Outline (Business Source License 1.1) | Outline's additional use grant forbids using it to offer a commercial Document Service, so the use case must be checked. | Have counsel review the license against your planned use before selection, and confirm the content access model in a pilot. |
| Tickets (if in scope) | GLPI (GPL-3.0), iTop (AGPL-3.0), Zammad (AGPL-3.0), FreeScout (AGPL-3.0), osTicket (GPL-2.0) | Ticket systems often hold personal data and need their own retention and audit settings. | Confirm which service desk module you need, then test ticket intake, retention and audit logs with sample data. |
| Bundled suite (openDesk) | openDesk (Apache-2.0 deployment automation) bundling components under their own licenses, such as AGPL-3.0 for Nextcloud and Nubus, GPL-3.0 for OpenProject and MPL-2.0 for Collabora | A bundle does not change each component's license, so obligations for distribution, modification and network use apply per component. | Request a written license inventory for the exact release you plan to deploy and have counsel review each component's terms. |
Which identity model the suite needs before anything is installed
Identity is the first design decision for a self-hosted workplace suite because every component, from files to wiki to chat, needs to answer the same question: who is this user and what may they do. Settle where the user record lives, which protocol each component will use to trust it, and who changes it, before any Helm chart is applied. In an openDesk build, Nubus provides the portal and identity layer, and the external directory or identity provider is connected to it. In a Nextcloud-centred stack, Nextcloud can authenticate against LDAP or Active Directory through its LDAP app, and documents OpenID Connect and SAML backends as well. Keycloak is the common broker when the directory sits behind several sources or when a single OIDC client registration is preferred for each application.
For each directory source, the checklist owner should record the authoritative attributes and the matching rule. Confirm with the directory team which attribute is the stable unique identifier (it should not be a mutable display name or email address), how the username maps to the login field, and which group memberships will grant access to which workplace functions. Group mapping is where most rollouts stall: decide whether a group grants a role inside each application or whether the application only reads a claim, and write that mapping down per component. Joiner, mover and leaver handling also belongs here. Confirm how a new hire is provisioned, how a role change removes old group access, and how a departure disables sessions across files, mail and chat, since a removed directory account that still has an active application session is a common audit finding.
Name one owner for the directory and one owner for the broker configuration, and make them different people if your change process requires it. The directory team typically owns the source of truth; the platform team owns Keycloak realms, clients and the Operator-managed configuration. Ask the directory team whether LDAP or Active Directory will be read directly or through a synchronization service, whether service accounts with bind rights exist, and whether a test directory with representative users is available for pilots. Keycloak's own guidance calls for production databases with synchronous replication for its supported high availability designs, so confirm early who runs that database. Any decision about Entra ID needs its own assessment, since connecting it depends on the federation approach covered in the identity federation topic, and this checklist should record that as an open item rather than assume a path.
What the Kubernetes platform must provide for openDesk
This sequence confirms that the cluster, its supporting tooling and its sizing meet openDesk's stated prerequisites before any component is deployed. It also fixes who owns the platform after handover.
Confirm the Kubernetes distribution and version
Your platform team checks that the cluster runs a CNCF-certified Kubernetes distribution at v1.33 or later. Confirm the distribution itself before anything else: openDesk is tested on kubespray clusters and not on OpenShift, so an OpenShift estate needs a separate conversation with the openDesk maintainers or the implementation partner before any design work starts. The step is complete when the distribution name, version and certification status are written into the requirements record.
Provision an ingress controller and cert-manager
Platform engineers select the ingress controller that openDesk supports, either haproxy-ingress or the deprecated Ingress nginx, and install cert-manager to issue and renew the certificates used by the suite's public endpoints. Confirm that your certificate authority policy and DNS model can work with cert-manager. The step is complete when the controller serves a test endpoint with a valid certificate issued through cert-manager.
Verify a ReadWriteOnce volume provisioner
The storage team confirms that the cluster has a dynamic volume provisioner able to create ReadWriteOnce volumes, which openDesk's stateful components rely on. Ask the storage owner which storage class will be used, who carries the backup responsibility for it, and how volume expansion is handled. The step is complete when a test claim binds to a volume and can be deleted cleanly.
Install Helm and Helmfile at supported versions
The deployment engineer installs Helm 3.17.3 or later but below v4, along with Helmfile 1.0.0 or later, on the controlled workstation or pipeline runner used for deployments. Pin these versions in the build configuration so that every operator deploys with the same tools. The step is complete when the version commands return the expected values from the runner that will execute the deployment.
Size the cluster for evaluation or production
Decide whether this cluster is for evaluation or production, because the figures differ. The stated evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet. Production needs external services that the evaluation minimum does not cover, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. The step is complete when the sizing decision and the external service list are signed off by the platform owner.
Assign who operates the cluster
Name the team that runs the cluster day to day, covering node patching, Kubernetes upgrades, certificate renewal, storage, and on-call response. Confirm whether an in-house team, a managed service provider or an implementation partner holds each duty, and record it in a responsibility matrix. Ask any partner to state which parts of the platform it operates and which remain with you. The step is complete when every platform duty has a named owner and a backup owner.
Which external services the production workplace requires
openDesk expects production-grade external services rather than evaluation defaults, and each one needs an owner before installation starts. The cards below cover the databases, caches, mail, antivirus and media relay services that the platform team must decide on, back up and make highly available.
PostgreSQL 15 for application data
Several openDesk components store state in PostgreSQL 15, and the production requirement is a database service you can back up, restore and patch on your own schedule. Decide whether it runs in-cluster, as a managed service or on an existing enterprise database platform. Keycloak also supports PostgreSQL 14 to 18, and its high availability designs need a synchronously replicated database, so confirm the replication topology with the identity team before you choose the instance layout. Ask for a tested restore procedure and the recovery point the platform team can commit to.
MariaDB 10 for legacy components
openDesk expects MariaDB 10 as an external service for production, so the workplace stack carries a second relational engine next to PostgreSQL. Confirm which bundled components use it in the release you deploy, because that set changes between releases. Decide whether your database team already operates MariaDB 10 under a support agreement, or whether the suite gets a dedicated instance. Check backup frequency, point-in-time recovery and the upgrade path, since a database version that falls out of support becomes a security finding.
Redis 7 and Memcached for caching
Redis 7 and Memcached hold session and cache data that the workplace components read on nearly every request. Losing them usually means users are logged out or pages slow down, not that data is lost, so the decision is about availability rather than backup. Choose between an in-cluster cache, a managed cache or an existing enterprise cache, and confirm whether your sizing assumes one node or a replicated pair. Ask the platform team how cache failover interacts with the single sign-on session lifetime.
Cassandra for specific workloads
openDesk lists Cassandra among the production external services, which makes it an operational commitment with its own skills, storage and repair routines. Confirm with the ZenDiS documentation and your release notes which bundled component needs Cassandra in your version, and whether a lighter option is supported for your scale. If you must run it, decide who owns cluster health, repairs, backups and version upgrades, and whether that team already runs Cassandra in production.
SMTP relay for outbound mail
Workplace components send notifications, invitations and password resets, and they need an SMTP relay that your mail team controls. Decide whether the relay is your existing enterprise gateway, a dedicated relay in the cluster or a hosted relay, and confirm that its sender domain has SPF, DKIM and DMARC records in place. Check whether the relay accepts unauthenticated submissions from the cluster network, and who receives bounce and abuse reports. Mail routing is often the last item closed and the first one users notice, so settle it before pilot users arrive.
ClamAV over ICAP and object storage
File uploads and attachments must pass through ClamAV over ICAP before users can open them, which means the antivirus service must be reachable from the file and mail components and sized for peak upload volume. Object storage holds large file content for the suite, so confirm the storage class, versioning, encryption and whether it is the same backend your backup tool uses. Ask who patches the ClamAV signatures, how a scanning outage is handled (fail closed or fail open), and whether the object store keeps data in your required jurisdiction.
TURN server for real-time media
Chat calls and video sessions need a TURN server to relay media for users behind strict firewalls, proxies or NAT. The TURN service sits on the network edge, so the security team must approve its exposed ports, its credentials model and its logging. Decide whether you run coturn or another TURN implementation in your DMZ or use an existing enterprise relay. Test calls from the networks your users actually work from, including guest and home networks, because a default configuration often passes internal tests and fails in the field.
Community or Enterprise: which edition and support model to require
Settle the edition question before any component is installed, because it decides who answers when something breaks in production. ZenDiS, the company that develops openDesk, recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses as the Community build, but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. It can be bought as SaaS or installed on premises. Require the written edition choice in the statement of work, and confirm whether the license and support terms cover the openDesk platform only or each bundled component, since Nextcloud, OpenProject, Collabora and XWiki each carry their own license and their own vendor support path.
The Enterprise-only features named in the openDesk documentation are Collabora branding and automatic load scaling, the Element AdminBot, GroupSync and Admin Console, Nextcloud Enterprise security patches and the Guard app, OX S3 storage and advanced full-text search, OpenProject Enterprise add-ons, and XWiki Pro apps. Ask which of these your use cases depend on. Group synchronization and the admin console affect how identity and access are administered, so a gap there changes the identity design in the checklist, not only the license cost. Nextcloud is sold separately as Nextcloud Enterprise in Standard, Premium and Ultimate tiers, each with a 100-user minimum. According to the Nextcloud pricing page (Nextcloud pricing), list prices start at 71.29, 104.99 and 204.75 euros per user per year for 100 or more users, with lower rates from 200 users. Standard includes 1-year maintenance, Premium adds a maintenance lifecycle of 5 or more years and extended support hours, and Ultimate adds support up to 24/7 with response times down to 1 hour. Confirm current prices with Nextcloud, since list prices change.
For every component, request a written support scope before signing. It should state the support hours, the severity levels and response targets, who handles second and third level issues, which versions are covered, how long security patches are provided for each release, and whether upgrades between majors are included. Nextcloud does not allow skipping major releases, and openDesk supports only its latest minor version, so the support contract must match the upgrade cadence you plan to run. Ask the partner to map each component to its owner, the vendor or the implementer, so that a security fix in one layer does not wait on a support ticket in another. Record the answers as a dated checklist item, because the edition you select becomes the baseline for the upgrade rehearsal and budget discussed elsewhere in this page.
Which security controls the workplace suite must meet
A self-hosted workplace suite joins files, mail, chat, video and wiki under one identity layer, so a weakness in one component reaches the others. The six controls below are the ones to settle before rollout, and each one names the evidence you should be able to produce. The HIPAA Security Rule at 45 CFR 164.312(e)(1) and 164.312(b) asks for transmission protection and audit controls for systems holding ePHI, but mapping these controls to your own framework is your responsibility.
Transport encryption and certificates
Every browser, API, SMTP, TURN and database connection that carries user data needs TLS, and the certificate lifecycle needs an owner. openDesk expects cert-manager and an ingress controller in the cluster, so confirm which component issues each certificate and how renewals are monitored. Check the ingress configuration for disabled legacy protocols, confirm that internal service-to-service traffic is encrypted, and verify that the SMTP relay and TURN server accept only encrypted sessions. Test evidence should include a scan of each public endpoint and the certificate expiry report.
One identity provider with MFA
Files, mail, chat, wiki and project tools should authenticate against one identity provider, with multi-factor authentication and conditional access applied once rather than per application. Keycloak supports OpenID Connect and SAML 2.0 and is a common choice for this role, and Nextcloud's LDAP app and OIDC or SAML backends can point at it. Check that every application is registered as a client, that local fallback accounts are restricted, and that session lifetimes match your policy. Evidence includes a list of registered clients and a sample login log showing the MFA challenge.
Least-privilege admin roles
Platform administrators, application administrators and help desk staff should hold separate roles, and no single account should control the cluster, the identity provider and the mail server at once. Map each administrative action to a named role and review memberships on a fixed schedule. For openDesk, confirm which admin functions require the Enterprise Admin Console and GroupSync, and who may change them. Evidence includes the role matrix, a membership export and a sample of privileged actions taken during a test window.
Audit logging across components
Each component writes its own logs, and a single investigation may need to join identity events, file access, mail routing and chat history. Decide where logs go, how long they are kept and who can read them, and confirm that the central store is itself protected from the administrators whose actions it records. HIPAA's audit control requirement at 45 CFR 164.312(b) expects activity in ePHI systems to be recorded and examined, and recordkeeping rules such as SEC Rule 17a-4(b)(4) set separate retention periods for communications. Evidence includes a sample record from each component and a test showing that a deleted file or failed login appears in the central store.
Signed charts and pinned images
The suite is deployed from Helm charts and container images that come from several upstream projects, so supply chain controls decide what actually runs. Pin each image to a digest rather than a floating tag, verify chart signatures before install, and keep an internal registry copy of every version you approved. openDesk's deployment is Helmfile and Helm based and each bundled component keeps its own license, so record the version of every component in your bill of materials. Evidence includes the pinned version manifest, signature verification output from the install pipeline and the list of images mirrored internally.
Secrets management
Database passwords, SMTP credentials, antivirus and TURN secrets, and identity provider client secrets are needed by several components, and copying them into values files creates a leak path. Store them in a dedicated secrets system or sealed secrets mechanism, limit read access to the deployment pipeline, and rotate each secret on a documented schedule. Confirm that database and cache credentials differ per component and that no secret appears in logs or repository history. Evidence includes a list of secret locations, a rotation record for one secret and a repository scan showing no committed credentials.
Which compliance evidence the suite can produce and what it cannot
The suite can produce configuration records, audit logs, retention settings, access inputs and documented procedures, and these are what an assessor will ask to see. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, and they also decide whether the evidence is sufficient for the controls in scope. Settle that boundary early, so the team does not promise a result the suite cannot deliver on its own.
Each component should be asked to produce specific evidence. The identity layer, Keycloak or the directory behind openDesk, should show who signed in, from where and with which method, plus the role assignments used for periodic access reviews. Nextcloud, Mattermost or Synapse, and the mail server should keep audit logs and retention settings that match the retention period the buyer has mapped. Backup jobs should leave run records and restore test results. Confirm with each vendor which logs are native, which need a forwarder such as a SIEM, and how long the platform keeps them by default, because the answer changes the design.
Map the requirements before collecting evidence. For example, SEC Rule 17a-4(b)(4) requires broker-dealers to preserve communications for not less than three years, so chat and mail retention must be configured to that period and the retention settings must be provable. The HIPAA Security Rule requires transmission security under 164.312(e)(1) and audit controls under 164.312(b), so encryption-in-transit settings and audit record review need their own evidence trail. Your compliance lead and auditors should confirm which rules apply to your organization and which controls they map to, rather than assuming the suite covers them.
What buyers ask before choosing a platform and hiring help
How much effort does the requirements phase take for a self-hosted workplace suite?
The effort scales with the number of components in scope, the identity sources that must be connected, the volume of data to migrate and the compliance obligations that apply. A suite limited to files, chat and video with one directory is a much smaller exercise than a full workplace with mail, wiki, projects and migration from an existing productivity cloud. Each component adds its own configuration decisions, its own external service needs and its own evidence. Ask any partner to show how they scope these drivers and what they will produce in writing before work starts, since most engagements are fixed-scope and agreed in writing before work begins.
Can our own team complete the workplace requirements checklist alone?
Yes, a capable internal team can draft the checklist, but it needs people who can answer for each domain. The checklist touches the directory, Kubernetes operations, databases and object storage, mail routing, retention rules and the rollout order, and these rarely sit with one group. Teams often underestimate the time spent reconciling answers across groups and confirming vendor requirements against their own environment. A common middle path is to draft the checklist internally, then have an outside reviewer challenge the open items before procurement. Either way, the output should be a signed scope, not a list of assumptions.
Which people from our organization must be involved in the workplace requirements?
Four groups need to be involved from the start:
- Directory owners, who control Active Directory, LDAP or the identity provider and can confirm attribute names, group structures and account lifecycle.
- The platform engineering team, who will run Kubernetes, ingress, certificates and the external services the suite depends on.
- Data owners, who classify files, mail and chat content and decide retention, access and migration scope.
- Decision makers, who approve the edition, support model, budget and the rollout order.
If any of these groups is absent, the checklist will contain assumptions that surface later as delays. Confirm the named owner for each item before the requirements are signed off.
How do one-time and recurring costs split for a self-hosted workplace suite?
One-time costs cover planning, integration, identity configuration, data migration, hardening and rollout. Recurring costs cover infrastructure, external services, support subscriptions, upgrades and the staff who operate the platform. The main cost drivers are the number of users, the components in scope, the external production services required and the support level chosen. For Nextcloud Enterprise, the vendor's pricing page lists Standard, Premium and Ultimate tiers with a 100-user minimum, with list prices starting at 71.29 euros, 104.99 euros and 204.75 euros per user per year respectively for 100 or more users, and lower rates from 200 users. These are recurring list prices, so the total depends on the tier, the negotiated rate and the user count. Ask any quote to separate one-time services from annual subscriptions and to name each external service and who operates it.
Should we choose openDesk or a Nextcloud-centred stack for our workplace?
The choice depends on how much of the suite you need and how you want support delivered. openDesk is a Kubernetes-based suite provided by ZenDiS and bundles Element, Nextcloud, OX App Suite, XWiki, Nubus, OpenProject, Jitsi and Collabora, with Helmfile and Helm deployment and a Community and Enterprise edition. ZenDiS recommends the Enterprise Edition for production, and its requirements call for a CNCF-certified Kubernetes cluster at v1.33 or later. A Nextcloud-centred stack lets you pick components individually, which suits organizations that already run some services or that need a narrower scope. Nextcloud 35 was released on 16 September 2026, and Nextcloud does not allow skipping major releases, so plan upgrades either way. Compare both against your identity model, Kubernetes skills and support needs before deciding.
What should we ask an implementation partner before hiring one?
Ask for evidence of work on the components you plan to run, not general claims. Useful questions include:
- Which Kubernetes distributions have you deployed openDesk or similar suites on, and how do you handle the cluster versions the suite requires?
- How do you connect the suite to our directory, and which identity federation patterns have you used with Keycloak or LDAP?
- How do you handle upgrades, including major release sequencing and rehearsal in a staging environment?
- Who supports each component after go-live, and how are support responsibilities split between you, the vendor and our team?
- What does the fixed-scope written agreement cover, and what is excluded?
Request written answers and check them against the scope document before signing.
Which compliance evidence should the requirements checklist capture from the start?
Capture the evidence each regulation expects before the build starts, because retrofitting it is costly. For communications in regulated financial firms, the SEC's rule under 17 CFR 240.17a-4 requires preservation of business communications, including inter-office messages, for not less than three years, which affects mail and chat retention settings. For healthcare, the HIPAA Security Rule at 45 CFR 164.312 requires transmission security for ePHI and audit controls that record and examine activity in systems holding ePHI. Your checklist should name the systems that hold these records, the retention period, the audit log destination and who reviews it. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit report or attestation.
In what order to roll out the suite components
The rollout sequence moves from identity and platform foundations to a pilot group, then to identity-linked services, collaboration tools and finally wiki and project work, so each layer is proven before the next depends on it. Each step ends with a rollback checkpoint, and the buyer should confirm this sequence with the implementation partner against their own dependencies and risk tolerance.
Settle identity and directory first
Before any workload goes live, the identity design is fixed: which directory is the source of truth, how users and groups are provisioned, whether an external identity provider such as Keycloak federates to Active Directory or another source, and how attributes map to each application. The implementation partner and the identity owner sign off on a written design. The step is done when a test user can sign in through the chosen identity path and group membership resolves correctly. Rollback point: if the design fails testing, nothing else is deployed against it, so changes stay cheap.
Build the Kubernetes platform and external services
The platform team prepares the cluster, ingress, certificate management, storage and the external services the suite depends on, such as production databases, caches, object storage, an SMTP relay, antivirus and a TURN server. Versions are checked against the openDesk requirements in effect at the time of build, and the team confirms which services are operated by the client and which by the partner. The step closes when backups restore successfully, monitoring reports on every service and the cluster passes the agreed health checks. Rollback point: the platform is accepted only after a restore test, so the team knows recovery works before users arrive.
Run a pilot with a small user group
A limited group of users, often an IT or program team with tolerance for early issues, signs in through the identity design and uses the core services in conditions close to production. The team records login failures, performance issues, file sharing gaps and support requests, and feeds them back into configuration. The step is done when the agreed pilot exit criteria are met and reviewed by the business owner. Rollback point: if the pilot fails exit criteria, the group returns to existing tools while the team fixes the defects, and no wider rollout begins.
Deploy files and mail on the identity layer
Files and mail come next because they depend directly on identity and are used by almost everyone. The team connects file sharing, mail, calendar and contacts to the directory, sets retention and mail routing according to the client's policies, and migrates data in tested batches. Each batch is verified against source counts and sampled content. The step closes when mail flows in and out, shared folders match access rules, and migration reconciliation reports are signed off. Rollback point: migration batches are reversible until the cutover is accepted, so the team keeps source systems readable during this phase.
Add chat and video conferencing
Chat and video depend on the identity layer, the TURN service and, for some designs, the same certificate and network paths already proven in earlier steps. The team tests presence, notifications, file sharing inside chat, and meeting join across networks that include NAT and restricted sites. Retention and compliance settings for messages are confirmed with the compliance owner before users are onboarded. The step is done when cross-network meeting tests pass and messaging retention behaves as documented. Rollback point: chat and video can be disabled independently without affecting files and mail.
Enable wiki, projects and remaining components
Wiki and project management are deployed last because they hold the most structured content and depend on access rules set in earlier steps. The team imports content with permissions mapped to groups, configures project templates, and checks that editors can reach only the spaces they should. Any components with separate editions or license terms are validated against the support and feature decisions made at the start. The step closes when access tests are signed off and content owners confirm imported material. Rollback point: each application can be frozen or restored from its own backup without touching the rest of the suite.
Confirm the sequence and handover with the partner
Before the rollout plan is accepted, the buyer and the implementation partner review the order against the client's own dependencies, change windows, regulatory deadlines and risk appetite. Any change to the sequence is recorded with its reason, and the partner confirms the runbook for each checkpoint. The step is done when both parties sign the rollout plan and the operations team has rehearsed at least one rollback. Ask the partner to show how each checkpoint is tested, who makes the go or no-go decision, and how upgrade rehearsals fit into the schedule.
Questions that separate workplace suite platforms in evaluation
Put licensing and edition questions first, because they decide what you actually pay for and what you can run without asking anyone. Ask each vendor to list every component in scope, its license, and which features or modules are Enterprise-only. For openDesk, the open-source core is Apache-2.0 for the deployment automation, with each bundled component keeping its own license, but ZenDiS recommends Enterprise Edition for production because it adds closed-source modules and SLA-backed 2nd and 3rd level support. Ask the partner to mark, per component, which features would be missing on Community Edition and whether those gaps touch identity, audit logging or patching. Score each answer as complete, partial or unanswered, and reject any answer that names a component without a license.
Next, make vendors name the exact Kubernetes and database versions they test, not the versions they support in general. The openDesk requirements call for a CNCF-certified cluster at v1.33 or later, and the documentation states it is tested on kubespray clusters and not on OpenShift, so ask whether your distribution is in that tested set. For databases, ask for the exact PostgreSQL, MariaDB and Redis versions used in the reference configuration and the version of each component's own database, such as Nextcloud's recommended MariaDB 11.8 or PostgreSQL 18. Also ask how upgrades between majors work. Nextcloud does not allow skipping major releases, and openDesk does not guarantee in-place major upgrades, so require a written upgrade path and a rehearsal plan in your own environment before you sign.
How DeployOpen scopes, delivers and supports workplace suite selection and implementation
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a digital workplace suite, that means turning the requirements in this checklist into a written scope, building the stack in your cloud, data center or air-gapped network, and handing over the configuration and evidence your team needs to run it.
How we scope
- Confirm which workplace components are in scope, such as files, office, mail, chat, video, wiki and projects.
- Record the identity source, Kubernetes platform, external services and edition decisions in one written scope.
- Agree deliverables, timelines and exclusions in writing before any work starts, as engagements are fixed-scope.
How we build
- Deploy the agreed components inside your own infrastructure, with identity federation configured for your directory.
- Configure external PostgreSQL, Redis, object storage, SMTP, antivirus and TURN services to match the platform requirements.
- Test upgrade paths and hardening settings against the agreed rollout order before users join each component.
How we hand over
- Document the architecture, configuration, component versions and each component's license and edition in use.
- Provide runbooks for backups, upgrades, identity changes and incident handling, sized to your operations team.
- Prepare the access control, audit logging and configuration evidence your compliance assessors will ask for, without issuing any attestation ourselves.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan recurring upgrades around the release cadence of each component, reviewing changes before they reach production.
- Confirm support boundaries in writing, including which components depend on a vendor's paid edition or support contract.
