Migrate from Statsig to GrowthBook

Migrate from Statsig to GrowthBook: what moves and what needs rework

Teams usually start this work after a Statsig renewal, after the ownership changes (Statsig agreed to join OpenAI in 2025 and was acquired by Amplitude in 2026), or because a warehouse-native requirement means experiment data must stay in their own data platform. The GrowthBook importer for Statsig can carry over environments, tags, segments, feature gates, dynamic configs and experiments, authenticated with a read-only Console API key, so the flag and experiment definitions do not have to be rebuilt by hand. The part that does not move cleanly is the metrics: metric sources and metrics in the importer are in beta and limited to warehouse-native Statsig metrics, so plan to recreate or verify metric definitions against your warehouse tables. Application code also needs rework, because the SDK calls in your services still point at Statsig.

Platform or experimentation engineers usually run the import, with a product owner for each active experiment deciding what must keep running unchanged. Start by listing which gates and experiments are live, because the importer copies definitions, not your running traffic assignments. Confirm with GrowthBook's Statsig migration guide which object types are covered for your plan, and test the Console API key's read-only scope in a non-production project first. The AI-assisted code migration described in that guide converts gates to boolean flags, dynamic configs to feature values and StatsigUser objects to GrowthBook attributes for JavaScript, TypeScript and client-side React. Other languages go through GrowthBook support, so confirm coverage for each service stack before scheduling it.

The effort is moderate and concentrated in three places: metric re-validation, SDK refactoring across every service that evaluates a gate, and parallel-run checks that flag values match between Statsig and GrowthBook for the same user. The main risks are silent differences in targeting or bucketing, experiments that change assignment mid-run, and metrics that report differently after recreation. Ask your GrowthBook contact to confirm in writing which Statsig objects are in scope, how the beta metric import behaves for your warehouse, and whether self-hosted Enterprise features such as sticky bucketing or holdouts are needed to match your current behavior. Costs are mainly internal engineering time, warehouse compute for experiment queries and any paid GrowthBook plan, so request a quote against a written scope.

Which Statsig capabilities map cleanly to GrowthBook

This table compares the main Statsig objects and capabilities with their GrowthBook equivalents and marks each as clean, needs rework or gap. Read it as a planning checklist: anything marked needs rework or gap should be confirmed in a test workspace before you set a cutover date.

Statsig capability	GrowthBook equivalent and fit	Status and notes
Feature gates	Boolean feature flags, imported through the Console API importer	Clean for simple on/off gates. Confirm how each gate's rules and rollout percentages arrive in the preview before relying on them.
Dynamic configs	Feature flags with JSON feature values	Needs rework. Check that each config's value types and nested structure survive the import and that application code reads them in the new shape.
StatsigUser objects	GrowthBook attributes passed in the evaluation context	Needs rework. Attribute names and types must be mapped by hand in the SDK calls. The AI-assisted code migration covers JavaScript, TypeScript and client-side React only, so other languages need manual edits or help from GrowthBook support.
Environments and tags	Environments and tags in the GrowthBook project	Clean. Confirm environment names and tag structure in the preview, since they are imported as named objects.
Segments	Targeting rules and saved attribute conditions	Needs rework. Review each segment's logic, because complex nested conditions may need to be rebuilt as targeting rules.
Experiments	GrowthBook experiments with their own analysis	Needs rework. Statistical settings and results history may not match Statsig. Re-verify metric definitions before trusting historical comparisons.
Warehouse-native metrics	Metrics queried against your own warehouse with read-only SELECT statements	Needs rework. Metric sources and metrics are in beta and limited to warehouse-native Statsig metrics. Build and validate metrics in GrowthBook for anything the beta does not carry over.
SSO and SCIM	Enterprise tier on self-hosted GrowthBook	Gap on the free Open Source plan. Requires the self-hosted Enterprise license, and the cost should be confirmed against the pricing page.
Approvals, advanced permissions and holdouts	Self-hosted Enterprise features	Gap on the free Open Source plan. Confirm which of these your change process depends on before planning the migration.
Console API access	Read-only Console API key used by the importer	Clean for import. Use a read-only key and confirm it still returns all projects you need, since the importer does not write back to Statsig.

