Migrate from Eppo to GrowthBook

Migrate from Eppo to GrowthBook: what the move involves

Teams reviewing an Eppo renewal, facing a data residency requirement, or wanting to run experimentation on the warehouse they already operate usually ask one question first: how much of the move involves moving data? The short answer is that the migration is mostly rebuilding metrics, flags and SDK wiring against the same warehouse, because the assignment logs and fact tables already sit in your own environment. What changes is the layer on top: which tool reads those tables, how metric definitions are written, how flags are evaluated in the application, and where exposure events are logged.

The work usually falls to three groups. Platform engineering owns GrowthBook's deployment, its MongoDB metadata store, authentication and the connection to the warehouse with a read-only role. Data engineering and an analyst re-create the metric definitions and confirm that the SQL against the warehouse returns the same numbers Eppo produced for live experiments. Product engineering swaps the SDK calls and the logging callback in each service. Effort and risk concentrate in the metric and SDK steps, not in infrastructure, and the riskiest moment is running old and new assignment logic side by side on live traffic.

Treat this section as a planning guide, not a quote. Effort depends on how many experiments are running, how many custom metrics Eppo holds, and how many services call the SDK. Ask GrowthBook's documentation about which items its LaunchDarkly and Statsig importers can carry over, and confirm for Eppo specifically which configuration you can export before access ends. Where a fact is unclear in your environment, check it with the vendor and your own data team rather than assuming it carries over.

Which Eppo capabilities map cleanly to GrowthBook and which need rework

This table maps the Eppo capabilities a migration touches to their GrowthBook equivalents and marks each one as clean, needs rework, a gap or a license decision. Read the status column first, then the migration note, which names what to confirm in your own warehouse and environments. The main takeaway is that the warehouse connection carries over with little change, while metrics, flags, SDK calls and experiment history must be rebuilt, and Enterprise-only features need a license decision before cutover.

Eppo capability	GrowthBook equivalent	Migration note	Status
Warehouse connection	Data source connections to Snowflake, BigQuery, Redshift, Databricks and others	Create a read-only role. Confirm your warehouse appears in the supported list.	Clean
Metric definitions	Metrics defined in the GrowthBook UI from warehouse SQL	Recreate each metric from its fact table. Eppo definitions do not transfer automatically.	Needs rework
Feature flags	Feature flags with targeting rules, rollouts and environments	Built-in importers cover LaunchDarkly and Statsig, not Eppo. Rebuild flags by hand or by script.	Needs rework
Assignment logging	SDK tracking callback that sends exposure events to your pipeline	Keep writing to your existing assignment table. Confirm the callback fields match your schema.	Needs rework
SDK evaluation	GrowthBook SDKs for your application language	Replace Eppo SDK calls in code. Confirm SDK support for every language and runtime you use.	Needs rework
Experiment analysis and statistics	Statistical results computed by the bundled Python engine from warehouse aggregates	Run both tools on the same data and reconcile differences before you switch decisions.	Needs validation
Sticky bucketing and holdouts	Sticky bucketing and holdouts, documented for self-hosted Enterprise	Needed only if you rely on these Eppo behaviors. Confirm usage before choosing a license.	License decision
Approval workflows and advanced permissions	Approval workflows and advanced permissioning, documented for self-hosted Enterprise	The free self-hosted plan allows 1 project. Count your Eppo projects before planning.	Gap on free tier
Experiment history	Experiment records held in GrowthBook's metadata database	Export Eppo write-ups and results before access ends. Confirm what GrowthBook imports from history.	Needs rework

What data and definitions you can move, and what you rebuild

Eppo reads data that already sits in your warehouse, so most of the migration is about definitions, not data movement. Four inventory items decide how much work the move takes and what you must capture before Eppo access ends.

Warehouse tables and assignment logs

Assignment logs and event tables stay where they are. GrowthBook connects to the same warehouse and runs read-only SELECT queries against them, so no experiment data has to be copied into a new system. Check that the warehouse role GrowthBook uses can read every assignment and fact table your experiments depend on, and that the SQL it runs against them returns the same user and exposure counts you see in Eppo before you trust any result.

