Statsig after the Amplitude acquisition: stay or replace

Statsig after Amplitude: should you stay or replace it?

The documented facts do not force a move off Statsig, but they justify checking your contract and preparing an exit. Statsig announced on September 2, 2025 that it would join OpenAI, and a note on its blog states that Amplitude acquired Statsig on May 5, 2026. If you face a renewal after two ownership changes, the decision turns on two things: the terms in your current agreement and where your experiment data physically sits. This page covers self-hosted GrowthBook as the option to evaluate, and only your contract review and your data map can settle whether moving makes sense for you.

Start by reading the agreement for change-of-control and assignment language, subprocessor lists, hosting regions and data processing terms, since these determine whether the new owner can change where or how your data is handled. Ask the vendor in writing whether any hosting location, subprocessor or support model is changing after the acquisition. Check renewal pricing and termination rights, and confirm how you would export flags, experiments and event data at the end of the term. Also confirm your tier: the Statsig pricing page places warehouse native deployment in the Enterprise plan, so if your analysis depends on data staying in your warehouse, that tier is the one your contract must cover.

If the review points toward an exit, plan it in stages rather than as a single cutover. Inventory every gate, experiment and metric your applications depend on, then run GrowthBook alongside Statsig for a trial period in a non-production environment. The self-hosted deployment ships as a single Docker image with a Helm chart for Kubernetes, and it needs a MongoDB-compatible database for metadata, so your platform team must budget for hosting, backups and upgrades. GrowthBook's self-hosting documentation describes the setup. Before you commit, weigh the free Open Source plan against paid Enterprise features such as SSO, SCIM and approval workflows, and count the engineering time to run it.

What to check in your Statsig contract before renewal

Statsig's ownership has changed twice in a short period, so the contract you signed may not describe the company you are buying from today. Each item below is a question to put in writing to Statsig or Amplitude before you renew, so the answers can be compared against your own data, cost and exit requirements.

Contracting entity after the acquisition

Ask which legal entity is party to your agreement now, whether the agreement was assigned to a new owner, and which entity will invoice and support you from renewal. Confirm whether the order form, terms of service and data processing addendum name the same entity. Ask for written confirmation of any change to the governing law or notice address, since these determine who you can hold to commitments.

Data processing and residency terms

Ask where event data, experiment assignments and exposure logs are stored, which sub-processors receive them, and whether any of that changed after the acquisition. Request the current data processing addendum and check whether it still matches the regions and sub-processors in your own compliance records. Ask whether Statsig will notify you in writing before such changes take effect.

Pricing unit and renewal terms

Statsig bills on analytics events, so your bill depends on traffic, not seats or flags. Ask how events are counted, what happens when your volume rises during the term, whether overage rates are fixed in the contract, and whether the price can change at renewal. Ask for a projection of your next-year bill using your last twelve months of event volume, in writing.

Change of control and termination rights

Ask whether your contract allows you to terminate or pause if control of Statsig changes again, and whether any notice period or early termination fee applies. Confirm whether a product roadmap change, sunset or feature removal gives you a right to exit without penalty. Clarify how prepaid, unused commitments are refunded or credited on termination.

Export rights for flags, experiments and events

Ask which objects you can export at the end of the term: gates, dynamic configs, experiments, segments and raw event data. Confirm the export format, the time window available, whether exports are included in your plan, and whether there is a deletion commitment after you export. Statsig's Console API is one route, so ask for any export limits that apply to it.

Support and service level commitments

Ask which support tiers are included at your plan level, what response times are committed in writing, and whether any uptime commitment applies to the SDK evaluation path or only to the dashboard. Ask whether support staff and escalation contacts have changed since the acquisition and how that affects your current account owner.

Decision paths: stay, stay with a warehouse plan, or replace

This path fits teams whose contract already sets the terms they need, especially those running warehouse native on Statsig Enterprise, where event data stays in their own warehouse. Staying is a reasonable choice when the ownership change does not affect the features you rely on and the vendor will commit to them in writing. The Amplitude acquisition was dated May 5, 2026 in a note on Statsig's blog, and the earlier agreement to join OpenAI was announced on September 2, 2025, so ask for current terms rather than assuming earlier ones still apply.

Change of control clause: Confirm what happens to your agreement, data processing terms and pricing if ownership changes again.
Written product commitments: Ask for named commitments on the gates, experiments and warehouse native features your teams use.
Data location: Confirm where event data is stored and which parts stay in your warehouse under your Enterprise plan.
Renewal terms: Check the renewal date, notice period, price protection and any right to terminate early.
Support and SDK continuity: Ask how SDK updates, security fixes and support escalation will be handled after the change.

