Digital workplace suite RFP questions for vendors

Which digital workplace suite RFP questions matter before you shortlist a partner

Run the evaluation by sending every shortlisted partner the same written scope, asking for written answers, and scoring those answers against named evidence rather than against presentations. The questions that matter most test the partner on six areas: Kubernetes operation, handling of Enterprise editions, identity integration, upgrade practice, migration of mail and files, and support across every component. A regulated or public organization replacing a productivity cloud or legacy tools needs a partner that will plan, build and run the suite, so each answer should name the people, tooling and records behind it. The questions below are neutral across openDesk and Nextcloud-centred stacks. DeployOpen's own position is stated only in its how-we-work material, not in the question set.

Ask every partner for the Kubernetes version it has operated in production and the tooling it uses to deploy and roll back. openDesk requires a CNCF-certified cluster at v1.33 or later and is tested on kubespray clusters and not on OpenShift, so ask whether the partner has run that exact combination and where it has not. For Enterprise handling, ask which Enterprise Edition components the partner would license, who signs the support contract, and how it will separate closed-source modules from the open-source core in your change records. For identity, ask how the partner federates users from your directory into the suite, which directory attributes it matches, and how it handles a stale account. Nextcloud's LDAP app and its OpenID Connect and SAML backends are documented options that a partner should explain in the context of your identity provider.

Ask for the upgrade calendar the partner will follow. openDesk releases major versions annually, minor versions monthly and patches on demand, and it supports only the latest minor version, so ask how the partner will rehearse each upgrade in a non-production environment. Nextcloud does not allow skipping major releases, so ask for the upgrade path across its four-month major cadence. For migration, ask how mail, calendar and files will be moved, what gets verified after each batch, and who is accountable for retention obligations. Where records must be kept for regulatory reasons, such as the three-year preservation period for broker-dealer communications under 17 CFR 240.17a-4, ask the partner to show how migrated data stays searchable. Finally, ask which party provides first, second and third line support for each component, what response times are written into the contract, and what happens when a component sits outside the vendor's support scope. Do not ask for prices in the RFP response. DeployOpen does not publish a price list, and cost questions should be answered through a written scope that lists each component, environment and support obligation.

Kubernetes experience: what to ask about openDesk hosting

Which Kubernetes versions has the partner run openDesk on?

Ask for named cluster versions and the date each was last deployed, because openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later. A credible answer names the exact version in production, the upgrade path they followed, and whether they have tested openDesk minor releases on that version. Ask how they handle a cluster that falls below v1.33 during your engagement, and whether they will pin the version in writing. A vague answer such as "we have done many Kubernetes projects" tells you nothing about openDesk. Red flag: no named version, or a version below the requirement with no plan to upgrade.

Has the partner deployed openDesk on kubespray clusters or OpenShift?

openDesk is tested on kubespray-built clusters and not on OpenShift, so the partner should say which of these they have actually run it on. Ask for the cluster build method, the operating system, and how node pools, network plugin and control plane were configured. If your platform team standardizes on OpenShift, ask what adaptation work the partner estimates and who owns the risk of an unsupported platform. Red flag: a partner who says OpenShift works "the same way" without evidence or a written statement of what changes.

How does the partner handle ingress and cert-manager on openDesk?

openDesk needs an ingress controller, either haproxy-ingress or the deprecated Ingress nginx, plus cert-manager for certificates. Ask which controller the partner has used in production, how they issue and rotate certificates for your public and internal names, and whether they integrate with your internal certificate authority. Ask who owns the DNS records and the TLS private keys after handover. Good answers describe the certificate issuers, renewal monitoring and a documented fallback if renewal fails. Red flag: choosing Ingress nginx for a new production build without discussing its deprecated status.

Which storage classes and RWO volume provisioner will openDesk use?