Metric and fact definitions

Eppo metrics, including their aggregation logic, filters and denominators, do not transfer automatically. Recreate each one in GrowthBook as a SQL-backed fact table or metric against the same source tables, then run old and new versions over a closed experiment. Where numbers differ, the cause is usually a filter, a time window or a conversion definition, so document the difference before you move the metric into production use.

Feature flags and targeting rules

Flag configuration, targeting rules, rollout percentages and environments live in Eppo's interface and must be rebuilt in GrowthBook. Eppo is not among the platforms GrowthBook documents an importer for (its importers cover LaunchDarkly and Statsig), so plan a manual rebuild or a script that reads your exported flag list. Record each flag's owner, default value and the code paths that read it so that nothing is orphaned at cutover.

Experiment write-ups and results

Hypotheses, decisions, launch dates and readouts are often held in Eppo or in linked documents. Export what Eppo offers for each experiment, confirm the export path directly with Eppo, and archive the results with the metric versions used to compute them. Without that archive, a future audit or a question about a past decision will rely on memory rather than evidence.

Application logging callback and SDK swap

Application code calls the Eppo SDK for assignments and must send exposure events through a logging callback. In GrowthBook, you replace the SDK and register a tracking callback that writes exposures to the same assignment table your warehouse already holds. The GrowthBook importer documentation notes that the application still has to switch SDKs after an import, so schedule this change in each service and test that exposure rows arrive before running a live experiment.

The migration sequence from inventory to decommission

This sequence moves live experiments from Eppo to GrowthBook without losing assignment history or results. Each step ends with a written artifact, so the cutover and decommission decisions rest on evidence rather than memory.

Inventory flags, metrics and running experiments
Product analytics or experimentation owners list every Eppo feature flag, metric definition, fact table reference, segment and running experiment, noting the owning team and the warehouse tables each metric reads. Engineers confirm which application code paths call Eppo SDKs and which logging callbacks write assignment events. The output is an inventory sheet with one row per item, a status column and a named owner. The step is done when every running experiment has a documented metric set and a decision date agreed with its owner.
Pilot one metric and one flag
Platform and data engineers connect a self-hosted GrowthBook instance to the same warehouse Eppo reads, using a read-only role that runs SELECT queries, and recreate one low-risk metric and one non-critical flag. The team checks that the GrowthBook metric query returns values that match the Eppo output for the same date range. Confirm the supported warehouse and deployment path in the GrowthBook data source and self-hosting documentation before connecting, since MongoDB hosting for GrowthBook metadata is a separate decision. The output is a short pilot report showing matched results or the reasons they differ.
Recreate metrics and flags in GrowthBook
Analysts translate the remaining Eppo metric definitions into GrowthBook metrics and build flags with the same fallback values, targeting rules and rollout percentages. Where the GrowthBook importers apply to your setup, the team reviews what they carry over, since the LaunchDarkly importer documentation warns that advanced setups may include cases it cannot handle. Engineers confirm that each rebuilt item matches its inventory row. The output is a reconciled definitions table that maps each Eppo object to its GrowthBook counterpart, with any unmapped items listed as open issues.
Run both tools in parallel
For each live experiment, the team keeps Eppo assignment logging active while GrowthBook also logs assignments through its tracking callback, so both systems record the same users in the same window. Analysts run both analyses on the same warehouse tables and compare effect sizes, sample counts and significance outcomes. Discrepancies are traced to metric definitions, filters or assignment timing before any decision is made. The output is a reconciled results table for each experiment, signed off by the analyst who owns the metric.
Cut over by flag and by experiment
Engineers move one flag or one experiment at a time from the Eppo SDK to a GrowthBook SDK, switching the logging callback at the same time, and confirm in the warehouse that assignment events arrive for both control and treatment users. New experiments start in GrowthBook only after the parallel results agree. Application owners sign off each cutover item. The output is a signed-off cutover checklist that lists each flag and experiment, the switch date, the assignment check result and the approver.
Decommission after experiments finish and archive write-ups
Once every Eppo experiment has concluded and its SDK calls are removed from the code, the team exports final results, decision records and experiment write-ups, and stores them in the organization's own document system. Access to Eppo is reviewed and revoked according to the contract terms, and the Eppo output tables remain in the warehouse under existing retention rules. Confirm with Eppo or Datadog what export and access options apply at your renewal date. The output is an archived experiment record for each completed test and a closure note that lists what remains in the warehouse.

