Migrate from LaunchDarkly to GrowthBook

Migrate from LaunchDarkly to GrowthBook: what the move involves

Moving from LaunchDarkly to GrowthBook is an import plus an SDK replacement, and the manual work is real. The importer copies projects, environments and flags into a preview and then imports the pending items, but it does not finish the job. Plan for a review of every flag, a rebuild of anything the importer cannot handle, and a code change in each application that reads flags today. GrowthBook's own importer documentation warns that advanced setups may include scenarios it cannot handle, and that the application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK after the import.

Platform or application teams usually run the migration, with a security or data owner who signs off on where the new metadata database and any experiment data source live. The effort depends mostly on three things: how many flags are live, how complex the targeting rules and prerequisites are, and whether experiments are in scope. A release-flag-only account is a smaller job than one that also moves experiment definitions and metrics into GrowthBook's warehouse-native analysis, because metrics must be re-pointed at your own data source with read-only SELECT access. Ask whether the importer will be re-run during cutover, since re-importing creates new revisions that must be reconciled with changes made in the meantime.

Ask the team that will do the work to produce a flag-by-flag inventory before committing to a date: which flags are stale, which use segments or custom attributes, which depend on prerequisites, and which are read by services you do not own. Confirm the access token scope with your LaunchDarkly administrator and check API rate limits on large accounts in GrowthBook's migration guide. Any quote should separate one-time work (inventory, import review, SDK changes, testing, cutover) from recurring work (hosting, upgrades, backups and on-call), and should name who is paid for each.

Which LaunchDarkly capabilities map cleanly to GrowthBook

This table compares the main LaunchDarkly objects and capabilities with their GrowthBook equivalents and marks each as clean, needs rework or gap. Use it to scope the migration before running the importer, since the importer's coverage is a starting point rather than a guarantee. Most flag definitions carry over, but experiments, metrics and governance features depend on your GrowthBook tier and data warehouse setup.

Capability	GrowthBook equivalent	Status	What to check
Flags and fallback values	Feature flags with default values per environment	Clean	Confirm the importer carried each fallback value and compare a sample of flags in the preview
Environments	Environments within the single self-hosted project	Needs rework	Open Source allows 1 project, so map LaunchDarkly projects to GrowthBook environments or tags before import
Targeting rules	Feature rules with conditions and attributes	Needs rework	Recreate custom attributes used in LaunchDarkly rules and confirm the importer aims to carry the rule logic
Percentage rollouts	Rollout rules with hashing attributes	Needs rework	Check which attribute drives bucketing, since changing it re-buckets users in partial rollouts
Prerequisites	Prerequisite-style dependencies between features	Needs rework	Test flag dependency chains in a staging environment before cutover
Segments	Attribute-based conditions or saved groups	Needs rework	Rebuild segments as explicit conditions and verify membership on sample users
Experiments and metrics	Warehouse-native experiments with metrics from your data source	Needs rework	Metrics must be defined against your warehouse, and LaunchDarkly experiment history will not migrate as live results
Approvals	Approval workflows in self-hosted Enterprise	Gap	Not included in the free self-hosted Open Source plan, so confirm the tier or a process outside the tool
SSO and SCIM	SSO and SCIM in self-hosted Enterprise	Gap	Requires a paid Enterprise plan per GrowthBook pricing, so plan identity setup before go-live

What to move, what to export and what to rebuild

The GrowthBook importer moves a defined set of LaunchDarkly objects, and everything else stays with your teams. Use the cards below to split the work into what the importer fetches, what you must export yourself, and what you rebuild in each application and pipeline.

Access token and REST API export

The GrowthBook importer authenticates to the LaunchDarkly REST API with an access token and reads projects, environments and feature flags from it. Create the token with the narrowest role that can read those objects, and record who owns it and when it expires. Confirm that the token can see every project in scope, since projects it cannot read will not appear in the preview.

Projects, environments and flags

These are the objects the importer fetches into a preview before anything is written. The docs aim to carry over fallback values, targeting rules, rollouts and prerequisites, so compare each flag in the preview against its LaunchDarkly definition. Treat the preview as the first review gate and not as proof that every flag behaves the same way.

Advanced setups outside importer scope