openDesk needs an RWO volume provisioner, so ask which storage backend the partner will bind to it and how it performs under load. Ask for the storage class names, reclaim policy, snapshot support and how backups of persistent volumes are taken and restored. Also ask how the storage design interacts with the external PostgreSQL, MariaDB, Redis and object storage services, since those usually carry the stateful data. A strong answer ties each stateful component to a named owner and a restore test. Red flag: no restore test, or storage described only as "default" without naming the provisioner.

Which Helm and Helmfile versions does the partner standardize on?

openDesk deployment uses Helm and Helmfile, and its requirements call for Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. Ask which exact versions the partner pins in their toolchain, how they store and review Helmfile environment values, and how they handle chart updates from the openDesk releases. Ask whether deployments run from a GitOps pipeline or by hand, and who holds the credentials. Red flag: a partner who installs Helm 4 without checking openDesk's stated range, or who cannot show the values files under version control.

Who owns PostgreSQL, MariaDB, Redis, object storage, SMTP, ClamAV and TURN?

openDesk expects production-grade external services, including PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Ask the partner to produce a responsibility matrix that names who provides, operates, patches and backs up each service: your platform team, a managed database service, or the partner. Ask which of these run inside your cluster and which run outside it, and how they are sized. Confirm the exact database versions with the openDesk requirements before you sign. Red flag: a quote that leaves these services out or lists them as "customer responsibility" with no hand-off plan.

What cluster reference architecture should the partner propose?

A useful reference architecture shows the node pools, control plane count, availability zones, ingress placement, storage tiers, and where each external service runs. Ask the partner to draw the evaluation layout and the production layout separately, since openDesk's evaluation minimum (12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk) is not a production sizing. Ask how they will test failover of a node and of an external database, and what capacity headroom they reserve for monthly minor releases. Red flag: a single diagram that serves for both evaluation and production, or no failover test plan.

How long will the partner's Kubernetes work take, and what drives it?

The duration depends on the cluster you already run, the external services you need to build, and how many components are in scope. Ask for a fixed-scope plan that lists the cluster work, the service build, the integration tests and the handover steps as separate line items with their own dates. Most engagements are fixed-scope and agreed in writing before work starts, so ask for the scope, deliverables and timeline in that document. Confirm the openDesk release cadence against your planned go-live, since minor releases arrive monthly. Red flag: a timeline quoted before the partner has seen your existing cluster and service inventory.

How to handle openDesk Enterprise Edition and Nextcloud Enterprise in the bid

The Community route runs openDesk on the open-source core licenses, with Apache-2.0 for the deployment automation and each bundled component under its own license, such as AGPL-3.0 for Nextcloud and Nubus and GPL-3.0 for OpenProject. Support, patching and upgrade work then come from the partner and your own platform team rather than from a vendor contract. Ask the partner to show how they will track the monthly minor releases, since ZenDiS supports only the latest minor version, and how they will apply security fixes between them.

Support boundary: Ask who answers 2nd and 3rd level incidents across every bundled component, and whether that is covered by a written retainer or by time and materials.
Patch ownership: Ask who tests and deploys patch releases, and how long a critical fix can wait for a change window.
Upgrade path: Ask how the partner handles major releases, which are not guaranteed to upgrade in place, and skipped minor versions that may need intermediate steps.
Closed-source gaps: Confirm that no module in the proposed scope depends on Enterprise-only components, and list any feature that would be missing.
Cost owner: State which costs fall on you (staff, retainers, external services) and which fall on the partner.

Check that the partner's written answer names each component and the person or team responsible for it.

How Keycloak and directory federation questions expose the real design

Identity is the layer where most suite projects slip, because every component in a digital workplace suite trusts the same identity source, and a weak answer here affects files, mail, chat, wiki and project tools at once. Ask the partner to name the identity source of record for each user group, and to state whether the suite will federate to an existing identity provider over OpenID Connect or SAML 2.0, connect directly to LDAP or Active Directory, or place Keycloak in the middle as the broker. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0 and provides identity brokering and user federation, so it can sit between the suite and an upstream provider. Nextcloud's LDAP app and its OpenID Connect and SAML backends show the same choice from the file-sharing side. Confirm which of these paths each bundled component supports in the version you will deploy, because openDesk's own identity layer is Nubus, not Keycloak.