What the Statsig importer brings over and what you rebuild

GrowthBook's Statsig importer covers the configuration objects in your Statsig project, but it does not move everything that surrounds them. Metrics depend on a warehouse connection, and the code, pipelines and alerts that read from Statsig stay with your team to rewire. Confirm each object type in a test import before the migration scope is agreed.

Environments, tags and segments

The importer retrieves environments, tags and segments from Statsig using a Console API key. Environments determine how flags are scoped across development, staging and production, so check that your environment names map cleanly onto the ones you plan to use in GrowthBook. Segments often hold targeting logic that several gates depend on, so confirm that each segment reproduces the audience you expect in a test import. Tags need to be checked for naming consistency, since they become the basis for grouping and filtering flags after the move.

Feature gates as boolean flags

Statsig feature gates are converted into GrowthBook boolean flags, and their targeting rules and rollout percentages are carried across as part of the import. Gates with complex conditions, nested rules or dependencies on other gates deserve a manual review, because a rule that evaluates correctly in Statsig can behave differently in the new system. Compare evaluation results for a sample of users in both systems before you switch any production traffic. Also confirm which gate owners will review the imported rules.

Dynamic configs as feature values

Statsig dynamic configs are mapped to GrowthBook feature values, which carry JSON-style payloads that your application reads at runtime. Check the schema of each config, because type changes, renamed keys or nested objects can break consumers that expect the original shape. Keep a record of which services read which configs, since the importer does not map those dependencies. Plan a verification step for each config that feeds pricing, limits or user-facing copy.

Experiments and beta metrics

Experiments are imported with their structure, but metric sources and metrics are in beta and limited to warehouse-native Statsig metrics. If your experiments rely on metrics defined outside a connected warehouse, those definitions will need to be recreated in GrowthBook against your own data source. Confirm with GrowthBook which metric types the beta covers before scope is agreed, and make sure a warehouse connection is in place to run the analysis. Historical results may not reproduce exactly, so record the final Statsig readouts before the move.

CI, alerting and data pipelines

The importer does not rebuild the integrations around Statsig. Check the code paths that call Statsig in CI pipelines, feature flag audit hooks, Slack or PagerDuty alerts, and event pipelines that forward exposure or metric events. Each of these needs a manual rewire to GrowthBook SDK calls or to your own data flow. Inventory these dependencies early, because they usually determine the cutover order more than the flags themselves.

SDK refactoring and access control

Application code still calls the Statsig SDK after the import, so each call site must be refactored to the GrowthBook SDK, which an AI-assisted migration path in the guide can help with for JavaScript, TypeScript and client-side React. Languages outside that list go through GrowthBook support. Review how user attributes change from StatsigUser objects to GrowthBook attributes, and confirm who in your organization holds the API keys and roles needed for the cutover.

Migration sequence from inventory to decommission

This sequence moves Statsig workloads to self-hosted GrowthBook in controlled stages, so each flag and experiment is verified before any production traffic depends on it. It ends with Statsig decommissioned only after the contract and data retention review is closed.