GrowthBook's documentation warns that advanced setups may include scenarios the importer cannot handle. Inventory unusual constructs before the first import, such as custom rule logic, flags that depend on external state, and multi-project patterns. Record each one in a table with an owner and a decision (rebuild, accept or retire), so nothing is discovered in production.

SDK calls in each application

The application still has to switch from the LaunchDarkly SDK to a GrowthBook SDK after the import, so the import does not change any running code. List every service and client that calls the LaunchDarkly SDK, including mobile and server runtimes. Plan the swap per service, and consider wrapping calls behind OpenFeature first if several languages are involved.

Webhooks, CI pipelines and automation

Flag changes often trigger outside systems, such as Slack notifications, deployment gates or scripts that toggle flags in CI. None of these are carried over by the flag import, so each one must be recreated against GrowthBook's API or events. Test each pipeline in a staging environment before cutover, and remove LaunchDarkly tokens from CI secrets once the old path is retired.

Data sources and metric definitions

Experiments in GrowthBook run against your own warehouse through read-only SELECT queries, so the data source connections and metric definitions must be built again in GrowthBook. Map each LaunchDarkly experiment metric to a SQL definition and confirm the event tables it reads. Ask your data team to verify the queries against a known period before any decision relies on them.

How to sequence the migration from inventory to decommission

The sequence moves LaunchDarkly flags into self-hosted GrowthBook in controlled stages, so each application switches only after its flags have been verified and its SDK calls run behind one wrapper. The end state is a documented cutover record and a LaunchDarkly account that can be closed without losing data you are obliged to keep.

Inventory flags, environments and experiments
Platform owners export a list of projects, environments, flags, segments and running experiments from LaunchDarkly, using a read-only access token with the REST API. For each flag, record its type, its owning application, its prerequisites, whether it is stale, and whether it drives a live experiment. Mark flags that the importer may not handle, such as complex prerequisite chains or unusual targeting. The output is a signed-off inventory that names every application that calls LaunchDarkly, which becomes the scope for every later step.
Run a pilot on self-hosted GrowthBook
Deploy a self-hosted GrowthBook instance in your own infrastructure, using the official Helm chart if you run Kubernetes, and connect it to a managed MongoDB-compatible database. Run the LaunchDarkly importer in its two steps: first fetch and preview, then review the pending items, and only then import them. Import into a fresh project so existing GrowthBook data is not affected. The output is a preview report, reviewed by the flag owners, that lists what was carried over and what needs manual rebuilding.
Verify imported flags against LaunchDarkly
For each pilot flag, compare fallback values, targeting rules, rollouts and prerequisites in GrowthBook with the LaunchDarkly original. Rebuild anything the importer documents as unsupported or incomplete. If you re-run the importer later, expect it to create new revisions, so record which revision each approved flag is on. The output is a parity checklist per flag, signed by the owning team, and a list of re-run rules agreed before cutover.
Wrap SDK calls and run both systems in parallel
Place a single flag-evaluation wrapper inside each application, ideally built on the OpenFeature API with a provider for each vendor, so that code calls one interface. Keep LaunchDarkly as the active provider while GrowthBook runs in shadow mode for selected flags, and compare evaluations for the same users. Investigate every mismatch in targeting or bucketing before moving on. The output is a mismatch log that is empty for the agreed set of flags, or each open mismatch has an accepted explanation.
Cut over each application separately
Switch one application at a time from the LaunchDarkly provider to the GrowthBook provider in a change request approved by the owning team. Confirm that user-facing behavior and experiment assignments are unchanged, and keep a tested rollback path to the previous provider until the change has run cleanly. Repeat for each application in the inventory order agreed in step one. The output is a cutover record per application with the date, the approver, the flags affected and the rollback test result.
Export retained data before decommissioning
Before you cancel or stop using LaunchDarkly, export the definitions, audit history and experiment results your records policy or regulator requires, and confirm with legal and compliance which retention periods apply. Store the exports in your own controlled storage and check that they can be read. Confirm with LaunchDarkly what happens to your data after the subscription ends, since the vendor documentation governs that. The output is a retention checklist signed by compliance and a verified archive.
Decommission LaunchDarkly and remove its SDKs
Once every application runs on the GrowthBook provider and the retention checks pass, revoke LaunchDarkly access tokens, remove the LaunchDarkly SDK dependency from each codebase, and disable any Relay Proxy or webhook integrations. Close the subscription only after the vendor has confirmed the terms for the final billing period. The output is a decommission record showing revoked credentials, removed dependencies and the final archive location, which the security team keeps with the change history.