Attribute mapping and user lifecycle decide whether access is correct after day one. Ask how the partner maps the directory attributes that drive roles, group membership and mail addresses, who owns that mapping, and how a joiner, mover or leaver event reaches every component. A deprovisioning test should remove a user from the directory and confirm that sessions, shared links, app tokens and group rights stop working in each tool, with the result recorded as evidence. For Keycloak, the partner should explain the database and high-availability design. Keycloak's supported high-availability designs require a synchronously replicated database, and the Keycloak Operator documentation strongly recommends manual approval mode for operator updates to avoid unintended automatic upgrades. Ask who approves each update and how that approval is recorded.

Ask for the partner's high-availability design in writing, including the database topology, the availability zones or sites involved, and the failover path for the identity layer. Then ask for a written failover test plan that names the scenario, the expected behavior, the owner of each step and the pass criteria. A plan that has never been run against your directory and database is a risk you should price into the scope before signing. Use the Keycloak high availability overview as the reference the partner must map its design against, and request a demonstration of a failed node during a test window.

Upgrade cadence questions that determine long-term effort

Each component in a workplace suite ships on its own clock, and the upgrade rules differ sharply between openDesk, Nextcloud and Keycloak. The cards below cover the questions that set your long-term operating effort, and what the partner must commit to in writing before you sign.

openDesk minor and major release rhythm

openDesk ships major releases once a year in Q3 and minor releases monthly, and only the latest minor version is supported. In-place upgrades between majors are not guaranteed, and skipping several minor versions may require intermediate steps. Ask the partner to state in writing which minor version they will keep you on, how far behind they will allow you to fall, and whether a major upgrade is priced and scheduled as a separate project. The reader must own the staging environment, the maintenance windows and the decision on when to adopt each monthly release.

Nextcloud one-major-at-a-time rule

Nextcloud does not allow skipping major releases, so each upgrade moves one major version forward and requires a backup first. Third-party apps must be disabled until confirmed compatible, which makes app inventory part of every upgrade plan. Nextcloud 35 is supported until September 2027, and the four-month major cadence means a version can fall out of support faster than a multi-year platform. Ask the partner how they map the upgrade path, who validates each app, and how many majors they will carry you through in a single year.

Keycloak minor releases and opt-in changes

Keycloak plans four minor releases a year, and since Keycloak 26.0 breaking changes in a minor release are opt-in. This reduces surprise but still means your realm configuration, custom authenticators and operator-managed resources must be reviewed on each release. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates. Ask the partner whether they will run operator updates in manual approval, who reviews the release notes, and whether database schema migration runs automatically at startup or as a reviewed SQL step for your size of deployment.

Staging tests and documented rollback

Each component above needs a staging copy of production data, configuration and integrations before any change reaches users. Ask the partner to describe how they clone the environment, which test cases they run for identity login, file sync, office editing and mail flow, and how long a rollback takes for each component, including database restores. Require a written rollback procedure per component and a record of which versions were tested together. The reader must own the business sign-off on test results and the decision to proceed or stop.

Support scope across version changes

Support obligations differ by vendor and edition. Nextcloud Enterprise tiers carry different maintenance lifecycles, and openDesk Enterprise Edition adds SLA-backed second and third level support and patches. Ask the partner which component versions they will support, whether they cover upgrades in the fixed-price scope or as a retainer, and how they handle a security fix that lands between scheduled windows. Confirm in writing which vendor responsibilities remain with you, such as Kubernetes version upgrades that openDesk requires to stay current.

Migration questions for mail, files and identity

This sequence shows the order in which a partner should move mail, files and identity from the current system to the new suite, with a named output at each stage. Asking about each step lets you compare proposals on evidence rather than on promised speed.

