What stays in your warehouse when you leave Eppo, and what does not
If a renewal, a Datadog-era question about ownership or a plan to move experimentation to self-hosted GrowthBook has you looking at an exit from Eppo, begin by sorting your data into two groups. The assignment logs and event tables Eppo reads are already in your warehouse, so they stay with you. Flag configuration, metric definitions and experiment write-ups live inside Eppo and must be captured before access ends. The export paths for those items must be confirmed in Eppo's current documentation and with your account team, and no Eppo export method should be assumed until someone on your side has tested it.
Start with an inventory. List the warehouse schemas and tables that Eppo reads or writes, including any intermediate and results tables it creates, and confirm who owns them, how long they are retained and which service accounts can read them. Next, record each flag key, environment, targeting rule, rollout percentage and prerequisite. For each metric, capture its SQL or definition, filters, denominators and owner. Write-ups usually hold the hypothesis, the decision and the dates, so store them in a format your team controls. GrowthBook reads your warehouse with read-only SELECT queries, so the event data does not need to move, but the rebuilt definitions depend on the inventory you made here. Review the GrowthBook data sources documentation to confirm your warehouse is supported.
Ask Eppo's account team for written answers on four points: which exports cover flags, metrics and experiment history, in what format, whether results tables keep their schema after the contract ends, and how access credentials are revoked. Run a test export on one flag and one metric before you rely on it, and compare the output with a recent Eppo result so you know the rebuilt definition matches. Plan for a parallel period in which both tools read the same warehouse tables, so any mismatch is caught while Eppo is still available. The effort involved depends on how many experiments and metrics you hold, so size it from your own inventory.
Which Eppo data can you export, and how
This table lists each category of Eppo data you may need after leaving, where it lives, how to get it and what to confirm. Rows that say to confirm have no documented export method in the sources we reviewed, so ask Eppo for written answers before access ends. The main takeaway is that event and assignment data usually stays in your warehouse, while configuration, metric definitions and write-ups need deliberate capture.
| Data type | Where it lives | Export method | Format and limits |
|---|---|---|---|
| Assignment logs and exposure events | Your warehouse, written by your own logging pipeline | No Eppo export needed if your team owns the tables. Confirm with Eppo which assignment tables it reads and how they are named. | Confirm with Eppo. Check retention and access on the warehouse side. |
| Eppo output schema: results and intermediate tables | Your warehouse, in the schema Eppo writes to | Query directly with warehouse access. Confirm with Eppo whether these tables are documented and whether they are rebuilt from source data. | Confirm with Eppo. Format follows the warehouse table definitions. |
| Feature flag configuration | Inside the Eppo application | Confirm with Eppo or the account team whether a bulk export or API read exists. Otherwise record flags by hand from the console. | Confirm with Eppo. Record keys, rules, rollout percentages and environments. |
| Metric and fact definitions | Inside the Eppo application, referencing warehouse tables and columns | Confirm with Eppo whether metric definitions can be exported. Otherwise document each metric's SQL logic, filters and owner. | Confirm with Eppo. Store definitions in version control once captured. |
| Experiment write-ups and decisions | Inside Eppo, plus any linked documents in your own tools | Export or copy write-ups and decision records from Eppo, and confirm with Eppo which export formats exist. | Confirm with Eppo. Keep hypotheses, launch dates and final decisions in a format your team controls. |
What does not carry over from Eppo, and the workaround for each
Your warehouse keeps the raw assignments, events and fact tables, but several things live only inside the Eppo application or its SDK runtime. Each card below names one of them, what it means for your exit, and a workaround you can run yourself before access ends.
Eppo SDK calls and assignment callbacks
Your application code calls the Eppo SDK to get variant assignments and runs a logging callback that writes exposure events to your warehouse. Those calls must be replaced with a GrowthBook SDK and its tracking callback, and the swap has to keep the same experiment keys and attribute names. Check that every experiment key in code maps to a GrowthBook experiment, and that exposure events keep the same user identifier so historical and new data line up.
Dashboards and saved views
Charts, filters and saved experiment views built in the Eppo interface do not export as a file you can import elsewhere. Before access ends, take a full inventory of each dashboard, record the metric, segment, date range and filters behind it, and save a screenshot. In GrowthBook, rebuild the equivalent views from the same definitions, then compare a few results against the Eppo numbers to confirm the logic matches.
Metric and fact table logic in the UI
Metric definitions, filters and aggregation choices are stored as configuration inside Eppo, not as SQL in your repository. Export the SQL Eppo generated for each result table if your plan allows it, or reconstruct each metric from its written definition. Then recreate those metrics as GrowthBook SELECT-based metrics against the same warehouse tables, and confirm the row counts match for one test period.
User roles, permissions and audit history
Who could view, edit or launch experiments, and the log of who changed what and when, belongs to Eppo's access model. Export the user list and role assignments, and save a copy of the audit trail if it is available to your administrators. In GrowthBook, recreate roles and permissions manually, and confirm which advanced permissioning and approval workflow features your self-hosted edition includes, since those sit in the Enterprise tier.
Experiment decisions and write-ups
Results only visible in Eppo often lack the reasoning behind a ship, stop or rerun decision. Write a short record for each completed experiment that states the hypothesis, the primary metric, the decision and who approved it, and attach the final result screenshot. Store these in your document system or repository so the decision history survives the vendor exit, and ask Eppo which results are available as exports.
The order to run a complete Eppo export
This sequence secures everything you need from Eppo before access ends, so your warehouse, your metric logic and your experiment record survive the exit intact. Each step produces an artifact you can check against the one before it.
Confirm the access end date and contract terms
Ask your Eppo account contact, in writing, when read and export access ends, what data Eppo returns or deletes, and whether any export rights or retention periods are defined in your contract. Involve procurement and legal, since they own the answers. Done means you hold a dated written reply that sets the deadline for every later step, and you know which Eppo artifacts you are entitled to keep.
Inventory the warehouse tables Eppo reads
List every assignment log, event table and fact table that Eppo queries in your warehouse, along with the schemas, owners and retention rules for each. Eppo reads data you already own, so this list is the foundation for the rest of the export. Record the table names and column definitions in a schema snapshot, and freeze it so later changes in upstream pipelines are visible. Done means every table that feeds an experiment appears in the inventory with a recorded schema version.
Export flag configuration and metric definitions
While Eppo is still accessible, export feature flag settings, targeting rules, rollout percentages and metric definitions, including the SQL or metric logic behind each one, using whatever export or API method your Eppo plan provides. Confirm the export method with Eppo, because the available formats are the vendor's to specify. Store the files in version control with the date of export. Done means each active flag and each metric has a saved definition that a person on your team can read without Eppo.
Capture each experiment's hypothesis and decision
For every experiment you intend to keep, write down the hypothesis, the primary and guardrail metrics, the audience, the start and end dates, the decision taken and the reason for it. Pull the results summary from Eppo as well, so the narrative and the numbers sit together. Store these records as Markdown or another plain-text format in a versioned repository with an owner for each file. Done means every archived experiment has a complete write-up that a new analyst could follow without access to Eppo.
Archive Eppo output tables
Copy the tables Eppo writes into your warehouse, including experiment results and intermediate tables, into a dedicated archive schema or bucket with a read-only role. Keep the original table names and column definitions in a manifest so they can be interpreted later. Record who ran the copy and when. Done means the archive contains every results and intermediate table listed in your manifest, and the manifest matches the warehouse schema snapshot from the second step.
Verify the archive against the source
Compare row counts and date ranges between each source table and its archived copy, and compare the totals of key columns such as assignment counts per experiment. Investigate any mismatch before access closes, and record the query results in the export log. Done means each table shows matching counts and date ranges, and any exceptions carry a written explanation.
Re-analyze one completed experiment before access closes
Choose one completed experiment and rebuild its results from the archived assignment and event tables using the metric definitions you exported, either in a spreadsheet, a notebook or a trial GrowthBook instance connected to the same warehouse. Compare your figures with the Eppo results you stored. Illustratively, if the effect sizes and confidence intervals agree to the precision Eppo reported, your export is usable for re-analysis; if they differ, trace the difference to a metric definition or a filter before Eppo access ends. Done means you have a signed-off comparison that shows the archive reproduces a real result.
Who owns each piece of data during the exit
Assignment logs, event tables and fact tables are written by pipelines your organization runs, so they stay in your warehouse when Eppo access ends. The work falls to data engineering and analytics engineering. They need to confirm what Eppo reads, what it writes and whether a replacement tool can read the same tables with read-only credentials.
- Assignment logs: confirm which pipeline writes exposure or assignment records, and whether any of that logging depends on an Eppo SDK callback that will be swapped out during the migration.
- Event and fact tables: confirm that the source tables behind each metric are owned by your team and that no transformation exists only inside Eppo's own modeling layer.
- Retention windows: check that stored history covers the analysis periods you need for past experiments, since a replacement will only analyze what the warehouse still holds.
- Credentials: create a dedicated read-only role for the new tool and revoke the Eppo service account once the cut-over is complete.
Before the access date, ask the warehouse owner to list every table Eppo writes to, because any table Eppo owns is a table you cannot assume will remain as it is.
Flag configuration, metric definitions and experiment metadata live in Eppo's application rather than in your warehouse. Someone must request or capture them through an export, an API or a support request before access ends. The experimentation lead and platform engineers usually own this work, and the metric definitions are the part that takes the most care to recreate.
- Flag configuration: capture targeting rules, rollout percentages, default values and the environments each flag belongs to, since these drive what users see on day one of the new system.
- Metric definitions: record the logic behind each metric, including the source table, the aggregation, denominators and attribution windows. Without these, historical results cannot be reproduced.
- Experiment metadata: keep names, hypotheses, owners, start and end dates, variant names and status for every experiment that is live or still referenced.
- Export method and cut-off: confirm in writing which formats Eppo offers, whether bulk export is available, which interface supports it and the exact date access ends.
Send these questions to Eppo early, because a scope agreed without confirmed export formats can leave metric logic missing from the migration plan.
Decisions, rationale and rollout history are the least structured data in an experimentation program, and they often exist only as comments, meeting notes or memory. Product managers, experiment owners and team leads hold this knowledge. If nobody records it before access ends, the new system will show results without the reasoning that justified shipping them.
- Decisions and outcomes: record which variant shipped, the date of the decision, who approved it and whether the team acted on the result or deferred it.
- Rationale and caveats: capture notes on data quality issues, guardrail trade-offs, early stops and any analysis that was excluded and why.
- Rollout history: document when each flag changed percentage, who made each change and any rollbacks, because this history supports incident reviews and audits.
- Comments and review threads: copy the substance of important discussions into a wiki or repository, since threads inside the tool are unlikely to survive in a usable form.
Ask Eppo whether its change history and experiment comments can be exported and in what form, then decide which records your organization will keep in its own knowledge base.
What to plan before the Eppo contract ends
An Eppo exit touches the contract, the vendor's ownership, your warehouse and the people who sign off on data. The six items below are the points to settle in writing before access ends, so the export and the GrowthBook parallel run do not depend on assumptions about dates or ownership.
Notice period and access end date
Read the notice clause and the date on which read access to Eppo stops, and get both confirmed in writing with the vendor. Ask whether exports, saved analyses and experiment histories remain downloadable after the subscription ends, and for how long. Plan the export window backward from that date, not from your renewal reminder.
Who administers the subscription now
Confirm whether your Eppo subscription, invoicing and support contact sit with Eppo or have moved under Datadog after the 2025 acquisition. The administrative owner determines who can approve a data request, who receives the termination notice and which terms apply. Get the named contact and the legal entity written down before you give notice.
Warehouse tables Eppo wrote to
Inventory every table, view and schema Eppo created or populated in your warehouse, including assignment logs, event tables and results tables. Eppo's exit does not remove data you already hold, but it can leave scheduled jobs or permissions behind. Decide which tables GrowthBook will read, which are kept for audit, and which are dropped on a defined date.
Timing against live experiments
Identify every experiment and feature flag that is running or scheduled when the contract ends. Decide whether each one is concluded, moved to GrowthBook, or frozen at its current variant, and confirm how Eppo's assignments behave after access stops. Capturing results before the last analysis run prevents gaps in the experiment history.
Legal and security sign-off on archives
Before any export lands on a laptop, bucket or shared drive, get legal and security to approve where archives are stored, who can read them, how long they are kept and how they are deleted. Exports of flag configuration, metric definitions and experiment write-ups often contain business logic and personal data, so they need the same classification as the warehouse they came from.
Parallel run against the same warehouse
Run GrowthBook against the same warehouse for a defined period before Eppo is switched off, and compare its results with Eppo's for the same experiments. Differences in metric definitions, statistics settings or assignment handling should be explained, not averaged away. Agree the comparison criteria and the sign-off owner before the parallel run starts.
Questions teams ask before exporting from Eppo
How much effort does exporting from Eppo take?
The effort depends on how much Eppo-specific definition work you have, not on the raw data, which usually already sits in your warehouse. The main drivers are the number of experiments you want to carry forward, the number of metrics and their filters, how many flags have targeting rules and prerequisites, and how well your team has documented past decisions. A team with a small set of active flags and a clear metric catalog has far less to rebuild than one with years of undocumented experiments. Ask any partner to inventory these four counts in writing before estimating anything.
What sets the timeline for moving experiment definitions out of Eppo?
The timeline is set by the inventory and by how many live experiments must keep running through the switch. Work that gates the schedule includes confirming warehouse access for the new tool, agreeing metric definitions with analysts, and deciding which in-flight experiments finish on Eppo and which restart in the new platform. Access approvals inside your own organization often take longer than the technical steps. Ask for a written schedule that lists each dependency and who owns it, rather than a single end date.
What does the export need from our team?
Plan for three roles to be named before work starts. A data owner must approve which warehouse tables and schemas the new platform may read, using read-only access. An Eppo administrator must export or document flag configuration, metric definitions and experiment write-ups, since those live in Eppo rather than in your warehouse. An analytics lead must confirm metric logic and statistical settings so that results remain comparable. Each role usually needs a few working sessions rather than full-time effort, but the tasks will stall without a named person for each.
Can our internal team run the export without outside help?
Yes, many teams can, provided they have engineers who can read warehouse schemas, an analyst who understands the metric definitions, and time to document what Eppo holds. The work is mostly careful inventory and rebuilding, not new engineering. Teams most often struggle with the parts that are undocumented: custom metric SQL, targeting logic that lives only in the Eppo interface, and the reasoning behind past decisions. Before deciding, ask whether your team can produce a complete inventory of Eppo objects within the window you have.
What does a fixed-scope engagement with DeployOpen include?
DeployOpen works from a written scope that lists deliverables, timelines and responsibilities before work begins. For an export of this kind, a scope usually covers the inventory of flags, metrics and experiments, connecting a self-hosted GrowthBook instance to your existing warehouse with read-only access, recreating the agreed definitions, updating application code to the new SDK, and documenting the result. It can also cover planning for running experiments in parallel. Ask for each deliverable to be named, along with what your team must provide and what is excluded.
Which costs are one-time and which recur after we leave Eppo?
One-time costs include the inventory, the rebuild of metrics and flags, SDK changes in applications, and the parallel run of experiments. Recurring costs include hosting the self-hosted GrowthBook service and its MongoDB database, warehouse compute for analysis queries, and the staff time to operate and upgrade the platform. GrowthBook's self-hosted Open Source plan is free to license with one project, while the self-hosted Enterprise plan adds features such as SSO, approval workflows and holdouts under a paid agreement. Ask any provider to split its quote into these categories, and ask what ongoing support or retainer work is priced separately.
Should we start the export before renewing Eppo?
Starting the inventory before renewal is usually lower risk, because it tells you how much work remains and whether your current contract terms still fit. The inventory does not change any production system, so it can run while Eppo remains active. Use the results to decide whether to renew, negotiate a shorter term, or set an exit date. Confirm with your Eppo account team what data export and access terms apply at the end of a contract, and write those answers down before the renewal decision.
How DeployOpen scopes and delivers an Eppo exit
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure. For an Eppo exit, we start from what already sits in your warehouse and write down, in a written scope, what must be captured from Eppo before access ends.
How we scope
- Inventory which assignment logs, event tables and fact tables Eppo reads from your warehouse, and confirm their owners and access paths.
- List flag configurations, metric definitions and experiment write-ups that exist only inside Eppo and need export before access ends.
- Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.
How we build
- Connect a self-hosted GrowthBook instance to the same warehouse using read-only queries, and confirm the permissions the connection needs.
- Recreate metric definitions and experiment settings from the captured export, then check results against values already stored in the warehouse.
- Test assignment consistency and metric outputs in a parallel run before any live experiment depends on the new setup.
How we hand over
- Deliver a runbook covering the export format, the mapping from Eppo objects to GrowthBook objects and the known gaps.
- Document the warehouse connection, data source configuration and any metric decisions the team needs to keep for audit or review.
- Walk your engineering and analytics owners through the deployment, backups and upgrade steps so the team can operate the platform.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, scoped in writing.
- Re-verify the warehouse connection and metric outputs when GrowthBook versions change or your warehouse schema is updated.
- Confirm with your compliance owners which evidence they need, since DeployOpen prepares controls and evidence but independent auditors issue any assessment.