What drives the cost and duration of the migration

This table lists the main drivers of migration effort and recurring cost when moving from Eppo to self-hosted GrowthBook, with how each one changes the outcome and how to keep it down. Read it to scope the work before asking for a quote, since most of the effort sits in rebuilding definitions and validating results rather than in software installation.

Driver	Why it changes cost or effort	How to keep it down
Live experiments and metrics	Each running experiment and metric definition has to be recreated and checked against Eppo results, so counts drive validation time directly.	Retire stale experiments before the move and migrate only metrics that active decisions depend on.
Flags and SDK integrations across services	Each service that calls Eppo needs its SDK and logging callback swapped, and each change needs testing and deployment.	Inventory every service first and group services that share one evaluation library so they change in one release.
Custom SQL in metric definitions	Complex joins, deduplication and business logic must be rewritten against the same warehouse tables, and each query needs review.	Move shared logic into reusable warehouse views or models before rebuilding metrics, so definitions are written once.
Enterprise features needed	Features such as SSO and SCIM, approval workflows, sticky bucketing, holdouts and safe rollouts appear only in the paid self-hosted Enterprise plan on the GrowthBook pricing page, which is a recurring license cost.	List required controls before choosing a plan, and confirm with GrowthBook which ones the Open Source plan lacks for your use case.
Warehouse compute during parallel runs	Running GrowthBook beside Eppo means both tools may query the same tables, so compute spend rises for the overlap period and recurs with each analysis.	Keep the parallel period short, reduce refresh frequency for historical analyses and confirm query volume with your warehouse team.
MongoDB hosting for metadata	GrowthBook stores its metadata in MongoDB or a compatible database, and the docs suggest a managed service for production, which is a recurring hosting cost plus backup and upgrade work.	Ask for a sizing estimate from your DBA, decide between managed and self-run hosting early and include backups in the operating plan.
Migration tooling for flags	The LaunchDarkly and Statsig importers do not cover Eppo, so flag configurations are typically recreated by hand or by script, which adds one-time effort.	Export Eppo flag definitions to a file and script the recreation so the same checklist can be reused for every flag.
Quote inputs to request	A fixed-scope quote depends on the counts above, the number of environments, the warehouse type and the operating model after cutover.	Provide these counts in writing before scope is agreed, and ask the quote to separate one-time work from recurring hosting and support.

What usually goes wrong in an Eppo to GrowthBook move

Most failures in this move come from definitions and runtime behavior, not from the GrowthBook software itself. Metrics, exposure logging, SDK coverage, default values, live experiments and feature parity each need an explicit check before cutover. The cards below pair each risk with the prevention step to take before anyone switches traffic.

Metric definitions drift from Eppo results

Recreated metrics often differ from Eppo's in small but material ways: the conversion window, the attribution rule, the filter on units or the table the event is read from. Two tools reading the same warehouse can still disagree if the SQL is not equivalent. Before relying on GrowthBook, rebuild each key metric and run it over the same date window and the same source table that produced a known Eppo result. Document every difference you cannot remove, and get sign-off from the analysts who own those numbers. Confirm that the GrowthBook data source connection uses the same warehouse account and schema.

Exposure logging breaks at cutover

Experiment results depend on exposure events that record which unit saw which variant. If the GrowthBook SDK's logging callback is not wired to the same assignment table Eppo fed, the analysis will show missing or empty variants without any error in the application. Test the callback in staging and confirm that each exposure row carries the experiment key, variant, unit identifier and timestamp in the format your analysis queries expect. Run a short comparison of exposure counts per variant between the old and new pipelines before turning on production traffic for any running test.

SDK swap misses services