Before you sign anything new, have your legal and procurement teams read the current order form against the points above, and confirm each commitment in writing with Statsig or Amplitude.

How GrowthBook, Unleash and Flagsmith compare for a Statsig exit

This table compares the three self-hosted open-source candidates on the capabilities a Statsig team usually needs when it leaves: experiments, warehouse analysis, license terms, free self-hosted limits and migration help. Read each row against your own list of must-have features, since the cheapest option on paper may not cover your experiment workflow. GrowthBook is the only one of the three that runs experiments against your warehouse, so teams that rely on Statsig's analysis should weigh that row first.

Criterion	GrowthBook	Unleash	Flagsmith
Experimentation and analysis	Built-in experiment analysis with statistical engine and metrics	Feature flags and rollouts; experiment analysis is not the core product	Feature flags and remote config; experimentation is not the core product
Warehouse-native analysis	Runs read-only SELECT queries against your warehouse and returns only aggregates	Not offered in this group	Not offered in this group
License	MIT outside enterprise directories; those directories fall under the GrowthBook Enterprise License	AGPLv3 from v8.0.0; earlier releases were Apache 2.0	BSD 3-Clause core with closed-source Enterprise features
Free self-hosted limits	Open Source plan: 1 project, unlimited users, unlimited API requests	Open Source: 1 project and 2 environments	No API request limits in the open-source version; confirm other limits with the vendor
Statsig SSO and RBAC equivalent	Self-hosted Enterprise adds SSO, SCIM, advanced permissioning and approval workflows	Confirm SSO and role controls in the edition you plan to run	Confirm SSO and role controls against the Enterprise features you need
Migration support from LaunchDarkly	Built-in importer via LaunchDarkly REST API; the SDK still has to change	Scripted migration guide published by Unleash	Built-in LaunchDarkly importer via REST API token
Migration support from Statsig	Documented Statsig importer with a Console API key; metric import is beta and needs a connected warehouse	Confirm with the vendor whether a Statsig importer exists	Confirm with the vendor whether a Statsig importer exists

How to plan a Statsig exit to self-hosted GrowthBook

This sequence turns a Statsig exit into a checked migration path: it inventories what you run, moves configuration with the GrowthBook importer, rewires SDK calls, validates results in parallel and retires Statsig only after the cutover is proven.

Inventory gates, configs, experiments and SDK call sites
Engineering and product owners list every feature gate, dynamic config, experiment, segment and tag in each Statsig project and environment. In parallel, the platform team searches the codebase and CI pipelines for Statsig SDK calls, including server and client libraries, and records which services depend on each object. Mark objects that are stale, unowned or used only in one environment, since these need a decision before anything moves. The step is done when every object has an owner, a status and a list of call sites, and you can say which services break if a given gate is removed.
Export configuration through the Console API
The platform administrator creates a read-only Statsig Console API key scoped to the projects in scope and stores it in your secrets manager, not in a repository. Scripted exports pull gates, dynamic configs, experiments and segments as JSON so you hold a copy outside the vendor. Check the API documentation for the version and per-project rate limits before you script large pulls. The step is done when the exported files are stored under version control or an approved archive, and someone other than the exporter has checked that object counts match the inventory.
Run the GrowthBook Statsig importer in a preview
A GrowthBook administrator runs the Statsig importer with a Console API key in a non-production GrowthBook instance. The importer retrieves environments, tags, segments, feature gates, dynamic configs and experiments. Metric sources and metrics are in beta and are limited to warehouse-native Statsig metrics, so plan metric definitions separately if your metrics are not warehouse native. Review each imported item against the export and the inventory, and log every gap. The step is done when the preview matches the inventory, and each gap has a recorded decision: rebuild, drop or handle manually.
Connect the warehouse and rebuild metrics
The data team connects GrowthBook to the warehouse that holds your experiment events, such as Snowflake, BigQuery or another supported source. GrowthBook runs only SELECT queries and receives aggregated statistics, so the team should confirm that the database role has read access only. Metric definitions that did not import as beta items are rewritten and tested against known experiment results. The step is done when a sample metric returns the same values as the source analysis for a past experiment, and the database role has been reviewed by the people who own the warehouse.
Refactor SDK calls to the GrowthBook SDK
The importer does not switch your application code. Service owners replace each Statsig SDK call found in the inventory with a GrowthBook SDK call, or with an OpenFeature provider if you want the evaluation API to stay independent of one vendor. Changes go through code review and the same test suite as other releases, with each flag name mapped in a shared table. The importer documentation warns that advanced setups may include scenarios it cannot handle, so review these by hand. The step is done when no production service imports the Statsig SDK and every mapped flag has a passing test.
Validate both systems in parallel
For a defined period agreed by the product and engineering leads, the application evaluates flags in both Statsig and GrowthBook and logs any difference in result. Analysts compare experiment outputs from the two tools against the same warehouse data. Investigate every mismatch before it is accepted, including differences in targeting, rollout percentages and sticky bucketing. The step is done when the mismatch log is empty or every remaining difference has a documented and approved explanation, signed off by both engineering and the experiment owners.
Cut over and retire Statsig
Teams switch production traffic to GrowthBook one service at a time, starting with low-risk flags, and keep a tested rollback path for each step. After the last service moves, the team removes the Statsig SDK from dependencies, revokes the Console API key, and confirms that exported archives and retention obligations are met under your contract. Confirm with the vendor how data is handled at termination. The step is done when no production traffic reaches Statsig, the key is revoked, and the change record is filed with the contract owner.

