Do you need an Eppo alternative after the Datadog acquisition?
If your Eppo contract or renewal now sits under Datadog ownership, the decision is whether to stay on the current terms or move experimentation to self-hosted GrowthBook. Staying is reasonable only when your contract terms and Datadog's roadmap commitments are confirmed in writing. Replacing is a realistic option when your experiments already run against your own warehouse, because the assignment logs and fact tables you depend on are then yours to keep. The constraint to manage is control over three things: the vendor you pay, the data path between your warehouse and the experimentation tool, and the terms on which you renew.
The public facts available here do not document Datadog's support commitments for customers who do not use Datadog Product Analytics, so do not assume the integration story applies to you. Ask the vendor for the following in writing: the support and maintenance term covering your contract, whether pricing or packaging changes at renewal, whether data retention and export rights are unchanged, and which product roadmap items are committed for your plan. If the answers are vague, treat that as a signal to plan an exit rather than a reason to wait.
A practical next step is to check how much of your experiment logic lives outside Eppo. If your warehouse already holds the exposure events and metric tables, a self-hosted GrowthBook deployment can read them directly, and the work shifts to rebuilding flags, metrics and SDK calls. Run a short pilot on one low-risk experiment before committing a renewal date, and decide your stay-or-replace answer by the time your notice window opens, not after.
What a stay-or-replace decision has to satisfy
A renewal forces a decision on five fronts at once: the vendor's future, where experiment data lives, how definitions move, what the license allows and how portable the SDK layer is. Each card below names one of these checks and what to confirm before you sign or migrate.
Contractual continuity under new ownership
Eppo is now sold as Eppo by Datadog, so the contracting entity, support terms, data processing terms and product roadmap may differ from what you signed originally. Ask Datadog in writing which terms carry over at renewal, what happens to pricing and support levels, and how much notice you get if a product or integration changes. Get the new order form reviewed before you accept it.
Experiment data staying in your warehouse
Confirm which data Eppo reads from your warehouse, which tables it writes back to, and whether any assignment, event or result data leaves your environment. Warehouse-native tools keep raw events in your warehouse, but the exact write-back and retention behavior is what your privacy and residency reviewers will ask about. Document it before comparing with a self-hosted alternative.
Reading and writing flag and metric definitions
Flag configuration, metric definitions and experiment write-ups are the assets most likely to stay trapped in a vendor UI. Before any renewal decision, confirm you can export or API-read every flag, metric, segment and experiment record, and that the export includes targeting rules and history. If an export is partial, plan to rebuild those definitions yourself.
Licensing that matches internal policy
Self-hosted options differ in license terms. GrowthBook's core is MIT licensed, but its enterprise directories fall under a separate license, and Unleash moved its server to AGPLv3 with v8.0.0. Have legal and security map each candidate's license against your policy on modified network services, embedded code and paid features before you commit to a design.
An SDK layer that can change vendors
OpenFeature is a CNCF project, currently at the Incubating maturity level, that provides a vendor-agnostic API. Its providers translate between application code and a flag management system, so application code can stay the same when the backend changes. Ask your engineers which Eppo SDK calls are direct and which go through OpenFeature, because direct calls add rework to any move.
What Datadog ownership does and does not settle for teams not on Datadog
Datadog ownership does not, by itself, tell a non-Datadog team what Eppo will cost, support or include at its next renewal. The facts available for this page establish that Eppo is sold by Datadog and that the content group describes continued support. They do not describe support terms, the product roadmap, pricing changes or feature availability for customers who do not use Datadog Product Analytics. Treat the acquisition as a reason to ask questions in writing, not as evidence that any particular commitment exists.
Before renewing, request written answers on five points. First, support scope: which channels, response expectations and escalation paths apply to your contract after the transfer to Datadog's sales and support organization. Second, data handling: where your assignment logs, exposure events and results are processed, which Datadog subprocessors touch them, and how deletion works at contract end. Third, feature availability: which capabilities you depend on, such as specific metric types, warehouse connectors or SDK support, remain available when you are not using the Datadog Product Analytics integration. Ask the vendor to name any feature that is planned to change, with dates.
Fourth, renewal pricing and notice periods: the renewal price basis, the uplift cap if one exists, and the number of days' notice required to cancel or change the plan. Fifth, exit assistance: whether the vendor provides export help, a transition period with read access, or migration support, and whether any of it carries a fee. Compare the answers with the export steps in your own warehouse before deciding. A self-hosted GrowthBook plan starts from the GrowthBook pricing page, so the renewal decision and the replacement decision can be made on the same written facts.
How Eppo, self-hosted GrowthBook and flag-only tools compare
This table compares staying on Eppo by Datadog with self-hosted GrowthBook Open Source and self-hosted GrowthBook Enterprise on data location, cost components, limits and governance. Read the cost rows as who pays for each part, since warehouse compute recurs under every option. Flag-only tools such as Unleash or Flagsmith cover flags, but confirm experiment analysis in each tool before treating them as a replacement.
| Capability | Eppo by Datadog | Self-hosted GrowthBook Open Source | Self-hosted GrowthBook Enterprise |
|---|---|---|---|
| Where event data is analyzed | Reads assignment and fact tables in your warehouse; confirm the deployment model with Datadog | Runs read-only SELECT queries in your warehouse and sends only aggregated statistics | Same warehouse query model as Open Source; confirm the setup with GrowthBook |
| Software subscription | Set by your Datadog contract; confirm renewal terms and what is bundled | No license fee for the self-hosted core | Custom quote from GrowthBook; the pricing page lists Enterprise as custom |
| Warehouse compute | Recurring; analysis queries run against your warehouse | Recurring; grows with experiment count, metrics and refresh frequency | Recurring; same drivers as Open Source, so query design matters in every option |
| Hosting and MongoDB | Handled by the vendor; you pay for the subscription instead | Your servers or cloud, plus MongoDB or a compatible database for metadata | Same hosting and database as Open Source, plus the Enterprise setup effort |
| Operations and upgrades | Vendor-run; confirm which support and upgrade duties continue after the acquisition | Your team patches, backs up and upgrades; an official Helm chart is available | Same duties as Open Source, plus maintaining SSO and SCIM provisioning |
| Project and user limits | Confirm plan limits in your contract | 1 project, unlimited users and unlimited API requests; core is MIT outside enterprise directories | Plan limits are set in the written agreement; confirm project count and seats |
| Governance and rollout controls | Confirm SSO, permissions, approvals and holdouts in your plan | Basic setup only; no SSO, SCIM, approval workflows or holdouts | Adds SSO, SCIM, advanced permissioning, approval workflows, safe rollouts and holdouts under the Enterprise License |
| Main trade-off | Least operating work, but less control over terms and roadmap after the acquisition | Full control and no fee, but one project and your team runs the platform | Governance and safe rollouts included, at the cost of a license and a longer procurement |
Which path fits your situation
Staying is reasonable when your renewal date is later than your evaluation window and the contract does not yet say what changes under Datadog ownership. The main risk is signing a multi-year term before you know how Eppo will be packaged, priced and integrated with Datadog Product Analytics. Your current setup still matters, because Eppo reads from your own warehouse, so the data you already own does not move while you wait.
- Contract scope: Ask for the current product name, support terms and any change clauses tied to the acquisition in writing.
- Integration plans: Ask which Datadog Product Analytics features are planned, and whether any would become required for your current Eppo use.
- Warehouse list: Confirm your warehouse (BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica) is still supported in the renewal terms.
- Exit data: Confirm which flag configuration, metric definitions and experiment write-ups you can export before access ends.
- Short renewal: Prefer a shorter term or a termination right over a long commitment while the roadmap is unclear.
Before renewing, confirm every item above in the order document, not only in a sales call.
Self-hosted GrowthBook Open Source fits teams whose experimentation needs fit inside one project. The self-hosted Open Source plan is free with unlimited users, one project and unlimited API requests, according to the GrowthBook pricing page. The core code outside its enterprise directories is MIT Expat licensed, so the license of the parts you run is clear. Your cost is then infrastructure, MongoDB, your warehouse compute and internal operations time, not a per-seat fee.
- Project count: Count the Eppo projects you actually use, since the free plan supports one.
- Feature gaps: Check whether you need SSO and SCIM, advanced permissioning, approval workflows, holdouts, or safe rollouts, which are Enterprise features.
- Warehouse match: Confirm your warehouse is in the GrowthBook list and that a read-only SELECT user can be provisioned.
- Deployment: Plan a Docker image or the official Helm chart, and a managed MongoDB such as MongoDB Atlas or AWS DocumentDB for production.
- Migration effort: Expect to rebuild metrics and SDK calls, and to move application code from the LaunchDarkly or Eppo SDK to a GrowthBook SDK where relevant.
Confirm the project limit and feature list against the current GrowthBook pricing page before you design around them.
Enterprise is the path when identity, approval and statistical controls are requirements, not preferences. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts, according to the GrowthBook pricing page. Those features sit under the GrowthBook Enterprise License, so you need a commercial agreement for the directories that contain them. Pricing for Enterprise is custom, so it has to come from a quote.
- Required features: List which of SSO, SCIM, approval workflows and holdouts your controls and experiment process depend on.
- License scope: Ask GrowthBook which files and features the Enterprise License covers in your deployment.
- Identity integration: Confirm your identity provider supports the SSO and SCIM setup you need.
- Warehouse list: Verify BigQuery, Snowflake, Redshift, Databricks, ClickHouse, Postgres, MySQL, SQL Server, Athena, Presto or Trino and Vertica against your actual data sources.
- Quote scope: Request a written quote that lists the hosting, support and upgrade terms along with the license.
If you cannot name the Enterprise features you need, you probably belong on the Open Source path.
How to deploy self-hosted GrowthBook alongside your warehouse
This sequence runs GrowthBook in your own infrastructure against the warehouse that already holds your Eppo data, so you can compare results in parallel before any traffic moves. It ends with a documented cutover decision rather than a switch made on assumption.
Confirm the warehouse and read-only credentials
Your data platform owner identifies the warehouse holding Eppo's assignment logs and fact tables, then creates a dedicated service account that can run SELECT queries on those schemas and nothing else. Security reviews the grant, and the team records which datasets are in scope. Done means the account can query the tables, and a test write attempt is refused. Ask Eppo or Datadog to confirm where assignment and event data is exported and in what format, because that path determines which tables GrowthBook must read.
Provision MongoDB or a compatible database
The platform team provisions the metadata store that GrowthBook uses. The GrowthBook self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production, so that backups, patching and high availability sit with the provider. Your team sets network rules so only the GrowthBook workloads can reach the database. Done means the GrowthBook service account can connect over a private network path and the backup policy is confirmed in writing.
Deploy the GrowthBook image or Helm chart
Platform engineers deploy GrowthBook as a single Docker image, which bundles the Next.js front end, the Express API and the Python statistics engine, or install the official Helm chart on Kubernetes. They store secrets such as the database connection string and encryption keys in your existing secrets manager. Done means the application starts, the health endpoint responds, and an administrator can sign in to the UI behind your identity provider.
Configure file uploads for your storage target
The team selects local storage, Amazon S3 or Google Cloud Storage for uploaded files, as the GrowthBook self-hosting documentation supports all three. Object storage with versioning and access logging is the usual choice for regulated environments, and the bucket policy should restrict access to the GrowthBook service identity. Done means a test upload persists after the application restarts and the bucket shows the expected access records.
Connect the warehouse data source with SELECT-only access
An administrator adds the warehouse as a GrowthBook data source using the read-only credentials from the first step. GrowthBook runs SELECT queries against the source and transmits only aggregated statistics, so the team confirms this in the network and query logs. Metric definitions are rebuilt against the same tables Eppo reads. Done means a test query returns results for a known experiment, and the warehouse audit log shows only SELECT statements from the GrowthBook account.
Import flags from the source platform
Where an importer exists, the team uses it to bring flags into GrowthBook. The LaunchDarkly and Statsig importers are documented, and the importers read projects, environments and flags through API tokens, with the LaunchDarkly importer warning that advanced setups may not be fully handled. No Eppo importer appears in the supplied documentation, so Eppo flag and metric definitions must be exported manually or with the Eppo export path that Eppo or Datadog confirms. Done means each flag is reviewed in the preview, and the team has a written list of items that did not carry over.
Run a parallel validation period before cutover
For a set period agreed by the experimentation and data teams, both platforms run against the same warehouse data. Analysts compare exposure counts, metric values and statistical outputs for completed experiments, and engineers confirm that the application still reads flags from the source SDK until the switch is approved. Any mismatch is logged with its root cause. Done means the team signs off on a written reconciliation report, and the cutover plan names the owner of each remaining step.
Evidence to keep before the renewal decision
Whether you stay with Eppo or move to self-hosted GrowthBook, the renewal decision should rest on written records rather than memory of what was promised. The cards below cover the contract, the data flows, the portable assets, the license review and the comparison of results. DeployOpen prepares this evidence for your team, but it does not issue audit reports or certifications; independent auditors and certification bodies do.
Renewal terms and support statements
Collect the signed renewal or notice terms, the notice period, and any written statement from Eppo or Datadog about what support continues and for how long. Ask specifically whether the integration with Datadog Product Analytics is part of the contracted scope or a roadmap item. Store these with dates, because support scope is the first thing that changes after an acquisition and the last thing you can reconstruct later.
Data-flow record for assignment logs
Document every table and assignment log Eppo reads, where each lives, who owns it, and which credentials or roles the tool uses to query it. This record shows whether events already sit in your warehouse, which is the basis for any move to GrowthBook, which runs read-only SELECT queries against your data source and transmits only aggregated statistics. Confirm the list against your warehouse access logs rather than the vendor's documentation alone.
Exported flags, metrics and write-ups
Export flag configurations, metric definitions, experiment results and the written rationale for each experiment before access ends. Flag state, targeting rules and metric SQL are the assets most likely to be lost in a hurry, and they are needed to rebuild live experiments in GrowthBook or to answer audit questions about past decisions. Keep the exports in a location your team controls and record who produced them and when.
License review of the GrowthBook edition
Confirm which GrowthBook edition you plan to run and check it against internal open-source policy. The core code outside the enterprise directories is MIT licensed, while the enterprise directories fall under the GrowthBook Enterprise License. Features such as SSO and SCIM, approval workflows and holdouts belong to the Enterprise tier on the self-hosted plan, so list which ones your experiments depend on and record that decision.
Side-by-side validation of results
Run both tools against the same assignment and event tables for a set of past experiments and compare the metric results, sample sizes and statistical outputs. Differences usually trace to metric definitions, attribution windows or filters rather than to the statistics engines, so record each mismatch and its cause. This validation record is the strongest evidence that a migration preserved decision quality, and it should be kept with the migration sign-off.
Questions teams ask before moving off Eppo
What does moving off Eppo to self-hosted GrowthBook actually cost?
The cost is spread across five components: the Eppo subscription you stop paying, the GrowthBook edition you choose, warehouse compute, hosting for GrowthBook and its MongoDB-compatible metadata store, and the one-time migration plus ongoing operation. GrowthBook's self-hosted Open Source plan is free to license, with 1 project and unlimited users, according to the GrowthBook pricing page. Eppo does not publish its prices, so ask Datadog for a written renewal quote to compare against. Warehouse compute is spent by both tools, so it mostly stays flat. Ask any implementation partner for a quote that lists each component separately, marking which items are one-time and which recur.
How long does a migration from Eppo to GrowthBook take?
No duration is fixed here, and the timeline depends on the work, not the tool. The main drivers are how many metrics and flags you must recreate, how many live experiments must run to completion on both sides, how many SDK integrations need swapping, and how clean your warehouse tables already are. Because Eppo reads your own assignment logs and fact tables, much of the effort is rebuilding definitions rather than moving data. Ask for a milestone plan in the written scope that ties each phase to a named deliverable and a validation step.
What must our internal team provide during the migration?
Your team has to supply four things before work can finish:
- Read access to the warehouse schemas that hold assignment and event tables, plus a service account GrowthBook can use with SELECT-only queries
- Named metric owners who confirm definitions, denominators and exclusions
- Engineers who swap the Eppo SDK for a GrowthBook SDK and add the logging callbacks that record exposures
- Sign-off from experiment owners on which live tests re-run and which are closed
GrowthBook's importer also warns that the application must still change SDKs after import, so plan that engineering time explicitly.
Can our own engineers do the migration without an outside partner?
Yes, many teams can, provided they have warehouse, deployment and experimentation skills in-house. GrowthBook publishes self-hosting documentation and an official Helm chart for Kubernetes, and its LaunchDarkly and Statsig importers are documented. The harder parts are usually statistical validation of recreated metrics, SDK and logging changes across production services, and operating the stack afterward. Ask yourself whether you have owners for each of those three areas. If not, a fixed-scope engagement can cover the gaps while your team keeps ownership of the definitions.
Is GrowthBook Open Source enough for our experimentation program?
It depends on which controls your program needs. The self-hosted Open Source plan includes unlimited API requests and unlimited users, but only 1 project. The GrowthBook pricing page lists the following as Enterprise-only for self-hosting: SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts. Map your current Eppo usage against that list. Also confirm the license boundary: GrowthBook's LICENSE file says code outside its enterprise directories is MIT Expat licensed, while those directories fall under the GrowthBook Enterprise License.
What changes if we need the GrowthBook Enterprise plan?
Enterprise adds a licensed commercial layer on top of the MIT-licensed core, and its cost is quoted by GrowthBook, not published. The pricing page lists Enterprise at custom pricing. Self-hosted Enterprise adds SSO and SCIM, advanced permissioning, approval workflows, and experiment features such as sticky bucketing and holdouts. Your architecture stays the same, but your license, identity integration and change-control processes do. Ask GrowthBook for the self-hosted Enterprise quote in writing, and confirm which of your current Eppo features map to it before you commit.
How do we request a fixed-scope quote from DeployOpen?
Send a written scope that covers the number of metrics, flags and live experiments to migrate, the warehouse and data sources in use, the services that need SDK changes, the GrowthBook edition you expect to run, and where it will be hosted. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside your own infrastructure, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so the quote follows from that written scope. Ongoing support and upgrades are available as retainers.
How DeployOpen works on this
DeployOpen starts with a written scope that compares staying on Eppo after the Datadog acquisition with moving to self-hosted GrowthBook, then builds, tests and hands over only the path the team chooses. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Inventory which Eppo features, warehouse connections, SDKs and metrics your teams use today
- Confirm with Datadog what support and Product Analytics integration terms apply to your contract
- Agree in writing the deliverables, timelines and decision criteria before any work starts
How we build
- Stand up a self-hosted GrowthBook test environment in your own cloud account or data center
- Connect a read-only warehouse user so only SELECT queries and aggregated statistics leave the warehouse
- Rebuild a sample of flags and metrics, then compare results against Eppo output for agreed experiments
How we hand over
- Document the architecture, SDK changes, logging callbacks and the Enterprise features you need
- Provide a cutover runbook with rollback steps for live experiments and flag evaluation
- Capture flag configuration, metric definitions and experiment write-ups before any Eppo access ends
How we support
- Offer ongoing upgrades, backups and operational support for the self-hosted stack as a retainer
- Track upstream GrowthBook releases and license terms so your team can plan each upgrade
- Run continuous security testing of the experimentation platform if your risk team requires it