Eppo assignments are often consumed by more services than the team that owns the main product. Batch jobs, mobile builds, backend workers and internal tools can each hold their own copy of the old SDK and keep assigning users under the previous logic. Inventory every repository and deployable that calls the old SDK, including scheduled jobs and edge code, and assign an owner to each. Track the swap in a checklist and confirm in production logs that no old-SDK calls remain before you decommission the source of the old keys.

Flags with different fallback values

A flag's default value controls what users see when the service cannot evaluate it, and that default may differ between the imported GrowthBook definition and the value the application code expects. An importer can carry over fallback values, but the application's own code paths may still hard-code assumptions. For each imported flag, compare the Eppo default, the GrowthBook default and the value the code uses when the SDK fails. Test the failure path explicitly by simulating an unreachable endpoint in a non-production environment, and record the results in the cutover runbook.

Live experiments restarted and biased

Recreating a running experiment in GrowthBook with a new start date or new assignment seed reshuffles users between variants. Users who already saw one variant may now see another, which contaminates the results and can invalidate the analysis. Where possible, keep existing assignments stable, using the same hashing attribute and seed, and freeze old experiments in Eppo until results are captured. If an experiment must restart, record it as a new analysis window and do not pool it with the earlier data. Ask the analytics lead to decide which running tests finish in Eppo and which begin in GrowthBook.

Feature gaps found after cutover

Some capabilities teams rely on in Eppo may sit in GrowthBook's Enterprise tier rather than the free self-hosted plan. The GrowthBook pricing page lists SSO and SCIM, advanced permissioning, approval workflows, sticky bucketing and holdouts as Enterprise self-hosted features, while the Open Source plan is limited to one project. Before committing, list the controls your governance process requires, such as approvals, role separation and holdout groups, and confirm each against the current pricing page and the Enterprise license terms. Ask GrowthBook directly for any gap your process depends on.

How the migration changes by team size and starting point

A small team with a handful of experiments and one warehouse usually has a short migration. Most of the work is recreating a few metrics and flags and pointing GrowthBook at the schema Eppo already reads. The first decision is the edition. The self-hosted Open Source plan is free with unlimited users and unlimited API requests, but it allows only one project. Confirm that one project can hold your flags and experiments without mixing unrelated product areas. (Illustrative: one web app and one mobile app can usually share a project. Two business units with separate metric sets may not.)

Edition first: Choose between the free self-hosted Open Source plan and self-hosted Enterprise before building anything, because the project limit and missing features such as approval workflows change how you structure the work.
Hosting footprint: GrowthBook runs as one Docker image backed by MongoDB or a compatible database. Compare a managed service such as MongoDB Atlas or AWS DocumentDB against running the database yourself, and name the person who patches and backs it up.
Metric rebuild: Recreate only the metrics that feed live decisions. Metrics you no longer use can stay in your exported write-ups and need no rebuild.
Parallel run: Keep Eppo running until one GrowthBook experiment reads the same assignment table and produces results you can reconcile.

Before starting, check that GrowthBook's read-only access to your warehouse uses a dedicated role and that the role can see only the schemas it needs.

Questions teams ask before moving from Eppo to GrowthBook

How much effort does moving from Eppo to GrowthBook take?

The effort depends mainly on how many metrics, flags and live experiments you run, and on how much of your Eppo setup is documented outside the tool. Because Eppo already reads your own assignment logs and fact tables, most of the work is rebuilding definitions in GrowthBook: connecting it to the same warehouse, recreating metrics and flags, swapping SDKs and logging callbacks, and re-running experiments. Ask your team to inventory every flag, metric and experiment before estimating. Ask us for a fixed-scope quote built from that inventory, which is the basis on which DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How long does an Eppo to GrowthBook migration run?

The duration depends on the number of live experiments, because you cannot simply switch off a running test without affecting users or results. Teams usually plan a parallel period in which metrics are recreated and checked in GrowthBook while Eppo keeps serving assignments, then cut over flag by flag. Experiments that started in Eppo should either finish there or be restarted in GrowthBook with a clear note about the change in assignment. Confirm with Eppo by Datadog what access and export window you will have before your contract changes, since that date sets your deadline.

What does the migration need from our team?

