Eppo vs GrowthBook: when each one fits
Start with the renewal or the change that prompted the review, because that determines how much time you have. If Eppo is part of your stack and its terms or ownership now raise questions, the right comparison is not feature against feature but operating model against operating model. Eppo fits best when you want a managed platform, your team has no appetite for running experimentation infrastructure, and your analytics already sit in the Datadog ecosystem. Eppo is now sold as Eppo by Datadog, so teams that already use Datadog Product Analytics may find the integration path straightforward. Confirm with Datadog what support, roadmap and contract terms apply to the Eppo product you are buying today.
Self-hosted GrowthBook fits when you need control over where the platform runs and who can reach it. GrowthBook's core is MIT licensed outside its enterprise directories, and its self-hosting model bundles the Next.js front end, Express API and Python statistics engine into one Docker image with metadata in MongoDB or a compatible database. It runs read-only SELECT queries against your own warehouse, so data residency is largely a question of where your warehouse and GrowthBook host sit. The trade-off is that your team takes on hosting, upgrades, backups and the MongoDB operations that the self-hosting documentation recommends placing on a managed service for production. Note that the free self-hosted Open Source plan allows one project, and governance features such as SSO and SCIM, approval workflows, holdouts and sticky bucketing sit in self-hosted Enterprise.
The decision turns on three questions. First, where may experiment data run: does your data policy allow a SaaS control plane to receive aggregated results, or must the whole loop stay in your network? Second, which statistics and governance features does the team need, and are they in the free tier or in Enterprise? Third, who will operate the stack after go-live, including on-call for MongoDB, GrowthBook upgrades and warehouse credentials? If the answer to the third question is no one, a managed Eppo subscription or a DeployOpen-run implementation with a retainer is the more honest option. Write those answers down before requesting quotes.
Which scenarios favor Eppo and which favor GrowthBook
This table maps common buyer situations to the option that usually fits better and the condition that drives the choice. Read each row as a starting point, and confirm the Eppo-side details with Datadog because this comparison relies on documented GrowthBook facts and the general Eppo model. The main takeaway: GrowthBook fits best where self-hosting, a free core or residency control matter, while Eppo fits teams that want a vendor-run service within the Datadog ecosystem.
| Scenario | Better fit | Why it matters |
|---|---|---|
| Already standardized on Datadog | Eppo | Eppo is now sold by Datadog, so one vendor relationship may simplify procurement. Confirm which Datadog integrations are included. |
| Strict residency or self-hosting mandate | GrowthBook (self-hosted) | GrowthBook runs read-only SELECT queries in your warehouse and sends only aggregated statistics. Ask Eppo exactly where its application processes data. |
| Small team with a limited budget | GrowthBook (self-hosted Open Source) | The free self-hosted plan allows 1 project with unlimited users. Plan for a paid tier if you need more projects. |
| Need for SSO, SCIM, approvals or holdouts | GrowthBook (self-hosted Enterprise) | These controls sit in the self-hosted Enterprise plan, not the free tier. Confirm whether Eppo includes equivalent controls in your contract. |
| In-house platform team that runs containers and databases | GrowthBook (self-hosted) | GrowthBook ships as one Docker image with an official Helm chart and uses MongoDB or a compatible database. Your team owns upgrades, backups and availability. |
| No capacity to operate additional infrastructure | Eppo | A vendor-run service removes hosting and database operations from your team. Confirm support tiers, uptime commitments and escalation paths in writing. |
| Legal review of the core license matters | GrowthBook (self-hosted) | Code outside the enterprise directories is MIT licensed, and those directories fall under the GrowthBook Enterprise License. Have counsel review the terms that apply to your deployment. |
How each tool reads your assignment and event tables
GrowthBook analyzes experiments against your own data source. It supports BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica. It runs only SELECT queries, and only aggregated statistics leave the warehouse, so raw assignment and event rows stay where they are. Confirm current connector details in the GrowthBook data source documentation before you commit to a design.
- Table schemas: Your team defines the experiment assignment table and the fact tables behind each metric, and maps columns such as user ID, timestamp, experiment key and event value. GrowthBook queries these definitions, so schema changes upstream can break metrics silently.
- Permissions: Create a dedicated read-only role for GrowthBook scoped to the datasets it needs. Review it whenever new sources are added.
- Query costs: Each analysis and refresh runs SQL in your warehouse, so compute is billed to your warehouse account. Partitioning and scheduling choices directly change that bill.
- Self-hosted metadata: GrowthBook stores experiment and flag metadata in MongoDB or a compatible database, which you operate in addition to the warehouse work.
- Ownership: Your data team owns the SQL definitions and the warehouse role, not the vendor.
Before a pilot, check that your warehouse appears in the supported list and that your assignment logging meets the table format GrowthBook expects.
Eppo describes itself as warehouse-native, which means it is designed to read the assignment logs and fact tables that already live in your warehouse rather than copying event data into a separate store. The specifics of which warehouses it supports, how it authenticates, what permissions it requests and how it runs queries are vendor details that can change, so confirm them directly with Eppo or Datadog before making decisions.
- Supported warehouses: Ask Eppo for the current list and whether your warehouse version is covered.
- Access pattern: Ask whether Eppo runs queries on your warehouse, whether it uses a service account or a role, and what permissions that account holds.
- Table schemas: Confirm which assignment and event table formats Eppo expects and whether it generates intermediate tables that you must keep.
- Query costs: Ask how Eppo schedules and batches warehouse queries, and whether compute is billed to your warehouse account in addition to the Eppo subscription.
- Datadog integration: Confirm how the Datadog ownership affects data access, support and any product analytics links.
Get these answers in writing and compare them with the GrowthBook design above, so your team can see which obligations move and which stay the same.
Whichever tool you choose, warehouse-native experimentation shifts several jobs onto your own team. These responsibilities exist before any tool is licensed and continue after go-live. They are the parts of the work that a quote from any vendor or implementer should cover explicitly.
- Assignment logging: Someone must own the exposure logging that writes which user saw which variant, and verify it at the source.
- Schema contracts: Agree on column names, types and event definitions, and version them so a change does not invalidate running experiments.
- Access reviews: Keep the warehouse role least-privilege and rotate its credentials under your standard process.
- Cost monitoring: Track warehouse spend driven by experiment queries and set limits or schedules where the tool allows.
- Metric definitions: Record each metric's SQL and business meaning so results can be reproduced during audits or reviews.
Ask any implementation partner to document these owners and cadences in the written scope, since they determine how much of the operating effort stays with your team.
Capability comparison: Eppo and GrowthBook
This table compares what Eppo documents for its Datadog-owned SaaS with what GrowthBook offers when self-hosted, one capability at a time. Where the supplied sources do not confirm an Eppo capability, the cell names what to confirm with the vendor. GrowthBook features marked Enterprise require the self-hosted Enterprise plan, while the free self-hosted Open Source plan covers the core setup.
| Capability | Eppo (sold by Datadog) | GrowthBook (self-hosted) |
|---|---|---|
| Hosting model | Datadog-owned SaaS. Confirm whether any self-hosted or customer-cloud deployment exists. | Self-hosted in your own infrastructure as one Docker image, with a Helm chart for Kubernetes and MongoDB or a compatible database. |
| Warehouse support | Warehouse-native. Confirm the full list of supported warehouses with Eppo. | BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino, and Vertica. |
| How the tool reads warehouse data | Reads your assignment logs and fact tables. Confirm the required schema and query permissions. | Runs only SELECT queries and transmits only aggregated statistics back from your warehouse. |
| Local SDK evaluation | Confirm which SDKs evaluate flags locally and which call a service at runtime. | Confirm local evaluation per SDK in GrowthBook's SDK documentation before choosing a design. |
| Multi-armed bandits and holdouts | Confirm availability and plan tier with Eppo. | Enterprise only on self-hosted Enterprise. The free self-hosted plan does not include them. |
| Safe rollouts and ramp schedules | Confirm availability and plan tier with Eppo. | Enterprise only on self-hosted Enterprise, as listed on GrowthBook's pricing page. |
| SSO, SCIM and advanced permissioning | Confirm SSO, SCIM and role model support with Eppo. | SSO and SCIM plus advanced permissioning are Enterprise only on self-hosted Enterprise. |
| Approval workflows | Confirm whether changes can require approval and how audit history is kept. | Enterprise only on self-hosted Enterprise. Open Source has no approval workflow. |
| License and source access | Proprietary SaaS. Confirm contract terms, data processing terms and exit provisions. | MIT Expat outside the enterprise directories. Code in those directories falls under the GrowthBook Enterprise License. |
Which GrowthBook features need the Enterprise plan
The self-hosted Open Source plan is free with unlimited users, one project and unlimited API requests, according to the GrowthBook pricing page. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Eppo users should map their current program against this list before assuming the free tier covers them. Teams that run a single product area with a small group of engineers and analysts often need only the core experiment analysis, which the Open Source plan already provides. Teams with several products, regulated approval requirements or an identity provider they must enforce will hit the limits quickly.
Start with the controls your organization actually requires. If your security team mandates SSO with automated user deprovisioning through SCIM, that is an Enterprise requirement. If experiment launches must be signed off by someone outside the experimenting team, check whether approval workflows and advanced permissioning are needed to enforce that split. Sticky bucketing and holdouts matter when you rely on consistent user assignment across sessions or on measuring long-term cumulative effects. Safe rollouts and ramp schedules matter when you ship flags to production gradually and want automatic guardrails. Multi-armed bandits matter only if you intend to shift traffic toward winning variants during a test, which changes how you interpret results.
Enterprise pricing is custom, and GrowthBook does not publish a figure for self-hosted Enterprise on its pricing page. Ask GrowthBook for a written quote that lists each Enterprise feature you need, the license term, the support scope and any changes to the license after the first year. Confirm in writing which Enterprise directories and features apply to your self-hosted version, since the GrowthBook LICENSE file separates enterprise code under its own license from the MIT-licensed core. Compare that quote with the cost of building the missing controls yourself, and record which requirements, if any, you have decided to accept as gaps.
Where experiment data and metadata live
Self-hosted GrowthBook splits the system in two: experiment data stays in your warehouse, while flag definitions, users and experiment settings sit in GrowthBook's own database. Each part needs a different owner, backup plan and access control, and Eppo's side of the picture needs written confirmation before any decision.
Warehouse data stays put
GrowthBook analyzes experiments against your own data source, including Snowflake, BigQuery, Redshift, Databricks and Postgres, running only SELECT queries and sending back aggregated statistics. Your existing assignment logs and event tables remain where they are. Confirm that the database role GrowthBook uses is read-only and scoped to the schemas holding experiment data.
Metadata sits in MongoDB
Flags, targeting rules, metric definitions, experiment write-ups and user accounts are stored in MongoDB or a compatible database. The GrowthBook docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. Decide who owns that database, where it runs, and whether its backups hold any data you consider sensitive.
Single image and Helm chart
The Next.js front end, Express API and Python statistics engine ship in one Docker image, and GrowthBook maintains an official Helm chart for Kubernetes. Running both in your own cluster keeps the application in your control, but your platform team takes on upgrades, patching and scaling. Ask who will track each GrowthBook release, such as v5.1.0 released on September 22, 2026.
File uploads and storage choice
Uploaded files can be kept on local disk, in Amazon S3 or in Google Cloud Storage. Local storage adds one more volume to back up and restore, while object storage needs its own bucket policy, encryption and retention settings. Choose the target before go-live so that uploads do not end up on a container's ephemeral disk.
Identity and audit controls
Self-hosted Enterprise adds SSO and SCIM, advanced permissioning and approval workflows, which the free self-hosted Open Source plan does not include. Map each reviewer and experiment owner to a role, and confirm how audit records of flag changes are retained. Your compliance team will expect evidence of who changed a flag and when.
Confirm Eppo data handling in writing
Ask Eppo, now sold by Datadog, where your assignment and results data is processed, which regions host it, who can access it, how long it is retained and whether it is used for Datadog product features. Get the answers in the contract or a data processing addendum rather than relying on marketing pages. Compare them against the warehouse and GrowthBook setup to find any gaps.
What the GrowthBook MIT license covers and what it does not
The GrowthBook license split is the first thing to confirm before you plan a self-hosted deployment. GrowthBook's LICENSE file states that code outside three enterprise directories, packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise, is MIT Expat licensed. Those three directories fall under the GrowthBook Enterprise License. In practice, the self-hosted core, including the experiment analysis, feature flag evaluation and data source connectors outside those paths, can be run, copied and modified under MIT terms. The current release line is v5.1.0, released September 22, 2026, so check the GrowthBook releases page for the version you intend to deploy and compare its LICENSE file against the one you reviewed.
The split also means the license does not cover everything a team might assume. Features gated to the self-hosted Enterprise plan, such as SSO and SCIM, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts, live in the enterprise paths and carry their own terms. Before you rely on any of them, confirm with GrowthBook in writing which plan and license apply to your deployment, and have your legal counsel read the LICENSE file alongside the Enterprise License text. Also confirm whether any code you plan to fork or patch touches an enterprise path, because modifying it may trigger different obligations than the MIT core.
Compare this with Eppo's subscription terms, which are a contract rather than an open-source license. Request in writing the terms that govern use of the hosted service, data ownership and export, any restrictions on running analysis outside Eppo, and what happens to your configuration and results at renewal or termination. Because Eppo is now sold as Eppo by Datadog, ask whether those terms have changed since the acquisition and who the contracting entity is. Your decision should rest on the two signed or published documents, not on the general reputation of either license.
What drives the cost of each option
Eppo and self-hosted GrowthBook split costs differently. One side is a vendor subscription, the other is a free core plus hosting, warehouse usage and your own operating effort. The cards below show who gets paid for what, which costs recur, and what to request before you compare totals.
Eppo subscription
Eppo is sold by Datadog on quoted terms, and its prices are not published, so this is a recurring line you can only fix through a written quote. Ask for the unit the quote is based on, whether it scales with seats, experiments, metrics or events, the term length, and what happens at renewal. Also ask which integrations, such as warehouse connectors and Datadog Product Analytics, are included or billed separately. Treat the subscription as recurring for the life of the contract.
GrowthBook free core versus Enterprise
The self-hosted Open Source plan is free with unlimited users and one project. Features such as SSO and SCIM, approval workflows, sticky bucketing, holdouts and safe rollouts require the self-hosted Enterprise plan, which is quoted on request. Enterprise is the main recurring license cost if you need those features. Before comparing, list which controls your governance requires and confirm each one against the current plan table, since the project limit alone can change the answer.
Warehouse compute both tools spend
Both tools run queries against your warehouse, so compute appears on your cloud bill whichever you choose. GrowthBook issues read-only SELECT queries and receives only aggregated statistics, so the cost is driven by how often analyses run, how many metrics and dimensions you define, and how large the fact tables are. Ask your data team to estimate query volume per experiment and to confirm how Eppo's queries differ in frequency. Warehouse spend is recurring and is largely independent of the tool choice.
Hosting GrowthBook and MongoDB
Self-hosting moves the application cost onto your infrastructure. GrowthBook ships its front end, API and statistics engine in one Docker image, with a Helm chart for Kubernetes, and stores metadata in MongoDB or a compatible database. The docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. Compute, storage, backups, a managed database subscription and staff time are recurring. Ask your platform team to price the managed database tier and the cluster sizing in your own cloud account.
Migration and ongoing operation
Migration is largely one-time work: rebuilding metrics and flags, swapping SDKs and logging callbacks, and re-running live experiments. Ongoing operation is recurring, covering upgrades, backups, monitoring, access reviews and on-call coverage for GrowthBook and its database. Costs rise with the number of live experiments, custom SDK integrations and compliance evidence you must produce. Request from any implementation partner a fixed-scope quote that separates the one-time migration from a recurring support or upgrade retainer.
What a move from Eppo to GrowthBook involves
The sequence moves experiment definitions, flags and SDK calls from Eppo to a self-hosted GrowthBook while the same warehouse keeps supplying the data, so results can be checked before live experiments are re-run.
Confirm warehouse access and permissions
Your data team confirms that GrowthBook can connect to the warehouse that already holds Eppo's assignment logs and fact tables, and that the connection user can run read-only SELECT queries on those schemas. GrowthBook documents that it runs only SELECT queries and transmits only aggregated statistics, so the security review should confirm that the service account matches that pattern. This step is done when a test query against the assignment table succeeds from the environment where GrowthBook will run, and the access approval is recorded.
Stand up GrowthBook in the target environment
Platform engineering deploys self-hosted GrowthBook in your own cloud account or data center. The GrowthBook self-hosting documentation describes a single Docker image that bundles the front end, API and statistics engine, a MongoDB or compatible database for metadata, and an official Helm chart for Kubernetes. Your team should confirm the production database choice, file storage target and SSO approach before go-live, and confirm which plan applies, since Enterprise features such as SSO, approval workflows and holdouts are not in the free self-hosted Open Source plan. This step is done when the instance runs, administrators can log in, and the warehouse connection shows as healthy.
Recreate metrics, segments and flags
Because GrowthBook's documented importers cover LaunchDarkly and Statsig rather than Eppo, the metric definitions, segments and feature flags usually have to be rebuilt by hand or by script from Eppo's exported configuration. Analysts map each Eppo metric to a GrowthBook fact table or SQL definition, and engineers recreate each flag with its fallback value, targeting rules and rollout percentages. Keep a written inventory of every flag and metric with its owner. This step is done when each live Eppo metric has a GrowthBook equivalent that a reviewer has signed off, and the inventory lists any metric that could not be carried over.
Swap SDKs and logging callbacks
Application teams replace Eppo's SDK calls with a GrowthBook SDK for each service and client platform, and they update the experiment exposure logging callback so each assignment is written to the same warehouse table that the analysis reads. The GrowthBook importer documentation notes that the application must switch from one vendor's SDK to another after any import, and this swap is code work that has to be reviewed like any other release. Where OpenFeature is already in use, a provider change may limit the code changes, so confirm that option with your engineers. This step is done when every service evaluates flags through the GrowthBook SDK in a staging environment and exposure events reach the warehouse with the expected fields.
Run parallel checks on historical data
Analysts run GrowthBook against a past experiment whose results were already published in Eppo and compare the two outputs for the same metric, population and date range. Differences in the statistical method, variance handling, outlier treatment or metric filters must be explained and documented before any decision uses GrowthBook. Statisticians should decide whether any gap is an accepted change in method or a defect to fix. This step is done when a written reconciliation for each core metric lists matching results and any accepted differences, signed by the analytics owner.
Re-run live experiments in GrowthBook
Teams restart each active experiment in GrowthBook, normally as new experiments rather than by copying Eppo's running state, so that assignment and analysis are owned by one system from the start. Product owners should decide whether to keep users in their current variant during the switch or reassign them, and that choice affects the results, so record it in each experiment write-up. This step is done when every experiment planned for migration is running in GrowthBook with a documented start date and an owner.
Retire Eppo access
Once no service calls Eppo and every experiment has moved, the team revokes Eppo's warehouse credentials and removes its SDK from the codebases. Before access ends, the exit work described in the exit checklist sibling page should be complete, including saving flag configuration, metric definitions and experiment write-ups. Confirm the renewal or termination terms with Eppo by Datadog, since its support status is a question to settle before moving. This step is done when the warehouse audit log shows no Eppo connections, the SDK is absent from builds, and the contract end is confirmed in writing.
Questions buyers ask before choosing or hiring help
How much effort does a self-hosted GrowthBook rollout take?
The effort depends mostly on how many environments you run, how many data sources you connect and whether you need the Enterprise features. GrowthBook ships its Next.js front end, Express API and Python statistics engine in one Docker image, and it stores metadata in MongoDB or a compatible database. The self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production, so your team must decide who operates that database. Plan for an identity provider decision, backups, upgrades and a Kubernetes or Docker host with monitoring. Ask your vendor or implementation partner to list each component and who owns it before you agree on a scope.
Can our team run GrowthBook without outside help?
Many teams can, provided they have someone comfortable with containers, a relational or document database, and SQL against their warehouse. GrowthBook maintains an official Helm chart for Kubernetes and supports local, Amazon S3 or Google Cloud Storage for file uploads, which covers the common deployment paths. The harder part is ownership: someone must own upgrades, such as the move to v5.1.0 released on September 22, 2026, and must own metric definitions that analysts trust. Outside help is most useful for the first deployment, the warehouse connection review and a runbook your staff can follow.
What does the work need from our data and platform staff?
Data staff need to identify the assignment and event tables, confirm the fact tables used for metrics, and grant GrowthBook a read-only role. GrowthBook runs only SELECT queries against your source and transmits only aggregated statistics, so the access review is narrow but still needs sign-off. Platform staff need to provision the host, the database, secrets, network paths to the warehouse and SSO if you use it. Confirm with GrowthBook whether your specific warehouse, such as Snowflake, BigQuery, Databricks or Trino, has any version or driver requirements.
How long does a migration from Eppo take, and what drives it?
The duration is driven by the number of live flags, metrics and experiments, how many SDK integrations you must change, and how much of your metric logic is already documented. There is no fixed duration in the sources available to us, so ask for a timeline tied to a written scope rather than a general estimate. Key drivers are the warehouse connection, SDK swaps in each service, rebuilding metric definitions and validating results against Eppo output for a few known experiments. Teams with many services or undocumented metrics should expect the longest phase to be verification.
What happens to running experiments during the switch?
Running experiments should be handled as a deliberate cutover, not a background task. Assignment continuity matters most: if users are reassigned to a different variant mid-test, results become hard to interpret. Plan to keep the same bucketing key and sticky bucketing behavior where you can, and confirm this with GrowthBook before you start, since sticky bucketing is part of the Enterprise feature set on the self-hosted plan. Freeze metric definitions during the test window, and record decisions in an experiment log so the results stay auditable.
Does the open-source GrowthBook core cover what we need?
The free self-hosted Open Source plan is limited to 1 project with unlimited users and unlimited API requests, according to the GrowthBook pricing page. Enterprise self-hosting adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Check which of these your current Eppo setup actually uses, because the answer decides whether you need a paid tier. The LICENSE file places code outside the enterprise directories under the MIT Expat license, so review that boundary with your legal team.
When is an implementation partner worth the cost?
A partner is most useful when the rollout touches several services, when your warehouse access must pass a security review, or when you need evidence for an internal or external control assessment. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen does not issue audit reports or certifications, so independent assessors remain necessary where compliance requires them. Ask for a written scope that lists deliverables, responsibilities and the handover, then compare it with an internal estimate.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Eppo vs GrowthBook, we start by checking which warehouse, identity setup and experiment workflow your team actually runs before recommending a deployment.
How we scope
- We confirm which warehouse, assignment tables and event tables GrowthBook would query, and who has read access to them.
- We map which GrowthBook plan features your experiments need, including whether self-hosted Enterprise features are required.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy GrowthBook in your cloud account or data center, using the Docker image or the official Helm chart, with MongoDB or a compatible database.
- We connect data sources with read-only SELECT access and verify that only aggregated statistics leave your warehouse.
- We rebuild metric definitions, feature flags and SDK logging callbacks, then test assignment and results against a known baseline.
How we hand over
- You receive configuration records, runbooks for the GrowthBook deployment, and a written list of metrics and flags with their owners.
- We document the warehouse access model, backup approach for the metadata database and the upgrade steps for new GrowthBook releases.
- Your team is walked through the experiment workflow so analysts and engineers can run and review tests after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover version upgrades, security testing of the deployment and changes to data source connections.
- We confirm the support scope, response expectations and upgrade cadence in writing before the retainer starts.