Inventory gates, configs, experiments and SDK call sites
Engineering and the experimentation owner list every feature gate, dynamic config, experiment, segment and tag in Statsig, then search the codebase for Statsig SDK calls and record which service, language and client surface (server or browser) each one lives in. Mark which gates are still live, which experiments are running, and which are stale. The output is a spreadsheet that maps each Statsig object to the services that read it and an owner for each. The step is done when every SDK call site is assigned to a service and a pilot candidate is chosen.
Import a scoped set into a test instance
A platform engineer stands up a non-production GrowthBook instance, typically from the Docker image or the official Helm chart, and runs the documented Statsig importer with a read-only Console API key. Import only the environments, tags, segments, gates, dynamic configs and experiments listed in the inventory, not the whole project. Treat the metric import as separate work: metric sources and metrics are in beta and limited to warehouse-native Statsig metrics, so confirm with your data team whether a connected warehouse covers the metrics you need. The output is an import log plus a side-by-side list of imported objects against the inventory. Remove the key from the import tool once the import is finished.
Review imported flags and targeting rules
The experimentation owner and an engineer compare each imported gate and dynamic config with its Statsig original, checking default values, targeting conditions, rollout percentages and segment membership. Note that the importer maps gates to boolean flags, dynamic configs to feature values and StatsigUser objects to GrowthBook attributes, so attribute names and condition logic need a manual check. Confirm that the GrowthBook API key used by services is scoped to the test environment. The step is done when each object is signed off or has a logged defect with an owner.
Refactor SDK calls and run a pilot on one service
Engineers replace the Statsig SDK calls in one low-risk service with the GrowthBook SDK, using the AI-assisted migration guide where it fits the language (JavaScript, TypeScript and client-side React are covered directly, other languages go through GrowthBook support). Wire the service to a GrowthBook instance connected to the test data source, then exercise the flags in staging with real requests. Record every behavior change in a defect log. The pilot is done when the service runs in production with its flags served by GrowthBook and no open severity-one issues remain.
Run a parallel comparison of evaluations
For a defined window agreed in advance, the pilot service keeps both SDKs in place and logs the variant each system returns for the same user and attributes. Compare the two outputs per flag and per experiment assignment, and investigate every mismatch. Differences in attribute mapping, hashing for sticky bucketing or rollout rounding are the usual causes, so check them against the Statsig and GrowthBook documentation before changing rules. The output is a mismatch report with root causes and a written decision to proceed or fix and repeat.
Cut over service by service
Each remaining service moves through the same refactor, test and comparison steps, and the team switches its production traffic to GrowthBook only after its comparison report is signed off. Keep a rollback path to the Statsig SDK for each service until its experiments have concluded. Track which services are on which system in a shared register so no call site is missed. The step is done when the register shows every inventoried call site on GrowthBook and the rollback path is retired per service.
Decommission Statsig after contract and retention review
Legal, procurement and the data owner review the Statsig contract for notice periods, termination terms and data return or deletion obligations, and confirm the export of any analytics data that must be kept outside the vendor. Ask Statsig in writing for the deletion or return process and the timing for your account. Once no service calls Statsig and the review is closed, remove the SDK packages and API keys, revoke the Console API key, and record the decommission date. The output is a signed decommission record and an evidence pack for the compliance team.

How to run Statsig and GrowthBook in parallel without split decisions

During an overlap, assign each flag to exactly one system of record and write that decision down before the first import runs. Statsig and GrowthBook can both hold a flag with the same key, and an application that reads from both will eventually see two answers for one user. Pick a single owner per flag: Statsig keeps gates and dynamic configs until a flag is cut over, and GrowthBook takes over only after its imported copy has been checked against the Statsig original. Keep a simple register with the flag key, owner, cutover date and rollback path. The importer copies objects at a point in time, so any change made in Statsig after the import will not appear in GrowthBook unless someone re-imports or edits both places. Confirm in your own environment whether your change process blocks edits to a flag that is in migration.

Before you trust GrowthBook for a user population, compare assignments for the same identifiers in both SDKs. Choose a test cohort of internal accounts, run the Statsig and GrowthBook evaluation paths side by side in a non-production environment, and log the variant each returns for each user, along with the attributes sent. Differences usually come from attribute mapping, since Statsig's StatsigUser fields must be translated into GrowthBook attributes, and from targeting rules or rollout percentages that hash users differently. Treat any mismatch as a blocker until you understand it. Confirm the hashing and bucketing behavior of both systems in their documentation and in your own tests rather than assuming they agree.

Experiments already running in Statsig need a deliberate handover. Decide per experiment whether it finishes in Statsig, restarts in GrowthBook with a new start date, or is paused while the variant assignment is frozen. Mixing both is the usual source of double-counted exposures: the same user is logged as exposed by Statsig's analytics pipeline and again by a GrowthBook tracking callback. Keep one exposure logger per experiment, and confirm which event your warehouse receives for each, since GrowthBook analyzes results from the warehouse using aggregated statistics. Ask your data team to check exposure counts for a sample window in both systems before any decision is made from them.