How the work differs for flag-only teams and experiment-heavy teams

Teams that mainly use LaunchDarkly to turn features on and off, roll out gradually and kill-switch risky code have the simplest path. GrowthBook can hold these flags, but its strongest parts are experimentation and statistics, so the value you get from it is smaller if you never run experiments. Before choosing GrowthBook for flags alone, compare it with the sibling pages on Unleash and Flagsmith, which focus on release management.

Flag inventory: Most of the work is reviewing which flags are still live, which are stale and which the importer should carry over. Ask for an export of flag status and last-evaluated dates before you start.
Targeting rules: Simple attribute rules and percentage rollouts usually map cleanly. Confirm that each rule, prerequisite and fallback value in the preview matches what production evaluates today.
Feature-only paid tiers: If you do not need experiments, you may never need the paid features, but you still need to decide whether SSO, approvals and advanced permissioning are required for your governance model.
SDK replacement: Every application that calls the LaunchDarkly SDK still has to change to a GrowthBook SDK, which is the same work whatever the flag count.

Before cutover, check that a sample of flags returns identical values from both systems for the same user contexts.

What drives cost and duration in a LaunchDarkly to GrowthBook move

The cost of moving from LaunchDarkly to self-hosted GrowthBook is split between infrastructure, paid seats, warehouse access and engineering time. Most of the effort sits in the application code and in checking what the importer did not carry over, so the flag inventory and SDK count matter as much as the platform price.

Metadata database and hosting

GrowthBook stores its metadata in MongoDB or a compatible database, and its docs suggest a managed service such as MongoDB Atlas or AWS DocumentDB for production. Your cost here is the database hosting, backups and the people who patch and monitor it, and it recurs every month. Ask the implementation team which database tier and backup retention they assume, and whether the database sits in your own cloud account or a managed service you pay for separately.

Deployment image and Helm chart

GrowthBook bundles its Next.js front end, Express API and Python statistics engine in one Docker image and maintains an official Helm chart for Kubernetes. Deployment is a one-time setup cost plus ongoing upgrades, so the work depends on whether you already run Kubernetes and how your change process handles upgrades. Confirm who owns the image build, storage for uploads (local, Amazon S3 or Google Cloud Storage), and the upgrade cadence before you agree on scope.

Paid seats for enterprise controls

The free self-hosted Open Source plan includes unlimited users but only 1 project. SSO and SCIM, advanced permissioning, approval workflows, sticky bucketing and holdouts sit in the self-hosted Enterprise tier, so a regulated team needing SSO or approvals should price that tier. Ask whether the quote is per seat or custom, and which features the Enterprise tier covers in your deployment.

Warehouse connection and query load

GrowthBook analyzes experiments in your own warehouse, running only SELECT queries and transmitting aggregated statistics. Costs come from the warehouse compute used by those queries, which rises with experiment count, metric count and data volume, and from the engineering time to set up each data source. Ask which warehouse you will connect, who grants the read-only role, and how the team will limit query cost.

Application SDK replacement

The importer does not switch your code. Each application must move from the LaunchDarkly SDK to a GrowthBook SDK, so effort scales with the number of services, languages and places where flags are evaluated. Count the services that call LaunchDarkly, note any client-side and server-side usage, and plan a test pass per application before cutover.

Flag inventory and migration checks

Import effort rises with flag count, targeting complexity, prerequisites and experiment history. The importer aims to carry over fallback values, targeting rules, rollouts and prerequisites, but its docs warn that advanced setups may include cases it cannot handle, so each complex flag needs a manual review. Ask the implementer to list flags with multi-step rules or prerequisites, how they will handle re-imports that create new revisions, and how rate limits on large LaunchDarkly accounts affect the timeline.

How GrowthBook's importer behaves on re-runs and large accounts