What you own after leaving Statsig

Moving from a hosted Statsig account to self-hosted GrowthBook moves several operational duties to your team. The cards below cover the components you will run, the access you will grant, and the decisions to settle before you commit to an exit.

Hosting and upgrades

GrowthBook ships its Next.js front end, Express API and Python statistics engine in a single Docker image, and the latest release in the supplied facts is v5.1.0, released September 22, 2026. Your team owns the image pins, the upgrade schedule, the staging test before each upgrade, and the rollback plan if an upgrade breaks flag evaluation. Ask DeployOpen or your platform team to define who approves upgrades and how quickly security fixes reach production.

MongoDB metadata store

GrowthBook stores its metadata in MongoDB or a compatible database. The self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. You now own backups, point-in-time recovery, patching, access control and capacity planning for the database that holds your flag definitions and experiment configuration. Confirm the recovery time and recovery point objectives your organization needs before you pick managed or self-run.

Warehouse credentials and query permissions

GrowthBook analyzes experiments by running only SELECT queries against your own data source and sends back only aggregated statistics. You become the owner of the read-only database roles, the network paths to Snowflake, BigQuery or another supported source, and the review of which schemas those roles can read. Confirm that the role cannot write, that credentials rotate under your secrets policy, and that query cost lands in a budget someone monitors.

SSO and advanced permissioning

Self-hosted Enterprise adds SSO and SCIM, advanced permissioning and approval workflows, which the free self-hosted Open Source plan does not include. If your Statsig contract relies on SSO and role-based controls today, plan for a paid self-hosted Enterprise seat count and a configured identity provider from day one. Map each Statsig role to a GrowthBook permission set and confirm that approval workflows match your change control rules before cutover.

SDK refactoring in your applications

An importer can carry flags, experiments and segments across, but your application code still calls the Statsig SDK. The LaunchDarkly importer documentation states that the application must switch to a GrowthBook SDK after import, and the same applies to Statsig. Your engineers own the code changes, regression tests for each flag evaluation path, and a dual-run period where both systems agree on assignments before the old SDK is removed.

Importer gaps and manual reconciliation

The Statsig importer retrieves environments, tags, segments, feature gates, dynamic configs and experiments with a Console API key, but metric sources and metrics are in beta and limited to warehouse-native Statsig metrics. Advanced setups may include cases the importer cannot handle. Your team owns the inventory of what did not transfer, the manual rebuild of those items, and sign-off that each carried-over experiment still matches its original definition.

Questions buyers ask before changing Statsig vendors

Does the Amplitude acquisition force us to move off Statsig?

No. Nothing in the supplied sources says existing Statsig contracts end on the acquisition, so the answer depends on your agreement. Statsig announced on September 2, 2025 that it would join OpenAI, and a Statsig blog note states that Amplitude acquired Statsig on May 5, 2026. Read your order form and master agreement for change-of-control, assignment, renewal and termination clauses, and ask Statsig in writing what changes for your plan, support, data processing terms and sub-processors. Treat the acquisition as a reason to review the contract, not as proof that a move is required.

What does a migration to self-hosted GrowthBook cost, and what drives it?

The cost comes from several components, and only some of them are one-time. Internal engineering time covers SDK refactoring, testing and cutover. Warehouse compute covers the SELECT queries GrowthBook runs against your data source for experiment analysis, which recurs with experiment volume. Hosting covers the Docker or Kubernetes deployment, the MongoDB or compatible database, and backups. GrowthBook Open Source is free for self-hosting with 1 project and unlimited users, while Enterprise adds SSO and SCIM, approval workflows and other features, billed per the GrowthBook pricing page. Ask any quote to separate one-time migration work from recurring hosting, seat and compute costs. DeployOpen does not publish prices; a quote follows from a written scope.