What drives migration cost and duration

This table lists the main factors that change the effort of moving from Statsig to self-hosted GrowthBook, with what keeps each one down and what to ask for in a written quote. Read it as a checklist for scoping, since the largest swings usually come from SDK call sites, metric readiness and the people who run the platform rather than from the importer itself.

Driver	Why it changes effort	How to keep it down and what to ask for
Feature gates and dynamic configs	Each gate becomes a boolean flag and each dynamic config becomes a feature value, so object count and targeting complexity set review time.	Export a full inventory through the Console API first and retire stale gates. Ask the quote to state the object count it assumes and how it handles rules with no direct equivalent.
SDK call sites by language	JavaScript, TypeScript and client-side React are covered by GrowthBook's AI-assisted code migration. Other languages go through GrowthBook support, which adds scope.	Count call sites per language and repository before scoping. Ask whether non-JavaScript services are in the quote and how support-led conversion is scheduled and reviewed.
Experiments and metric definitions	Experiments import, but metric sources and metrics are in beta and limited to warehouse-native Statsig metrics, so metric rebuilding can dominate the work.	List active experiments and the metrics each one uses. Ask the quote to separate metric rebuilding from the object import and to name which metrics will be recreated by hand.
Warehouse readiness	GrowthBook analyzes experiments with SELECT queries against your own warehouse, so the event tables, identity keys and access grants must exist before metrics work.	Confirm the target warehouse (for example Snowflake or BigQuery), read-only credentials and how events map to users. Ask who owns the query access model and how it is tested.
MongoDB or compatible database	GrowthBook stores metadata in MongoDB or a compatible database. The docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production.	Decide early between a managed service and a self-run database. Ask the quote whether backup, restore testing, upgrades and sizing are in scope, and who pays the database service.
Helm or Docker operations	GrowthBook ships as a single Docker image and has an official Helm chart for Kubernetes. Ingress, TLS, file storage on local, S3 or Google Cloud Storage, and upgrades all add work.	Choose one deployment path and state it in the scope. Ask for the environments covered (staging and production), the upgrade procedure and how releases such as v5.1.0 are tested before rollout.
SSO, permissions and approval workflows	Self-hosted Enterprise adds SSO and SCIM, advanced permissioning and approval workflows that the free Open Source plan does not include, which changes both configuration and license cost.	Decide early whether these features are required. Ask the quote to list which Enterprise features are configured and whether the license cost is included or quoted separately.
Internal staffing	Someone must own the platform, the SDK rollout, flag hygiene and experiment analysis after go-live. Internal time is usually the largest recurring cost and is easy to miss.	Name the internal owner and their weekly allocation during migration. Ask whether the quote includes knowledge transfer, runbooks and a post-cutover support window.

What usually goes wrong and how to prevent it

Most failed Statsig-to-GrowthBook moves do not fail in the importer. They fail in the gaps around it: setups the importer does not cover, application code that still calls Statsig, experiments with no metrics, flags that drift during parallel runs, and operations nobody owns. Each card below names one of these risks and the step that prevents it.

Unsupported advanced setups

GrowthBook's importer documentation warns that advanced setups may include scenarios it cannot handle. Statsig accounts with many projects, custom gate logic or unusual experiment configurations are the most likely to fall outside the import. Before you run anything, export a full inventory of gates, dynamic configs, segments and experiments and mark each item as imported, rebuilt by hand or retired. Ask GrowthBook support to confirm coverage for your specific setup.

Forgetting the SDK switch

Importing flags does not change application code. The GrowthBook documentation for its LaunchDarkly importer states that the application still has to switch from the vendor SDK to a GrowthBook SDK after the import, and the same applies to Statsig calls such as gate checks and dynamic config reads. Keep a search list of every Statsig SDK call in each repository and track its replacement as a separate task, since the AI-assisted code migration covers JavaScript, TypeScript and client-side React only.

Beta metric gaps