The LaunchDarkly importer in GrowthBook works in two steps, and the first step is the one to lean on. Running the fetch produces a preview of the projects, environments and feature flags it found through the LaunchDarkly REST API, using an access token you supply. Nothing is written to GrowthBook at that point. Review the preview against your LaunchDarkly console before you import pending items, paying attention to fallback values, targeting rules, percentage rollouts and prerequisites, since those are the parts the importer is documented to aim at carrying over. The importer then writes pending items at about one second per flag, so a very large account will take a noticeable amount of wall-clock time for the import itself. Ask your team to count flags per environment in the preview and plan the window accordingly, and confirm the current pace and any API rate limits on your LaunchDarkly plan with the vendors before a production run.

Re-runs deserve a deliberate decision. Each import that writes flags creates new revisions in GrowthBook, so running the importer again against a LaunchDarkly account that has changed will add revisions rather than leave the earlier state untouched. Decide in advance whether the second run is a refresh for verification or a real change, and record which flag keys and revisions the team reviewed. Freeze changes in LaunchDarkly during the verification window if you can, because a flag edited after the preview will not match what was reviewed. Treat the warning in the importer documentation seriously: advanced setups may include scenarios the importer cannot handle, and the application still has to move from the LaunchDarkly SDK to a GrowthBook SDK after the import. Before any application switches, compare evaluated values for a sample of users in both systems in a non-production environment and confirm the flags that use prerequisites, segments or multiple variations behave as they do in LaunchDarkly.

Verification is what protects a cutover, so give it an owner and a written checklist. Compare each environment's flag count and key names, sample targeting results for known test contexts, and rollout percentages for flags that are partially released. Check whether any flag fell outside what the importer handled and rebuild it by hand. Keep the LaunchDarkly environment live until the application teams confirm parity, because it is the reference for any discrepancy. Plan for the self-hosted side as well: the GrowthBook instance that receives the import needs to be sized and backed up before the import starts, and the team running it should know how to roll back a bad revision. Confirm the exact import behavior and limits with the current GrowthBook documentation for your version, since the importer and the release you deploy may have changed since this page was written.

Questions buyers ask before they migrate from LaunchDarkly to GrowthBook

How long does a LaunchDarkly to GrowthBook migration take?

The duration depends on how many projects, environments, flags and SDK integrations you have, and on how many of them use setups the importer cannot represent. The importer itself is quick per item, since GrowthBook's documentation describes importing pending flags at about one second per flag, but the surrounding work dominates: reviewing the preview, checking targeting rules by hand, rewriting SDK calls in each application, and testing rollouts. Ask DeployOpen or any implementation partner for a timeline built from a written inventory of your flags and applications, not from flag counts alone.

What does a GrowthBook migration cost, and which parts recur?

Costs fall into three groups. The one-time items are the migration work itself, SDK replacement in each application, and testing. The recurring items are the infrastructure to run GrowthBook (compute, a MongoDB or compatible database, storage and backups), your team's time to operate upgrades, and any paid tier you choose. Self-hosted Open Source is free with unlimited users and one project, while the self-hosted Enterprise tier adds features such as SSO and SCIM, approval workflows and holdouts, so the licensing choice moves the recurring cost more than the software does. Ask for a quote that separates these lines.

Can our own team do this migration without outside help?

A team with experience running services on Kubernetes or Docker, comfort with MongoDB and a working knowledge of its SDKs can often handle the importer and the self-hosted deployment. The harder parts are the advanced setups the importer may not handle, the parallel run, and the cutover across many services. Teams with few applications and simple targeting often manage it internally. Teams with many services, strict change windows or compliance evidence needs often bring in outside help for scoped pieces, such as the deployment, the SDK work or the test plan.

What does engineering and data ownership look like during the migration?

Engineering owns the SDK replacement in each application, the flag evaluation logic and the rollout plan for each service. Platform or operations owns the GrowthBook deployment, its database, backups and upgrades. If you plan to run experiments, a data owner must confirm which warehouse tables hold the events, grant GrowthBook read-only SELECT access and agree on metric definitions. Product and analytics owners must sign off on how experiments map to the new system. Naming these owners before work starts prevents most delays.

Do experiments and historical results move to GrowthBook?

