openDesk vs La Suite numérique: which fits your public body
If you run a German or French public body, the choice is between openDesk, a bundled Kubernetes suite from ZenDiS, and La Suite numérique, the workspace DINUM operates for French state employees from modular open-source services. openDesk fits a German public administration or a non-government organization that wants one integrated suite it installs and operates in its own infrastructure. La Suite fits a French state body that can use the hosted services it offers, or an organization that only needs selected components such as Docs or Meet. Eligibility decides more of this than features do: La Suite's website restricts access to state civil servants and invited partners through ProConnect, so an organization outside that group cannot simply adopt it as a workspace.
openDesk is the heavier commitment. Its deployment is Helmfile and Helm based and requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager and an RWO volume provisioner. The evaluation minimum is 12 x64 CPU cores and 32 GB of RAM, and production expects external PostgreSQL, Redis, object storage, an SMTP relay and a TURN server. Confirm with your platform team that it can operate this footprint and that your clusters are not OpenShift, since openDesk is not tested there. ZenDiS recommends Enterprise Edition for production, so ask what the support and patch commitments cost and whether your identity model fits the Nubus portal and IAM layer that openDesk ships with.
Which scenario points to openDesk and which to La Suite
This table maps common buyer situations to the platform that usually fits better, based on scope, eligibility, operating model and support. Read each row as a starting question, then confirm access terms and support scope with the relevant publisher before you commit.
| Buyer scenario | Better fit | Why |
|---|---|---|
| German federal or state authority wanting a complete office and groupware suite | openDesk | openDesk bundles files, groupware, chat, wiki, project management, video and web office into one deployment. Confirm with ZenDiS whether your authority is eligible to adopt it and which edition applies. |
| French state employee who needs chat, video, documents and email from one government service | La Suite numérique | La Suite is operated by DINUM for French state civil servants and invited partners, accessed through ProConnect. Confirm your eligibility before planning around its services. |
| French public body without ProConnect access | openDesk or a self-hosted build | La Suite access is restricted to state civil servants and invited partners, so the service may not be available to you. Confirm eligibility with DINUM, then evaluate the open components on your own infrastructure if needed. |
| Organization outside government that needs collaborative documents or video only | La Suite Docs or Meet (self-hosted) | Docs is MIT licensed and Meet is MIT licensed, and both support Kubernetes and Docker Compose. A narrow scope avoids deploying the full openDesk stack, but you must confirm licensing of any bundled components you adopt. |
| Organization that needs a complete suite with its own IdP, mail and chat, outside government | Confirm with both vendors | openDesk's availability terms must be confirmed with ZenDiS, and La Suite's services are scoped to government users. Ask each for written statements on eligibility, hosting and support before comparing features. |
| Team with an existing CNCF-certified Kubernetes platform at v1.33 or later | openDesk is a practical candidate | openDesk is Helmfile and Helm based and requires a Kubernetes cluster with an ingress controller, cert-manager and an RWO volume provisioner. Confirm your cluster meets these prerequisites, since openDesk is tested on kubespray clusters and not OpenShift. |
| Team without an existing Kubernetes platform | Evaluate effort before choosing | openDesk expects Kubernetes plus production-grade external services such as PostgreSQL, Redis, an SMTP relay and object storage. Scope the platform build before selecting, because the Kubernetes layer is a major one-time and recurring cost. |
| Team that must confirm production support terms | openDesk Enterprise Edition, if available | ZenDiS recommends Enterprise Edition for production and offers SLA-backed support. Ask ZenDiS for written support scope, and ask DINUM what support applies to La Suite services you would use. |
| Team that needs health data or Diffusion Restreinte content handled in a managed French service | Confirm with DINUM | La Suite's Docs and Visio are not suited to Diffusion Restreinte content or health data. Verify any classification requirement with your security owner before choosing a platform. |
How openDesk and La Suite are built and what that means for operations
openDesk is one Kubernetes-based bundle that a platform team deploys as a whole, while La Suite is a set of services that can be adopted and run separately. Both models change who needs which skills, how often upgrades land and how many components someone must watch.
Helmfile and Helm deployment
openDesk is deployed with Helmfile and Helm automation under Apache-2.0, so the whole suite is installed and upgraded as one release set. Your team needs working knowledge of Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later, plus the change management to review each bundled component's chart changes. Ask ZenDiS or your integrator how chart upgrades are tested before they reach your cluster.
Cluster prerequisites and tested platforms
openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager and an RWO volume provisioner. The project tests on kubespray clusters and does not test on OpenShift, so an OpenShift shop should confirm support in writing before committing. Plan the cluster build as a separate workstream.
External production services
For production, openDesk expects you to supply PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each is a service you back up, patch and size yourself. Confirm which of these your organization already runs and which you must procure before estimating the platform team's load.
Modular La Suite services
La Suite is built from separate services, including Docs, Meet, Tchap, Fichiers and professional email. Docs and Meet both support Kubernetes and Docker Compose, so a team can adopt one service at a time instead of the full bundle. The trade-off is that each service needs its own owner, upgrade schedule and monitoring, and you must confirm how they integrate with your identity provider.
Meet on LiveKit and Tchap on Matrix
La Suite Meet is powered by LiveKit, and Tchap runs on Matrix, so video and messaging each depend on a different protocol stack with its own scaling and federation behavior. Your operators need skills in both media servers and Matrix homeserver administration. Ask DINUM or your integrator which Tchap and Meet components are in the packaged deployment and which must be run separately.
Upgrade cadence and monitoring load
openDesk plans annual major releases in Q3, monthly minor releases and on-demand patches, and supports only the latest minor version. La Suite components ship on their own repositories and cadences, such as Docs v6.0.1 on October 15, 2026. Your team must track one bundle cadence with openDesk, or several independent cadences with La Suite, and decide which is easier to keep current.
Side-by-side capabilities: file, office, chat, video and wiki
This table sets openDesk's bundled suite against La Suite numérique across license, deployment, file, office, video, chat, document, identity and hardware needs. Read each row as what the published material documents, and confirm the gaps with ZenDiS or DINUM before you plan around them. The main takeaway is that openDesk arrives as one Kubernetes-deployed bundle, while La Suite is a set of open components whose hosting and access terms differ by service.
| Capability | openDesk | La Suite numérique |
|---|---|---|
| License | Deployment code is Apache-2.0; bundled components keep their own licenses, such as AGPL-3.0 and MPL-2.0 | Docs and Meet are MIT licensed; confirm the licenses of other components with DINUM |
| Deployment model | Helmfile and Helm on a CNCF-certified Kubernetes cluster, v1.33 or later | Docs and Meet support Kubernetes and Docker Compose; confirm the supported paths for the full suite |
| File storage | Nextcloud for files; Enterprise Edition adds Nextcloud Enterprise security patches and the Guard app | Fichiers for file storage; confirm its license, hosting and self-hosting path with DINUM |
| Office editing | Collabora as the web office under MPL-2.0; Enterprise Edition adds automatic load scaling | Docs handles collaborative documents; confirm whether spreadsheet or slide editing is in scope |
| Video meetings | Jitsi Meet, Apache-2.0 licensed, deployed as part of the bundle | Meet, MIT licensed and powered by LiveKit; recording and transcription are in beta |
| Chat | Element with Nordeck widgets; AdminBot and GroupSync are Enterprise Edition features | Tchap messaging built on Matrix, with access limited to state staff and invited partners |
| Collaborative documents and wiki | CryptPad with diagrams.net and XWiki for wiki work; OpenProject for project management | Docs is built on Yjs; PDF export uses GPL BlockNote XL unless PUBLISH_AS_MIT=true is set |
| Identity integration | Nubus provides the portal and identity and access management; external IdP federation is documented | ProConnect controls access for the hosted service; confirm self-hosted identity options with DINUM |
| Minimum evaluation hardware | 12 x64 CPU cores, 32 GB RAM and more than 10 GB disk; production needs external services | No minimum supplied; ask DINUM for Docs and Meet sizing and required backing services |
What openDesk Enterprise Edition and La Suite's open components cost to license
The openDesk deployment automation is Helmfile and Helm based and is licensed under Apache-2.0. That license covers the deployment code that assembles the suite, and it does not change the license of each product that the deployment installs. Your organization can read, modify and run the automation without a license fee for that layer, but the work of operating it is a separate cost that you carry or contract out.
- Apache-2.0 for the deployment code: The Helmfile and Helm configuration is open source, so you can audit it and adapt it to your environment.
- Bundled components keep their own licenses: Nextcloud and Nubus are AGPL-3.0, OpenProject is GPL-3.0 and Collabora is MPL-2.0. Each carries its own obligations when you modify or distribute it.
- Infrastructure is still yours to pay for: The deployment expects a Kubernetes cluster, external production-grade services and an SMTP relay, so hosting and third-party services are costs outside the license.
- Community deployment has no vendor support contract: Support for the open-source path depends on your internal team or a services provider.
Check which component licenses your legal team must review before you distribute or modify any bundled product, and confirm the license of each release you plan to run.
ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses as the community deployment, but it adds closed-source modules, an Enterprise-only registry and a license file. ZenDiS also sells SLA-backed second and third level support and patches, delivered either as SaaS or for on-premises installation. The license and support are the main recurring cost, and the supplied facts do not give a price, so request one in writing.
- Closed-source modules: Enterprise adds proprietary components on top of the open-source core, so the code you run is not fully open source.
- Enterprise-only registry and license file: Images and modules are drawn from a registry that requires the license file, so you cannot pull them with the open-source setup alone.
- SLA-backed support and patches: Second and third level support and security patches come with service levels, which matter most when you must meet an internal patch deadline.
- Delivery choice: You can buy it as SaaS or install it on premises, which changes who operates the platform and where the data sits.
- Enterprise-only features: Collabora branding and automatic load scaling, 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 ZenDiS or its distributor for the license term, renewal conditions, support hours and SLA definitions, and which Enterprise-only features are included in the quote.
La Suite's collaborative editor Docs and its video app Meet are both MIT licensed, which allows you to use, modify and redistribute them without a license fee. Docs is a joint initiative of DINUM and ZenDiS, and the supplied facts describe no paid edition for either component. That does not mean a deployment you receive is free to run, because the operating body may attach its own support terms, hosting conditions or service agreements.
- Docs under MIT: The editor is MIT licensed, and its README notes that PDF export relies on GPL-licensed BlockNote XL packages that can be excluded with PUBLISH_AS_MIT=true.
- Meet under MIT: The video app is MIT licensed and runs on LiveKit, so confirm the license of LiveKit and any other dependency you add.
- No paid edition in the supplied facts: No Enterprise tier, license file or SLA-backed support is described for Docs or Meet.
- Access terms apply to the service: La Suite access is restricted to state civil servants and invited partners through ProConnect, so availability is a condition separate from the license.
- Support is not the same as the license: Support for a deployment you receive depends on the operating body, not on the MIT grant.
Ask DINUM or the operating body which support terms, service levels and hosting conditions apply to any deployment you receive, and whether they cover your organization.
Licensing is one part of the total cost, and the recurring items usually outweigh the one-time items over the life of the platform. For openDesk, the Enterprise subscription is paid to ZenDiS, while the infrastructure, external services and internal staff are paid to your own vendors and team. For La Suite, the license cost is zero under MIT, but hosting, operations and support arrangements carry costs that you must identify before you compare the two.
- One-time costs: Planning, integration, identity setup and data migration are generally one-time, and they are priced by scope.
- Recurring costs: Enterprise subscriptions, SLA-backed support, hosting, storage, SMTP relays and staff time recur each year.
- What drives cost up: Number of users, number of environments, required SLAs, and the number of modules you enable all raise the figure.
- What to ask for in an openDesk quote: Enterprise license scope, support tier, SLA terms, delivery model and renewal rules.
- What to ask for in a La Suite quote: Operating body terms, support hours, data location, and who is accountable for patches.
Request written terms from each vendor or operating body and compare them against the same user count and environment, since DeployOpen will scope its own work separately in writing.
What drives the running cost of each platform
The running cost of openDesk is mostly a platform cost, and it starts before any user logs in. openDesk is deployed with Helmfile and Helm onto a CNCF-certified Kubernetes cluster at v1.33 or later, with an ingress controller, cert-manager and an RWO volume provisioner. The evaluation minimum is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet. That figure is for evaluation only. For production, the openDesk requirements expect external services such as PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Each of these is a recurring capacity line, and each may be run, licensed or bought separately by the client. Confirm production sizing for your user count with the vendor or ZenDiS before you budget, and ask who pays for each external service.
Staff and support are the other large components, and they recur. Someone must hold Kubernetes, Helm and identity skills, because Nubus provides portal and identity management across the bundle. openDesk releases major versions annually in Q3, minor versions monthly and patches on demand. Only the latest minor version is supported, in-place upgrades between majors are not guaranteed, and skipping several minor versions may need intermediate steps. Each monthly minor upgrade therefore consumes staff time in a test environment, and a lagging cluster may force a longer, staged catch-up. Enterprise Edition, which ZenDiS recommends for production, adds SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Its price is a recurring line that depends on the deployment model you choose.
La Suite numérique has a different cost shape. Its building blocks, including Docs and Meet, are MIT-licensed and can be run on Kubernetes or Docker Compose, so the license line is zero and the cost sits in hosting and in staff who operate each service. Docs is MIT-licensed with a PDF export path that depends on GPL-licensed BlockNote XL packages, which can be excluded with PUBLISH_AS_MIT=true. Meet is LiveKit-based, so you carry its media capacity. Before you compare totals, ask each side for the same written list: who operates the cluster, who applies security patches to each component and on what schedule, who owns the upgrade test cycle, what the support contract covers, and what hosting capacity is included. A quote that leaves any of these open is not comparable.
Moving users between openDesk and La Suite without losing documents
This sequence moves users and their documents between openDesk and La Suite in an order that protects access, file formats and chat and video history, and ends with a parallel run that proves the move before the old service is retired.
Confirm eligibility and identity mapping first
Before any data moves, confirm who is allowed to use the target platform. La Suite access is restricted to state civil servants and invited partners through ProConnect, so a non-government body moving toward La Suite should check with DINUM whether its users qualify. openDesk identity runs through Nubus, and its federation with an external identity provider is documented separately, so the team should map each user's account, email address and group membership between the two environments. The step is complete when a written user list exists for each side, with every account matched to exactly one target identity and every ineligible account flagged for a decision.
Inventory services and decide transfer or rebuild
List every service the users rely on and classify each one as transferred, rebuilt or retired. Documents in Docs can be moved as files. Chat, video and permissions usually need a different route, because a chat history or a meeting recording is not the same kind of object as a document. openDesk bundles Element, Nextcloud, OX App Suite, XWiki, OpenProject, Jitsi and Collabora, while La Suite lists Tchap, Visio, professional email, Fichiers, Docs and Grist, so some services will have no direct counterpart. The output is a signed-off table with one row per service and one decision per row.
Confirm each component's export path with the vendor
For every component in the inventory, ask the vendor or project how data leaves the system. Ask for the supported export format, the API or bulk tool used, whether metadata such as author, timestamps and sharing survives, and how attachments and embedded images are handled. Do not assume the export path from the other platform's documentation. The step is complete when each row in the inventory has a named export method and a written answer from the source vendor or project that the team has reviewed.
Plan the document conversion and format checks
Docs imports .docx and .md and exports .docx, .odt and .pdf, according to its README. Documents in other formats, such as older office files or wiki pages, must be converted first. Test a representative sample of files in each direction, including tables, comments, images and links, and record which elements survive. Note that PDF export relies on GPL-licensed BlockNote XL packages that can be excluded with PUBLISH_AS_MIT=true, so the team should confirm the export settings it will run. The check is complete when the sample results are written down and accepted by the document owners.
Agree a version path for each platform
Plan the target version before the migration starts. openDesk states that only the latest minor version is supported, that in-place upgrades between majors are not guaranteed, and that skipping several minor versions may need intermediate steps. Ask ZenDiS or your integrator to confirm the upgrade route from your current release to the target release, and record any intermediate versions required. The output is a dated version plan that the change board has approved.
Migrate documents and rebuild chat and video
Move documents in batches, starting with a small pilot group, and keep the source copy unchanged until the target is verified. Chat and video history are usually handled separately: confirm with each vendor whether message history can be exported, and whether it should be archived rather than imported. Rebuild permissions by group rather than file by file, then compare sharing settings in both systems against the inventory. The step is complete when the pilot group can open, edit and share migrated documents and the permission report matches the approved list.
Communicate and run both systems in parallel
Tell users what changes, when they switch, where their old files stay, and who to contact for missing content. Run both platforms in parallel for a period the project team sets and agrees with the business owners, and reconcile document counts, sharing and access logs between them each cycle. Retire the old service only after the owners sign off on the reconciliation report and the archive of the source data is confirmed. The sequence is complete when the parallel run closes with an agreed exit report.
Where implementation projects for each platform usually run long
openDesk projects usually run long at the platform layer, before any bundled application is configured. The deployment is Helmfile and Helm based and needs a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. The requirements documentation says it is tested on kubespray clusters and not on OpenShift, so an organization standardized on OpenShift should confirm the gap early. Production also expects external services the team must supply and operate: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Identity federation with the organization's existing identity provider is the next common delay, because Nubus handles portal and identity management and the federation guide must be walked through against the real directory. Mail and storage integration for bundled components such as Nextcloud and OX App Suite is the last large item. Confirm each dependency in writing with the platform team before the schedule is fixed.
La Suite projects usually run long on eligibility and data classification, not on installation. The suite is operated by DINUM for French state employees and invited partners, and access runs through ProConnect. A body that is not a state ministry must establish whether it qualifies for access at all, and that question sits outside any technical work. If access is granted, the hosting question follows: La Suite states that Docs and Visio run on SecNumCloud-certified hosting in France and are not suited to Diffusion Restreinte content or health data. An organization that wants to self-host Docs or Meet instead takes on the hosting, identity and classification decisions itself. Docs is MIT licensed and supports Kubernetes and Docker Compose, and Meet is MIT licensed on LiveKit with recording and transcription in beta, so the self-hosted route is open, but the data classification review must come first. Ask the vendor or DINUM to confirm the current access conditions and hosting options before committing a timeline.
Both projects slip most often when scope is agreed before the data classification and identity decisions are made. DeployOpen plans, implements and hardens these platforms inside the client's own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. A useful written scope for either platform names the Kubernetes or hosting target, the external services, the identity provider and federation method, the mail and storage integrations, and the data classes each component will hold. DeployOpen does not publish a price list, so the quote follows from that scope. Ask for the dependencies to be listed as assumptions with an owner each, so that a missing external service or an unresolved access question appears as a scope item rather than a surprise during go-live.
Questions buyers ask before choosing between openDesk and La Suite
Can a non-government organization use La Suite numérique?
Not as a general-access workspace. La Suite is operated by DINUM for French state employees, and access is restricted to state civil servants and invited partners through ProConnect. A private company or a non-state body would need to confirm with DINUM whether any access route exists for it. If the goal is to run the open-source building blocks yourself, the relevant question is licensing and hosting, not access to the government service. Docs is MIT licensed, and Meet is MIT licensed, so both can be self-hosted, but the operator takes on hosting, identity and support responsibilities.
What does the openDesk Enterprise Edition change for production?
ZenDiS recommends the Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. It is sold as SaaS or for on-premises installation. Enterprise-only features include Collabora branding and automatic load scaling, Element AdminBot, GroupSync and Admin Console, Nextcloud Enterprise security patches and the Guard app, and OX S3 storage with advanced full-text search. Cost is a recurring subscription on top of your infrastructure, so ask ZenDiS for the current price and SLA terms in writing.
How much effort does the Kubernetes platform need to run?
Expect a platform team, not a single administrator. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller, cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4, and Helmfile 1.0.0 or later. It is tested on kubespray clusters and not on OpenShift. For production, you also run external services such as PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. Effort recurs through monthly minor releases, and since only the latest minor version is supported, each upgrade must be planned and tested.
Can our own team deploy openDesk without outside help?
Possibly, if you already run production Kubernetes and have people who can operate PostgreSQL, object storage, identity federation and mail relay at the same level. The minimum evaluation footprint is 12 x64 CPU cores, 32 GB of RAM and more than 10 GB of disk, and ARM is not supported yet. The harder part is the surrounding services and the upgrade cadence, not the first install. Ask ZenDiS which support tier covers your team, and if you need outside hands, request a written DeployOpen scope that lists the specific tasks and deliverables.
How long does a typical openDesk deployment take?
No duration is established in the facts available here, so treat any figure you hear with caution. The timeline depends on cluster readiness, the external services you must provide, identity integration, the number of bundled components you enable, and how much customization your ministry or organization requires. Ask for a phased plan with milestones for the cluster, the production services, the identity federation and the user onboarding. DeployOpen plans and delivers most engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts.
What does the work need from our side?
Plan for named owners in infrastructure, identity, security and the business units that will use the suite. You need a Kubernetes environment that meets the stated version and tooling requirements, production-grade data services, an SMTP relay, object storage, a TURN server and a decision on how users authenticate. Your side also owns change approval, backup policy, access reviews and the evidence trail for any compliance assessment. Ask any implementation partner to list these dependencies in the written scope so responsibilities are clear before cost is fixed.
Can we self-host Docs or Meet on their own?
Yes, both are self-hostable as standalone components. Docs is MIT licensed, supports Kubernetes and Docker Compose, and imports and exports common document formats. Its README notes that PDF export relies on GPL-licensed BlockNote XL packages that can be excluded with PUBLISH_AS_MIT=true. Meet is an MIT-licensed video app powered by LiveKit, also deployable on Kubernetes or Docker Compose, with recording and transcription still in beta. Confirm with DINUM or ZenDiS which versions they maintain, and confirm your own identity, storage and support arrangements before you commit.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For openDesk vs La Suite numérique, we start from your hosting constraints, identity setup and content rules, then build the deployment you choose.
How we scope
- Confirm which workloads, users and content classes the platform must serve before any design begins.
- Map Kubernetes, database, object storage, SMTP and TURN requirements against your existing infrastructure.
- Agree scope, deliverables and timelines in writing, since most engagements are fixed-scope.
How we build
- Deploy the chosen suite inside your environment, configuring identity federation and external services as scoped.
- Test integrations between files, documents, chat and video against the agreed acceptance criteria.
- Harden the configuration and document licensing of each bundled component for your compliance team.
How we hand over
- Deliver runbooks, architecture documentation and configuration records written for your operations team.
- Walk administrators through upgrade, backup and restore procedures used in your environment.
- Document open items, such as features you must confirm with the vendor, so ownership is clear at handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover planned upgrades when the vendor's release policy requires intermediate steps.
- Ask for the retainer scope and response expectations in writing alongside the original quote.