Inventory mail, files and calendars
The partner catalogs every mailbox, shared mailbox, distribution list, calendar, contact book, file share and document library in scope, with owner, size, age and any legal hold or retention rule attached to each. Ask for the inventory template they use and who on your side signs off on scope. The step is complete when you hold a written inventory that lists what is excluded and why.
Map retention and compliance obligations
Before any data moves, the partner maps each data class to the retention and audit requirements that apply to it, such as the three-year preservation period for broker-dealer communications in 17 CFR 240.17a-4 or the audit controls in 45 CFR 164.312 for ePHI. Ask which of your obligations they have confirmed with your legal or compliance team and which remain open. The output is a retention matrix that the migration must preserve.
Define coexistence and cutover order
The partner proposes how old and new systems run side by side, including mail routing, calendar free/busy visibility, external sharing links and the order in which user groups move. Ask how mail flow is redirected during the transition and how users reach files that have not yet moved. The step closes with a written cutover plan that names each wave, its entry and exit checks and who approves it.
Cut over identity and access
The partner sets up identity federation so that users authenticate against one identity source during and after migration, and confirms how directory attributes, group membership and disabled accounts are matched. Ask which identity provider or directory bridge is used, how service accounts are handled and how access is removed from the legacy system. Evidence of completion is a test login matrix covering each user group, plus a list of accounts that were reconciled or deliberately excluded.
Run test migrations on copies
Before production, the partner runs full test migrations of mail, files and calendars against copies of source data, using named tooling such as an IMAP sync tool, a file migration utility or a vendor import process. Ask for the tool names, the versions used, the logs they produce and how mismatches are reported. The output is a test report showing item counts, failed items and the remediation applied to each failure.
Validate migrated data against source
The partner compares source and target for message counts, folder structure, attachment integrity, file checksums, permissions and preserved timestamps, and checks that retention settings and legal holds were carried over. Ask which sample sizes and checksum methods they use and who signs the validation result. The step is done when a documented reconciliation shows zero unexplained differences, or when every remaining difference has a recorded owner and decision.
Rehearse rollback and sign off
The partner documents the rollback path for each wave, including how mail routing is reversed, how identity is restored and what happens to data written to the new system during a rollback. Ask them to rehearse at least one rollback on a copy before production and to name the decision owner. Sign-off is complete when the rehearsal log, the rollback runbook and the production cutover record are filed together with the retention evidence.

Support across all components: who answers when a bundled component fails

Who is the single accountable owner when Nextcloud, Element or OpenProject fails inside a bundled suite?

The accountable owner should be named in writing before go-live, and it should be one party for the whole suite, even when the fault sits in a component built by someone else. Ask the partner to show a RACI matrix that lists each bundled component (for example Nextcloud, OX App Suite, Element, OpenProject, XWiki, Jitsi and Collabora) with who triages, who fixes configuration, who fixes code and who communicates with you. Confirm whether the component vendor's support contract is yours to buy separately, and who opens that ticket on your behalf. Ask for the escalation path in writing, including who is called at 2 a.m. on a Sunday.

How do vendor support boundaries and component licenses affect who fixes a problem?

Each component keeps its own license and its own vendor, so the support boundary follows the code, not the deployment tooling. openDesk's deployment automation is Apache-2.0, while components such as Nextcloud and Nubus are AGPL-3.0, OpenProject is GPL-3.0 and Collabora is MPL-2.0. Ask the partner to map every component to one of three answers: supported by the partner, supported by the vendor under a paid contract, or community support only. For openDesk, ask what the Enterprise Edition from ZenDiS covers in terms of SLA-backed second and third level support, and which of those tickets the partner can file on your behalf.

What incident response times should the partner commit to in writing for each component?

Response times should be written per component and per severity, and they should state what the clock starts on. Ask for a severity matrix that defines what counts as a critical outage for mail, chat or files, and what the first response, the workaround and the fix targets are for each. Do not accept a single blanket figure for the whole suite, because a broken Element homeserver and a cosmetic XWiki issue have different impact. Confirm whether these targets are part of the fixed-scope agreement or a retainer, and what happens outside business hours. Any figure you are quoted should appear in the signed scope document, not only in a sales deck.