The move needs three groups of people working in parallel. Data engineers or analysts need read access to the warehouse that holds your assignment logs and fact tables, plus permission to create the connection GrowthBook uses. Product owners need to confirm which metrics, decision rules and experiment owners are still valid. Engineers need to replace the Eppo SDK and logging callbacks with GrowthBook SDKs in each application, and to test that assignments stay consistent. GrowthBook's documentation notes that the application still has to switch SDKs after any flag import, so plan engineering time per service, not only for the platform.

Can our team migrate from Eppo to GrowthBook without outside help?

Many teams with an experienced data and platform group can do it alone, especially for a small number of experiments. The hard parts are usually warehouse query performance, statistical settings that must match prior results, and the SDK change across many services. Teams often bring in outside help for the self-hosted deployment (the Docker image, MongoDB or a managed database, and the Helm chart for Kubernetes), backups, and upgrades. DeployOpen plans, implements, integrates, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Decide which parts you own before you request a quote.

Do Eppo experiment history and metrics export cleanly to GrowthBook?

Not automatically, and you should not expect a one-click copy of results. Assignment logs and event data stay in your warehouse, so the raw inputs carry over, but Eppo's definitions, dashboards and experiment write-ups are its own. Capture metric definitions, experiment hypotheses, decisions and results in a neutral format before access ends, and keep Eppo's output tables as an archive. GrowthBook's importers document support for LaunchDarkly and Statsig, not Eppo, so ask Eppo by Datadog what export options exist and ask GrowthBook how it can model your historical experiments.

What do the self-hosted Open Source plan limits mean for the move?

The self-hosted Open Source plan is free with unlimited users, one project and unlimited API requests, according to GrowthBook's pricing page. One project means that if your Eppo estate spans several product lines or business units, you must either consolidate them under one project or evaluate whether the Enterprise self-hosted plan is needed. Features such as SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts are listed for the self-hosted Enterprise plan, not the free one. Map each Eppo feature you use against that list before you commit to a design, and confirm current terms directly with GrowthBook.

What should we confirm with Eppo and GrowthBook before starting?

Start with written answers on four points. From Eppo by Datadog, confirm the support period, the data access and export options, and how assignment logs are kept after you stop using the product. From GrowthBook, confirm which warehouse connectors, statistics features and self-hosted plan features match your current use, and whether the license terms for the directories you deploy are acceptable to your legal team. Also confirm the current release you plan to deploy, since GrowthBook publishes new versions on its GitHub releases page. Finally, agree on the cutover criteria for each experiment before any flag moves.

How DeployOpen scopes and runs the Eppo to GrowthBook migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted GrowthBook inside your own infrastructure, including the cloud account, data center or air-gapped network where your warehouse already sits. Most engagements of this kind run under a fixed-scope written agreement that sets out the deliverables, the warehouse connections, the metrics and flags in scope, the cutover approach and the timelines, all agreed before any work starts. For an Eppo move, the scope document should list each live experiment, each metric definition and each flag that must keep running, because those items drive most of the effort and most of the risk.

The written scope also needs to settle who owns the decisions that a tool swap forces. Your data team decides how metric definitions map from Eppo's models to GrowthBook's, your platform team decides where the GrowthBook container and its MongoDB or compatible database run and how they are backed up, and your security team reviews the read-only warehouse credentials GrowthBook will use. DeployOpen can prepare the hardening baseline, the backup and restore procedure and the operating documentation, and it can run the parallel period where both tools read the same tables. Ongoing support, upgrades and continuous testing are available as retainers, which can be scoped separately from the initial migration.

DeployOpen does not publish a price list. A quote follows from the written scope, so the cost depends on how many experiments and metrics you carry across, how many warehouse sources are involved, how much of the flag configuration must be recreated by hand and what hosting and retainer terms you want. Ask for the quote to itemize the setup work, the parallel run, the documentation handover and any recurring retainer as separate lines, and ask which items you would still pay for if the migration pauses partway. DeployOpen is an independent implementation firm, so it does not hold vendor partner status or certification for GrowthBook or Eppo, and any compliance evidence it prepares is for your independent auditors to assess.

Migrate from Eppo to GrowthBook