The metric source and metric import is in beta and limited to warehouse-native Statsig metrics. Experiments that depend on metrics defined outside that scope will arrive without the metrics they need, which makes results unreadable even when the experiment itself imports correctly. Map each active experiment to its primary and guardrail metrics, confirm which ones the importer carries over, and define the rest in GrowthBook against your warehouse before you rely on any result.

Flag drift during parallel runs

A parallel run keeps Statsig and GrowthBook live at the same time, and any flag changed in one system but not the other produces two different user experiences. This is most likely when product teams keep editing in Statsig during the transition. Freeze flag changes in Statsig for each migrated flag, or designate one system of record per flag and log every change with an owner and a date. Compare evaluations for a sample of users in both systems before you cut over each flag.

Lost analytics history

Statsig's analytics data is not part of the GrowthBook import, and history that never reached your warehouse will not appear in GrowthBook experiment analysis. Teams often assume the export carried over results from past experiments. Confirm which event data already lands in your warehouse and whether it covers the windows your historical experiments need. Archive Statsig experiment results you still need for audit or reference before the subscription ends.

Self-hosted operations gaps

Self-hosting GrowthBook moves the operating work to your team: the Docker image or Helm chart, the metadata database (MongoDB or a compatible database), file storage, upgrades and backups. The self-hosted Open Source plan is free but limited to 1 project, while SSO, SCIM, approval workflows and holdouts require the self-hosted Enterprise plan. Assign an owner for upgrades and database backups, and confirm which Enterprise features you need before the cutover, since changing plan later affects the rollout schedule.

How the migration differs by starting point

If Statsig is mainly a home for feature gates and dynamic configs, the migration is largely a flag-state and code-path exercise. The importer retrieves environments, tags, segments, feature gates and dynamic configs with a read-only Console API key, so most of the inventory moves without manual re-entry. The work that remains sits in the application, where Statsig SDK calls must be replaced and the rollout logic checked.

Environment mapping: confirm which Statsig environments map to GrowthBook environments before importing, so production targeting is not mixed with staging.
Gate-to-boolean conversion: feature gates become boolean flags, so review any gate that was used with more than a yes or no decision.
Dynamic configs: these map to feature values, which need a typed check in each consumer.
SDK refactoring: the guide's AI-assisted code migration covers JavaScript, TypeScript and client-side React, while other languages go through GrowthBook support.
Experiment scope: if no experiments run, you can skip the metric work entirely.

Before cutover, ask GrowthBook support to confirm coverage for any language your services use outside JavaScript, TypeScript and React.

Questions buyers ask before moving from Statsig to GrowthBook

What does a Statsig to GrowthBook migration cost?

The cost depends on how many gates, dynamic configs, experiments, segments and SDK call sites you have, and on whether you pay for GrowthBook Enterprise or run the free Open Source plan. The GrowthBook pricing page lists the self-hosted Open Source plan as free with unlimited users, 1 project and unlimited API requests, while self-hosted Enterprise adds SSO and SCIM, approval workflows and other features. Your one-time costs are the import, code refactoring and testing. Recurring costs are infrastructure, the MongoDB or compatible database, warehouse compute for experiment queries and the people who operate it. Ask any partner for a fixed-scope quote built from an inventory of your Statsig objects and SDK call sites.

How long does a Statsig to GrowthBook migration take?

The duration is driven by scope rather than by the importer alone. The Statsig importer retrieves environments, tags, segments, feature gates, dynamic configs and experiments with a Console API key, so object transfer is usually the short step. The longer work is refactoring application code, running parallel checks, validating targeting and rollout behavior, and migrating metrics if you need them. No researched duration is available for this work, so confirm the timeline against your own inventory of projects, SDK languages and environments before committing to a date.

What does the internal team need to provide?

Plan for a few inputs from your own staff before any work starts:

A Statsig Console API key with read-only access, issued from an account your organization controls.
A list of the SDK languages and applications that call Statsig, including client-side React or TypeScript code.
Access to the GrowthBook environment you will run, plus a database such as MongoDB or a compatible service for its metadata.
Access to your data warehouse if experiment analysis or metric migration is in scope, with read-only query permissions.
Named owners who can approve flag behavior, rollout rules and experiment definitions.