How does the partner take in patches from upstream projects and test them before production?

Ask the partner to describe the patch intake path from each upstream project to your environment, step by step. For openDesk, the release model is annual major releases in Q3, monthly minor releases and on-demand patches, with only the latest minor version supported. For Nextcloud, each major version receives monthly maintenance releases for one year. The partner should show how it tracks these cycles, applies them to a staging environment that mirrors production, runs regression checks across all components and keeps a rollback plan. Ask how many minor releases behind the partner is allowed to fall, since skipping several minor versions may need intermediate steps.

How are security advisories for each bundled component tracked and acted on?

Ask for a written process that subscribes to each component's security channel, records every advisory against the components you run, and assigns a severity and a patch deadline. The process should cover the Nextcloud and openDesk security notices, Keycloak and Nubus identity advisories, and the base images and Helm charts. Ask how the partner decides between an out-of-cycle patch and waiting for the next scheduled release, and who signs off on that decision. Request a sample advisory register from a previous engagement that you can review, with personal or client details removed.

What evidence does each component produce during incident handling, and who keeps it?

Evidence should be defined per component before an incident, not reconstructed afterwards. Typical sources include Nextcloud audit and activity logs, Keycloak event logs and metrics, Kubernetes pod and ingress logs, mail server delivery logs and chat server logs. Ask the partner to list each source, its retention period, where it is shipped, who can read it and how it is exported for a post-incident review. For regulated organizations, confirm that the evidence supports the audit controls your regulator expects, such as the audit-control expectations in 45 CFR 164.312(b) where ePHI is involved. Clarify that the partner prepares and retains operational evidence, but independent auditors or certification bodies, not DeployOpen, issue any assurance report.

Can the partner support the whole suite, or only its own deployment scripts?

A credible partner supports the full running system: the components, the Kubernetes platform beneath them, the identity layer that connects them and the external services they depend on, such as PostgreSQL, Redis, SMTP, antivirus and TURN. Be cautious of any offer that covers only the partner's own scripts or Helm values. Ask the partner to show how a failure in an upstream component is diagnosed, which vendor it is escalated to and who keeps you informed during that process. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and the written scope should state exactly which components and layers are included.

What should be in the support scope to avoid gaps after go-live?

Put the support scope in the fixed-scope document before work starts, listing every component, version, environment and channel covered. Include the upgrade path, since openDesk does not guarantee in-place upgrades between majors and Nextcloud does not allow skipping major releases. Confirm whether support covers user administration questions, integration breakages with mail or directory systems, and performance incidents. Ask what is excluded, for example custom apps or changes made by your own staff, and what the change request process costs in time. Ongoing support, upgrades and continuous testing are available as retainers, so ask which items sit inside the retainer and which are billed per request.

How to score partner answers in the evaluation

This table sets out what a full-marks answer, a partial answer and a disqualifying answer look like for each area the RFP covers. Use it to score written responses and follow-up demonstrations on the same scale, and treat any disqualifying answer as a reason to stop the evaluation for that bidder until it is resolved in writing.