Flags and their targeting are the part the importer is designed to carry over, so do not assume historical experiment results come with them. Experiment results live in LaunchDarkly's analysis and in your event store, and GrowthBook analyzes data from your own warehouse using its configured metrics. Treat past results as records to export and keep, and confirm with the GrowthBook documentation and a test import exactly which experiment objects, if any, your account produces. Plan metric definitions in GrowthBook before you rely on new results for decisions.

Does the LaunchDarkly importer handle everything in our account?

No. GrowthBook's documentation says that advanced setups may include scenarios the importer cannot handle, and that it aims to carry over fallback values, targeting rules, rollouts and prerequisites. Review the preview before importing, because pending items are the place to catch gaps. Check custom attributes, segments, multivariate flags, prerequisites and any flags with complex rule ordering by hand. The application must also switch from the LaunchDarkly SDK to a GrowthBook SDK, which the importer does not do for you.

What does GrowthBook's license allow for internal use?

The LICENSE file in GrowthBook's repository states that code outside its enterprise directories is MIT Expat licensed, while those enterprise directories fall under the GrowthBook Enterprise License. Running the open-source code for internal use is therefore permitted under MIT outside those directories. Anything you need from the enterprise directories, such as the paid features, requires the Enterprise license. Have your legal or procurement team read the LICENSE file for the exact version you deploy, since terms in future releases can change.

What the GrowthBook license and self-hosting model mean for your team

The license split is the first thing your legal and procurement teams need to read. 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, the self-hosted Open Source plan runs on the MIT-licensed core, and features such as SSO and SCIM, advanced permissioning, approval workflows and holdouts sit behind the enterprise code and a paid license. Have counsel map each feature your migration depends on to one side of that line, and read the GrowthBook license file directly rather than relying on a summary.

The deployment unit is a single Docker image that bundles the Next.js front end, the Express API and the Python statistics engine. Metadata is stored in MongoDB or a compatible database, and the self-hosting documentation suggests a managed service such as MongoDB Atlas or AWS DocumentDB for production. Your platform team should decide early whether to run that database themselves, since backups, point-in-time recovery, patching and access control for it become your responsibility. The official Helm chart covers Kubernetes installs, and file uploads can go to local storage, Amazon S3 or Google Cloud Storage. Choose the storage backend before go-live, because moving uploaded files later is extra work.

Pin the exact version you deploy and record it in your change ticket. This page uses GrowthBook v5.1.0, released on September 22, 2026, as an example, but confirm the version you actually install against the GrowthBook releases page, read its changelog, and check that your Helm chart values or image tag match it. Upgrades will be your job unless you hold a support retainer, so agree on who reviews release notes, who tests a new image in staging and how a rollback works. Repeat that check at each upgrade, because license and feature boundaries can change between releases.

How DeployOpen scopes and runs a LaunchDarkly to GrowthBook migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this migration, we start with a written inventory of your LaunchDarkly projects, environments and flags, then agree on what moves to GrowthBook and what stays with you to decide.

How we scope

Inventory LaunchDarkly projects, environments, flags, segments and prerequisites before any import is attempted
Agree in writing which flags migrate, which are retired and which need manual rebuilding in GrowthBook
Confirm the LaunchDarkly REST API access token policy, the hosting target and the data source used for experiment analysis
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts

How we build

Deploy self-hosted GrowthBook in your environment, using the official Helm chart or Docker image with MongoDB or a compatible database
Run the two-step importer against a non-production copy, reviewing the preview before importing pending flags
Check fallback values, targeting rules, rollouts and prerequisites by hand, since the importer warns about unsupported setups
Replace LaunchDarkly SDK calls in each application with GrowthBook SDKs or an OpenFeature provider, tested per service

How we hand over

Document the import runbook, re-import behavior, environment mapping and the flag-by-flag exception list
Provide a cutover checklist covering SDK switches, flag ownership and rollback steps for each application
Record the configuration, backup and upgrade procedures for the GrowthBook deployment in your own runbooks
Hand over admin access and knowledge transfer so your team can operate the platform after acceptance

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover
Track new GrowthBook releases and plan upgrades in your change windows, with licensing review for enterprise features
Confirm with GrowthBook which paid tier features, such as SSO, approvals or holdouts, your rollout depends on
Plan periodic testing of the flag platform and its access controls as part of the retainer scope

Migrate from LaunchDarkly to GrowthBook