How long does an exit from Statsig take?

The duration depends on how many gates, dynamic configs, experiments, segments and metrics you run, how many SDK call sites your applications contain, and whether you need warehouse-native metrics. GrowthBook's Statsig importer reads environments, tags, segments, feature gates, dynamic configs and experiments with a Console API key, while metric import is in beta and limited to warehouse-native Statsig metrics. Those beta limits can extend the plan. Your team should inventory the Statsig objects and SDK usage first, then agree a timeline in the written scope. No duration is stated here because none is supplied for this migration.

What do we need to provide during the migration?

Expect to provide access and decisions, not only code. You need a read-only Statsig Console API key, a named owner for each product area, access to the application repositories that call the Statsig SDKs, and the warehouse connection that GrowthBook will query (for example Snowflake, BigQuery or Postgres). Your security team should approve the Console key scope, the network path to the database and the hosting account. Product and data owners must confirm which experiments are still live, which metrics are the official definitions, and which stakeholders sign off on results.

Can our engineers migrate from Statsig to GrowthBook without outside help?

Often yes for a small estate, but the importer does not remove the application work. GrowthBook's importer documentation for LaunchDarkly warns that advanced setups may include scenarios it cannot handle, and the same caution applies to exports from other vendors. After the import, each application must switch from the Statsig SDK to a GrowthBook SDK, and the team must verify flag evaluation, targeting and experiment assignment in every environment. Teams with a stable warehouse, a clear flag inventory and spare engineering capacity can often run this internally. Teams with many services, strict change control or regulated data may prefer a fixed-scope engagement.

What should we ask for in a fixed-scope quote for this work?

Ask for a written scope that lists each deliverable, the Statsig objects in and out of scope, the applications and SDK call sites covered, the data sources and metric definitions, the test and cutover approach, and the handover documentation. Request that the quote separate one-time work (inventory, import, refactoring, validation, runbooks) from recurring items (retainers for upgrades, support and testing). Ask what happens if the importer cannot handle a configuration, who owns the beta metric limitations, and which costs your own cloud, warehouse or licensing accounts will carry. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or certifications.

Should we replace Statsig or wait and watch the product roadmap?

Decide on your own requirements, using the contract review as the first step. If your data residency, warehouse-native experimentation or licensing needs are already unmet, planning an exit may be justified regardless of ownership. If Statsig meets them and the contract protects your renewal terms, you can document the exit plan and keep it current without moving yet. GrowthBook's self-hosted Open Source edition is MIT licensed outside its enterprise directories, which you should review with your legal team before relying on any Enterprise features. Set a review date tied to your renewal so the decision is not made under deadline pressure.

How DeployOpen plans a Statsig exit inside your environment

DeployOpen scopes a Statsig exit in writing before any work starts, and the scope begins with inputs from your side: the current Statsig contract and order forms, the data processing terms, and the documented location of your event and experiment data. Those documents determine what must be exported, what must be deleted on exit, and which decisions belong to your legal and procurement teams. The written scope then names the deliverables, the environments in which work happens, and the acceptance criteria for each phase. Engagements are fixed-scope, so the agreed deliverables and timelines are fixed in advance, and any change to them goes through a written change request.

The technical plan starts with an inventory of every gate, dynamic config, experiment, segment, environment and tag in use, along with every application that calls the Statsig SDK. DeployOpen then runs the GrowthBook Statsig importer with a read-only Console API key inside a non-production GrowthBook instance that you host, reviews what arrived, and reconciles it against the inventory. The inventory also drives the SDK refactoring plan, which maps each Statsig call to its GrowthBook equivalent and orders the changes by risk. Metric import remains in beta and depends on a connected warehouse, so the plan records which metrics need to be rebuilt by hand. Warehouse connection, hardening (access control, backups, upgrades) and documentation are delivered in your own cloud accounts or data centers, and the runbooks are handed over for your team to operate.

DeployOpen prepares the controls and evidence that your compliance team and independent auditors may need, but DeployOpen does not issue audit reports, attestations or certifications, and it cannot state that the resulting environment meets any framework. Ongoing support, upgrades and continuous testing after cutover are available as a retainer and are priced separately from the fixed-scope exit. Ask for the written scope to list who operates the GrowthBook instance after handover, which warehouse credentials are used and who owns them, and how rollback to Statsig would work if your contract still runs during the transition.