Area	Full marks require	Partial marks look like	Disqualifies
Kubernetes experience	Named clusters running openDesk or comparable Helm and Helmfile stacks, with the Kubernetes version, ingress controller, cert-manager and storage provisioner stated against the supplied requirements	Generic Kubernetes claims, no named cluster or version, or no plan for the external PostgreSQL, Redis, object storage and TURN services	Proposes a platform outside the stated requirements without a written justification, or cannot describe how the cluster is operated after go-live
Enterprise Edition handling	Explains where Community and Enterprise differ for each component, states which features the design depends on, and prices the Enterprise subscription as a separate line item	Recommends Enterprise in general terms but does not map features to the requirement or leaves licensing to a later phase	Designs a production system on Community components without addressing the support gap, or hides subscription costs inside services fees
Identity federation	Demonstrates federation to the existing directory through a named broker, with attribute mapping, group sync, joiner and leaver tests and a fallback login plan	Describes SSO in principle, without naming the directory connector, attribute matching or how disabled accounts are removed	Plans local accounts as the primary identity source or cannot state which system is authoritative for user lifecycle
Upgrade approach	Written cadence for each component, a staging environment that mirrors production, a rehearsal in a non-production environment before each release, and rollback steps tied to backups	Upgrades described as routine or manual, without rehearsal, pinning rules or a process for skipped versions	Plans in-place upgrades across several major versions or disables backups or change control during upgrades
Migration of mail and files	Dated migration waves, inventory of mailboxes and file shares, checksum or count validation, coexistence rules and a cutover and rollback plan per wave	Migration tooling named but no validation method, or coexistence and cutover left for a later stage	No inventory of source data, no test migration, or proposes moving retention-relevant mail without preserving originals
Component support across the suite	One named accountable owner for each component, a support matrix stating response levels per component, and a written path for issues that span components	Support offered for the core platform only, with bundled components referred to upstream communities without a defined contact	No defined support for one or more in-scope components, or support terms that exclude the components most likely to fail
Security hardening	Hardening baseline per component, network policies, secrets handling, signed charts and pinned images, and a documented method for verifying them in an air-gapped or restricted environment where required	Hardening described as a checklist without evidence, or image pinning limited to some components	Relies on default configurations in production or cannot explain how images and charts are verified before deployment
Evidence quality	Sample logs, configuration exports, backup restore records, access reviews and change records that map to the controls the organization must support, with clear statements of what the evidence does not prove	Evidence described in general terms, or delivered only as screenshots without retention or access controls	Offers certification or audit outcomes as a deliverable, or cannot show any evidence from a comparable deployment

Answers that should worry you in a digital workplace suite bid

A digital workplace suite bundles identity, Kubernetes, groupware, files and office editing into one operating commitment. The answers below separate partners who have run this stack from those who have only read about it, and each card names the follow-up that exposes the difference.

Vague Kubernetes platform claims

A partner who cannot name the Kubernetes version and distribution it has tested is guessing about your cluster. openDesk requires a CNCF-certified cluster at v1.33 or later, plus an ingress controller, cert-manager, an RWO volume provisioner, Helm and Helmfile. Ask: which distribution and version did you deploy openDesk on, and what did you change to make it work? Ask for the cluster build used in their last production handover.

openDesk treated as one product

openDesk is a bundle. Each component keeps its own license, such as AGPL-3.0 for Nextcloud and GPL-3.0 for OpenProject, and some components have separate Enterprise terms. A partner who quotes a single license and a single support contract has not mapped the stack. Ask: which components will you support at what level, and which license terms apply to each one in our deployment? Request a per-component table in writing.

In-place major upgrades without a rehearsal

Major releases of openDesk are planned annually, minor releases monthly, and in-place upgrades between majors are not guaranteed. Nextcloud also forbids skipping major versions. A partner promising seamless major upgrades without a staging rehearsal is accepting risk they should price. Ask: describe the staging environment, the rollback path and the intermediate steps you would run to move from our current minor version to the next major.

Avoidance of Enterprise Edition questions

ZenDiS recommends openDesk Enterprise Edition for production, which adds SLA-backed second and third level support, patches and closed-source modules. Nextcloud Enterprise adds support tiers and a maintenance lifecycle. A partner who deflects questions about these editions will leave you with unsupported components in production. Ask: which features will we lack on Community editions, who supplies patches for them, and what does each support tier cover?

Identity federation failure modes unexplained

Federating openDesk or a Nextcloud stack with an existing directory is where most access incidents start. A partner should describe what happens when the identity provider is unreachable, when attributes do not match, when a user is disabled upstream, and how sessions are revoked across components. Ask: walk us through what each component does during an IdP outage and how you would test deprovisioning end to end.