Can we run the Statsig to GrowthBook migration ourselves?

Yes, a team with experience in its own codebase and a clear inventory can do it in-house. GrowthBook documents the Statsig importer and an AI-assisted code migration guide that converts feature gates to boolean flags, dynamic configs to feature values and StatsigUser objects to GrowthBook attributes, covering JavaScript, TypeScript and client-side React. Other languages go through GrowthBook support. The risks lie in edge cases the tooling does not catch, such as custom targeting, sticky bucketing differences and experiment logic tied to Statsig events. Bringing in an implementation partner is most useful when those edge cases are numerous or when the team lacks time to run parallel validation.

Does the Statsig importer migrate metrics too?

Only partially. GrowthBook's documentation describes metric sources and metrics as beta and limited to warehouse-native Statsig metrics. Metric import therefore depends on your Statsig setup, and it needs a connected warehouse on the GrowthBook side to run the analysis. Metrics defined in Statsig's own event pipeline will not carry over in the same way. Before you start, list every metric your experiments rely on, check whether each one is warehouse-native, and plan to recreate the rest in GrowthBook against your own data source.

Does GrowthBook Open Source include the features we use in Statsig?

Check this feature by feature before you commit. The self-hosted Open Source plan includes flags and experiments within its limits, but the GrowthBook pricing page places SSO and SCIM, advanced permissioning, approval workflows, multi-armed bandits, safe rollouts, ramp schedules, sticky bucketing and holdouts in the self-hosted Enterprise tier. If your Statsig use depends on any of these, budget for Enterprise or redesign the workflow. Compare your current feature list with the published plan details and confirm each item with GrowthBook before the migration plan is final.

How does GrowthBook's enterprise license affect us?

GrowthBook's LICENSE file states that code outside its enterprise directories is MIT Expat licensed, while the directories packages/back-end/src/enterprise, packages/front-end/enterprise and packages/shared/src/enterprise fall under the GrowthBook Enterprise License. In practice, you can self-host and modify the MIT-licensed core under MIT terms. Any Enterprise features you use, such as SSO or approval workflows, are covered by the Enterprise License. Have your legal team review the license text, especially if you plan to modify or redistribute code from the enterprise directories.

Do we need to replace the Statsig SDK after the import?

Yes. Importing objects does not change how your application calls flags. GrowthBook's documentation for its LaunchDarkly importer makes the same point: the application must switch from the vendor SDK to a GrowthBook SDK after the import, and that applies equally to Statsig. Plan the SDK swap as code work across every service and client, and test feature evaluation, fallback values and experiment exposure logging in each environment before you remove the Statsig calls.

How DeployOpen scopes and runs the migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Statsig to GrowthBook, we agree the scope in writing first, then work through the importer, the SDK refactor and the metric decisions with your engineering and data teams.

How we scope

We inventory which Statsig gates, dynamic configs, segments and experiments are live, and which ones are still used in code.
We confirm whether your metrics are warehouse-native, since the importer's metric support is in beta and limited to that case.
The written scope names the GrowthBook edition, hosting model, data sources and the SDK languages covered before work starts.

How we build

We stand up a self-hosted GrowthBook instance, using the Docker image or the official Helm chart, in your environment.
We run the Statsig importer with a read-only Console API key and review each imported object before anything goes live.
We refactor SDK calls, mapping StatsigUser attributes to GrowthBook attributes, and test flag evaluation against the expected behavior.

How we hand over

We document the deployment, configuration, key management and the mapping from each Statsig object to its GrowthBook equivalent.
We provide a parallel-run and cutover checklist so your team can verify results before retiring Statsig calls.
We walk your engineers through running GrowthBook day to day, including user access, environments and backups.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope migration closes.
Retainers can cover version upgrades, such as moving to a newer GrowthBook release, with changes tested before rollout.
Ask any provider, including us, to confirm in writing which GrowthBook edition, feature set and support terms your scope relies on.

Migrate from Statsig to GrowthBook