Price quoted without written scope

A per-user or per-month figure with no written scope cannot be compared, because component count, external services, migration volume and operations staffing change the total far more than the license. DeployOpen works from fixed, written scopes before work starts. Ask: what is in the quote, which external services and migration tasks are excluded, and which costs recur after go-live? Require a scope document before any price comparison.

Audit or certification outcomes promised

Some workplace records need evidence aligned with rules such as the SEC Rule 17a-4(b)(4) three-year retention requirement or HIPAA audit controls under 45 CFR 164.312(b). A partner can prepare systems and evidence, but only independent auditors issue reports or certifications. Ask: which evidence will you produce, which controls does it support, and who in our organization or an independent auditor signs off on the result?

What buyers ask before hiring outside help for a workplace suite

The first question most buyers raise is what drives cost, and the honest answer is scope. The main variables are how many components go live (files, office, mail, chat, video, wiki and projects each add configuration, testing and user support), whether the production setup uses openDesk Enterprise Edition or Enterprise subscriptions for individual components, how many external services must be provisioned (PostgreSQL, MariaDB, Redis, object storage, an SMTP relay, ClamAV over ICAP and a TURN server, depending on the design), how much mail, file and chat history must move, and who will operate the result after go-live. Some costs are one-time, such as design, integration and migration. Others recur, including subscriptions, infrastructure and operations staff. Ask every bidder to split their quote along those lines and to name who is paid for each line, whether that is the vendor, a partner, your cloud provider or your own team.

On timing, buyers often ask for a duration before the scope is written. DeployOpen does not publish prices, and a quote follows from a written scope that names the components, the identity sources, the environments and the migration volumes involved. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Be cautious with any bidder who gives a single number without that document. To make the scope concrete, you must supply access to your directory (for example, read access to the Active Directory or LDAP source that the identity layer will federate), a Kubernetes platform that meets the version and tooling requirements of the chosen suite, and named decision owners for identity mapping, data retention, edition choice and go-live approval. Missing any of these three will extend the work more than any technical issue.

Finally, buyers ask whether their own teams can do the work without outside help. Many can operate a Kubernetes platform and run Helm-based deployments, but the combination of identity federation, upgrade planning, migration and security evidence is where internal capacity is usually stretched. Check three things before deciding: whether you have people who can own the platform after go-live for the full support period of each component, whether you can rehearse upgrades on a non-production copy, and whether you can produce the audit evidence your assessors will request. If the answer is no to any of these, a fixed-scope engagement that covers build, handover and documentation is one option, and an ongoing support retainer is another. Put the handover deliverables and the support boundaries in the written scope so that they can be checked later.

How DeployOpen works on this

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a workplace suite RFP, we start with a written scope that answers the questions in this page, then build and test the environment against it before handover.

How we scope

We confirm which components are in scope, such as files, office, mail, chat, video, wiki and projects, before any work starts.
We review your Kubernetes platform, ingress, certificate handling and external services against the openDesk requirements you need to meet.
Engagements are fixed-scope, so deliverables, timelines and responsibilities are agreed in writing before work begins.

How we build

We deploy the chosen suite into your infrastructure, including identity federation with your existing directory or identity provider.
We configure migration of mail and files in stages, with test runs and reconciliation checks agreed in the scope.
We run security testing against applications, APIs and infrastructure, and document the hardening decisions made along the way.

How we hand over

You receive architecture, configuration and runbook documentation covering each component and its upgrade path.
We prepare the systems, controls and evidence your compliance assessors will ask for, without issuing audit reports or certifications ourselves.
We walk your operations team through backup, restore and upgrade procedures so the environment can be run without us.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped to the components you run.
Upgrade rehearsals in a non-production environment can be included in the retainer to match your release cadence.
Retainer scope, response expectations and service levels are confirmed in writing, so you know what is covered before you sign.

Digital workplace suite RFP questions