Migrate from LaunchDarkly to Flagsmith

How to migrate from LaunchDarkly to Flagsmith without losing flag state

Teams usually start this work after a renewal, a billing change or a data residency requirement pushes them off LaunchDarkly. The Flagsmith importer moves LaunchDarkly projects, environments and flags into Flagsmith, but the rest of the migration is manual, and the effort depends mostly on how many SDKs your applications use and how complex your targeting rules are. The importer runs from a LaunchDarkly access token entered in Flagsmith's project settings, and each LaunchDarkly project becomes a Flagsmith project. Because the importer overwrites existing environments and flags in the target project, run it into a fresh Flagsmith project so nothing you already maintain is replaced. This is not a criticism of LaunchDarkly. It is a sequencing decision that protects the flag state you already depend on.

Platform or internal tooling engineers usually run the import, with a security owner signing off on the token scope, who can access the Flagsmith project and where the self-hosted instance sits. Plan to review the token's permissions before you start and to revoke it once the import is verified. Risk is moderate and concentrated in the checks after the import: confirm that boolean flags kept their on and off states in each environment, that multivariate variations mapped to the right Flagsmith values, and that archived or deprecated flags came across as archived. Targeting rules, segments and any custom evaluation context need a separate comparison, because the importer does not replace that review. Ask Flagsmith to confirm the current importer behavior for your LaunchDarkly account type before you schedule the work.

Swapping SDKs is the step that changes application code, so treat it as a separate release. You can replace the LaunchDarkly SDK calls directly, or wrap them behind the CNCF OpenFeature API first and switch to a Flagsmith provider later, which lets you move services one at a time. Check that every SDK language your teams use has a Flagsmith SDK or an OpenFeature provider before you commit to a cutover date, and confirm the details in the OpenFeature documentation. Run both systems in parallel for the services that carry the most traffic, and compare evaluated values for the same test users before you turn anything off. Edge caching and the self-hosted deployment model should be settled before cutover, since Flagsmith's Edge Proxy and Redis options affect latency and failure behavior.

Which LaunchDarkly capabilities map cleanly to Flagsmith

This table compares the LaunchDarkly capabilities a team typically relies on with how Flagsmith handles them, using the importer and documented behavior. Read each row as clean, needs rework or gap, and confirm the rows marked for rework against your own flag inventory before cutover. Governance items such as RBAC, SAML and audit logs depend on Flagsmith Enterprise or Scale-Up plans, so check the plan tier before assuming they carry over.

Capability	Flagsmith behavior	Migration status
Boolean flags	The importer keeps the on and off state of each boolean flag in the target environment.	Clean. Verify targeting rules by hand after import.
Multivariate flags	Variations are mapped to Flagsmith multivariate values, so values and weights should be reviewed.	Needs rework. Check each variation and its rollout percentages.
Projects and environments	Each LaunchDarkly project becomes a Flagsmith project and each environment is copied as an environment.	Clean. Import into a fresh project because existing data is overwritten.
Archived and deprecated flags	Archived or deprecated flags are imported as archived in Flagsmith.	Clean. Confirm that archived flags are not still referenced by code.
Segments and targeting rules	Segment and rule logic is not covered by the importer's documented scope, so rules must be recreated and tested.	Needs rework. Rebuild segments and compare evaluation results for sample users.
Server and client SDKs	Flagsmith provides its own SDKs, so every application that calls the LaunchDarkly SDK must change.	Needs rework. Plan SDK swaps or an OpenFeature provider layer per service.
Relay Proxy versus Edge Proxy	Flagsmith offers optional Edge Proxies for lower latency, which play a role similar to LaunchDarkly's Relay Proxy.	Needs rework. Confirm the Edge Proxy design and sizing for your traffic.
RBAC, SAML and audit logs	Role-based access control, SAML single sign-on and governance features such as change requests and audit logs are Enterprise items, and governance starts at the Scale-Up plan.	Gap on the free tier. Confirm plan tier and licensing before cutover.

What the Flagsmith LaunchDarkly importer moves and what you rebuild

The Flagsmith importer covers the flag model itself, so most of the migration effort sits outside it. The cards below separate what the importer copies from the access, integration and identity work that you rebuild by hand before cutover.

Starting the importer with an access token

The import starts when you add a LaunchDarkly access token in Flagsmith's project settings. Use a token scoped to the LaunchDarkly projects you intend to move, and record who created it, because it reads your projects and environments through the LaunchDarkly REST API. Confirm the required token permissions with the Flagsmith documentation and LaunchDarkly's access token settings before you start, since a token with too few rights will produce an incomplete import.

Project and environment mapping

Each LaunchDarkly project becomes a Flagsmith project, and every LaunchDarkly environment is copied as a Flagsmith environment. Build a list of your LaunchDarkly projects and environments before the run, then compare it with the result. Environment names, server-side and client-side keys, and any production approval settings will not carry over in the way your teams expect, so review each environment rather than assuming a one-to-one copy.

Boolean and multivariate flag states

Boolean flags keep their on and off states, and LaunchDarkly multivariate variations map to Flagsmith multivariate values. Archived or deprecated LaunchDarkly flags arrive as archived in Flagsmith. Check a sample of flags in each environment against LaunchDarkly, including default variations and any flag that a code path reads as a string or number, since a changed value type can silently alter application behavior.

Targeting rules and segments to rebuild

Treat targeting as a manual rebuild. Segments, individual target lists and rule logic should be confirmed in Flagsmith before any traffic moves, because the importer documentation tells you to check results by hand. Compare the audience of each rule in both systems with a few test identities, and document rules that depend on LaunchDarkly-specific context attributes so that you can recreate them in Flagsmith's identity traits.

SDK keys and application code

Each application points to a LaunchDarkly SDK key, so every service and client build needs a new Flagsmith environment key and an SDK change. Inventory every SDK key and where it is stored, including secrets managers, Kubernetes secrets and mobile builds. Plan a staged rollout of the new key per service, and keep the LaunchDarkly SDK in place until each service has been verified in Flagsmith.

Webhooks, CI pipelines and identity mapping

Webhooks, CI and CD steps that toggle flags, audit log exports and any Slack or ticketing integrations are not part of the importer and must be recreated against Flagsmith's own APIs and integrations. Identity mapping also needs attention: user keys, anonymous contexts and any attributes that drive percentage rollouts must match, or users may change buckets. Confirm which integrations your team depends on before you schedule cutover.

The migration sequence from inventory to decommission

This sequence moves flags from LaunchDarkly to Flagsmith in controlled stages, so each application switches only after its flags are verified in the new environment. The end state is a Flagsmith deployment in your infrastructure with LaunchDarkly retired and a documented record of each cutover.

Inventory flags, SDK usage and targeting rules
Engineering and the flag owners list every LaunchDarkly project, environment, flag and segment, then record which applications call the LaunchDarkly SDK and which flags each one evaluates. Mark flags that are archived or deprecated, and note any targeting rules that depend on custom context attributes, since those need checking after import. Done when you have a spreadsheet or tracker that maps each application to its flags and each flag to an owner.
Stand up a fresh Flagsmith target
Deploy Flagsmith in your own infrastructure and create a new, empty project to receive the import. The importer overwrites existing environments and flags in the target project, so do not reuse a project that already holds configuration you need. Confirm the deployment's database approach, since the Helm chart creates its own PostgreSQL by default and the docs recommend an externally managed database in production. Done when the target project is empty and the team has confirmed where the data lives.
Run the importer and review the result
Add a LaunchDarkly access token in the Flagsmith project settings to start the import, then compare each imported environment and flag against your inventory. Check that boolean on and off states, multivariate variations and archived flags arrived as expected, and review any targeting rules by hand because the importer does not guarantee an exact match. Done when every flag in the inventory has a matching Flagsmith counterpart and discrepancies are logged with an owner.
Pilot with a few low-risk flags
Choose a small set of flags on one non-critical application, switch that application's SDK to Flagsmith, and confirm evaluations match LaunchDarkly for the same users and environments. Watch for changes in percentage rollouts, since a different evaluation result can move users between variations. Done when the pilot runs in a non-production environment with recorded evaluation results that match the source system.
Run both systems in parallel
Keep LaunchDarkly live as the source of truth while Flagsmith serves the same flags to test traffic, and compare evaluations for the same identities across both. Any flag change made during this period must be made in both systems until cutover, so record a single owner for each flag. Done when mismatches have been resolved and the team agrees the results are consistent across the environments in scope.
Cut over each application
Move applications one at a time: replace the LaunchDarkly SDK calls with the Flagsmith SDK (or an OpenFeature provider if you wrap calls first), deploy, and verify flag evaluations in production. Keep the LaunchDarkly configuration available for a rollback until that application is confirmed stable. Done when each application's logs or dashboards show Flagsmith serving its flags and the owner signs off on the cutover.
Decommission LaunchDarkly
After every application has cut over, disable LaunchDarkly SDK keys, remove the Relay Proxy or other LaunchDarkly components from your environments, and export a final record of projects, flags and audit history for your retention needs. Confirm your LaunchDarkly contract terms and data retention obligations with the vendor before cancelling. Done when no application or pipeline calls LaunchDarkly, the exported records are stored, and the decommission is documented.

Why the import should go into a fresh Flagsmith project

Import into a fresh Flagsmith project, not one that already holds flags your team has built, because the LaunchDarkly importer overwrites existing environments and flags in the target project. The importer copies each LaunchDarkly project into Flagsmith and each LaunchDarkly environment as a Flagsmith environment, so any environment or flag with a matching identity in the target can be replaced without a warning in the import itself. A clean project removes that risk: nothing already in Flagsmith can be silently lost, and any mismatch you find later can be traced to the import rather than to earlier manual work. Before you start, confirm the target project is empty, record the names of any environments and flags it already holds, and agree with the owners of those flags who will re-create them if needed. Check the Flagsmith documentation for the current behavior, since the importer's handling of existing data is the single most important detail to confirm with your own test project first.

Verify the imported state in the Flagsmith dashboard before any application switches over. Open each imported environment and compare its flag list with the LaunchDarkly export, counting flags per environment and confirming that archived or deprecated flags appear as archived. For boolean flags, confirm that the on and off state in each environment matches the source, because the importer keeps those states. For multivariate flags, open each one and confirm that every LaunchDarkly variation has a corresponding Flagsmith multivariate value, with the same default and the same percentage weights where your flags use them. Treat these checks as mandatory rather than optional: the Flagsmith documentation says imported flags should be reviewed by hand afterwards, and targeting rules, segments and any flag that uses custom evaluation logic are the places where differences most often appear. Record each check in a short sign-off sheet so that the cutover decision rests on evidence, not on the import log.

What drives the cost and duration of a Flagsmith migration

This table breaks the cost of moving from LaunchDarkly to Flagsmith into its components, showing who is paid for each, what recurs and what moves the total up or down. Use it to build a written scope before asking for a quote, since the published Flagsmith prices are only one part of the bill.

Cost component	Who is paid or who spends	One-time or recurring	What drives it up or down
Internal engineering time	Your platform and application teams	One-time for the cutover, then recurring for ownership	Number of applications to re-instrument, SDK languages in use and how many flags need manual checks after import
Implementation services	DeployOpen or another partner, under a written fixed scope	One-time	Number of LaunchDarkly projects and environments, use of multivariate flags, and whether OpenFeature wrapping is added before cutover
Hosting and compute	Your cloud account or data center	Recurring	Replica count, Redis and task processor sizing, and whether Edge Proxies are added for latency
Managed PostgreSQL and PgBouncer	Your cloud provider or database team	Recurring	Choice between the default in-cluster database in the Helm chart and an externally managed database, which the docs recommend for production
Flagsmith plan	Flagsmith, per plan (Free at $0, Start-Up at $40 per month billed yearly, Scale-Up at $250 per month billed yearly, Enterprise on custom pricing), per the Flagsmith pricing page	Recurring	Monthly request volume and team member count, plus whether SAML SSO, roles, change requests or audit logs are needed, which start at Scale-Up
Additional API calls on lower tiers	Flagsmith, billed as overage on Free, Start-Up and Scale-Up	Recurring	Request volume above plan limits; the pricing page lists $50 per million additional calls per month, so confirm your traffic before choosing a tier
Enterprise-only features	Flagsmith, through an Enterprise license	Recurring	Need for RBAC, SAML, Okta or OpenShift Operator support; each one may push the decision toward a custom Enterprise quote
Quote checklist	Ask Flagsmith and your implementation partner	Written before work starts	Ask for: project and environment count, flag count by type, SDK inventory, request estimate, hosting model, and named deliverables for validation

How the migration differs by team size and starting point

A single product team with a handful of flags usually has the simplest path. The question is mostly whether the free tier covers its request volume and team size, and whether the team can run one Flagsmith instance with Docker Compose or a single Helm release. The importer copies each LaunchDarkly project and environment, so a small account maps almost one to one.

Plan fit: The Free plan on the Flagsmith pricing page lists 50,000 requests per month and 1 team member, so confirm request volume and seat count against that limit before you rely on it.
Deployment: Docker Compose is the quick start in the self-hosting documentation. It suits a pilot or a low-traffic internal service, but plan a managed database for production.
Import scope: Review archived and deprecated flags before the import, since they arrive as archived in Flagsmith.
Cutover: Replace the LaunchDarkly SDK in one application at a time and check that each boolean on or off state matches what production served.
Costs: Your main recurring costs are hosting and the hours spent checking flags. Ask any vendor or partner to price these separately.

Before cutover, compare evaluated flag values for a sample of users in both systems and confirm that the Flagsmith environment keys match the SDK keys your code expects.

What usually goes wrong and how to prevent it

Most failed LaunchDarkly to Flagsmith imports are not caused by the importer itself but by what teams assume it does. The risks below cluster around the target project, the flags themselves, the SDK wiring and the database under Flagsmith. Each one has a check you can run before cutover.

Importing into a project with data

The Flagsmith importer overwrites existing environments and flags in the target project, so importing into a project that already holds flags can silently replace definitions your services depend on. Create a fresh Flagsmith project for the import and keep any existing project untouched. Before starting, export or note the current flag states of that project so you can compare them after the run.

Unchecked multivariate mappings

Multivariate flag variations map to Flagsmith multivariate values, but the mapping is not a guarantee that each variation keeps its meaning or weight. Compare every multivariate flag's variations, default and rollout percentages in LaunchDarkly against the imported Flagsmith values, in each environment. Treat any mismatch as a blocker for that flag until the owning team confirms the expected value.

Archived flags brought in as archived

Flags marked archived or deprecated in LaunchDarkly are imported as archived in Flagsmith. This is useful for history, but archived flags may still be referenced in code paths that evaluate them. Search repositories for each archived flag key before cutover, remove dead references, and confirm that no service expects an archived flag to return a live value.

SDK keys still pointing at LaunchDarkly

Importing flags does not change the SDK wiring in your applications, so services can keep evaluating against LaunchDarkly after the Flagsmith project is live. Inventory every service that initializes a LaunchDarkly client, including mobile and frontend builds, then replace the client key with the Flagsmith environment key in staging first. Confirm in logs or metrics that each service now reads from Flagsmith before retiring the LaunchDarkly key.

Targeting rules that behave differently

Segments, attribute rules and percentage splits can evaluate differently once they are expressed in Flagsmith's identity and segment model, especially when context attributes are named or typed differently. Build a parity test that evaluates a sample of real user contexts against both systems and records any disagreement. Review rules that depend on attribute types, missing attributes or ordering, because those are the most common sources of drift.

User bucketing shifts in partial rollouts

A partial rollout assigns users to buckets based on the hashing and keys used by the source system. If the Flagsmith identity keys or hashing differ, users already on a feature can move to the other variation at cutover, which breaks consistency for customers mid-experiment or mid-rollout. Confirm which identifier you pass as the Flagsmith identity, test a few known users for the same result, and schedule partial rollouts after the parity test passes.

Default bundled database in production

The Flagsmith Helm chart creates its own PostgreSQL server in the cluster by default, while the documentation recommends an externally managed database in production and offers optional PgBouncer. Running the bundled database in production means your flag store depends on a component you may not back up, patch or monitor the way you do other tier-one data. Provision a managed or externally operated PostgreSQL with backups and restore testing, point the chart at it, and document who owns it.

Swapping SDKs or moving to an OpenFeature provider

The first decision is whether to replace the LaunchDarkly SDK call by call in each application or to put the OpenFeature API in front of it first. A direct swap is shorter for a small number of services, since each application imports the Flagsmith SDK and changes its flag calls to the Flagsmith client. An OpenFeature buffer costs an extra step per service, but it means the application code only knows the OpenFeature client, and the vendor behind it becomes a provider choice. The CNCF project moved to the Incubating maturity level on November 21, 2023, and the OpenFeature introduction describes providers as the translation layer between the evaluation API and the flag system. Pick the buffer when several teams or languages depend on the same flags, or when you want the option to change vendors again without touching business code.

OpenFeature lists server SDKs for C++, Dart, .NET, Go, Java, Node.js, PHP, Python, Ruby and Rust, and client SDKs for Dart, Kotlin, Swift and web frameworks such as React and Angular. Before you commit, check that every language in your estate has a provider that works with the Flagsmith flag types you plan to use, and confirm the provider version against your runtime. Mobile and browser SDKs need separate review, because client-side keys and what they expose are a different risk from server-side keys. Confirm with Flagsmith which environment keys each client will hold, and whether any client should receive flags at all.

Swapping the provider does not carry targeting and bucketing across by itself. LaunchDarkly rules, segments and percentage rollouts are imported as Flagsmith configuration, so each rollout must be checked against the evaluation results for real contexts. Bucketing is the risk to plan for: if the context key or the hashing input differs after cutover, users in a partial rollout can switch variations. Run a sample of identifiers through both systems, record the results, and keep the old SDK in place for a rollback window. Ask your Flagsmith contact and your own platform team to confirm which identity fields each application sends and how Flagsmith derives the segment and percentage split.

Questions buyers ask before migrating from LaunchDarkly to Flagsmith

How much does it cost to move from LaunchDarkly to self-hosted Flagsmith?

The software itself is free to self-host under the BSD 3-Clause license for the majority of the code, so the cost is mostly infrastructure, people and any paid features you need. Infrastructure covers the application, a PostgreSQL database (managed or in-cluster), Redis caching and any Edge Proxies. People cover the migration work, the testing of SDK changes in each application and the ongoing operation of the platform. Recurring cost rises with the number of environments, traffic and high availability requirements. Ask any quote to separate one-time migration work from recurring support, and to list which Enterprise features are included. Current plan details, including Enterprise, are on the Flagsmith pricing page.

How long does a LaunchDarkly to Flagsmith migration take?

No duration is fixed in this guide, and the length depends mainly on the number of projects, environments and flags, how many applications call the LaunchDarkly SDK, and how much cleanup the flags need. The importer itself runs quickly on small accounts, but the review afterwards, SDK replacement and cutover testing take most of the effort. Teams with many services and long-lived release flags will need more time than teams with a few applications. Ask for a written timeline tied to a defined scope, and confirm how many flags and environments were counted in that scope.

What does the migration need from our engineering team?

The work needs a named owner for the Flagsmith instance, engineers who can replace the LaunchDarkly SDK in each application, and someone from product or release management who knows which flags are live and which are stale. You also need a LaunchDarkly access token with enough rights to read projects, environments and flags, and an account owner who can approve the import into a fresh Flagsmith project. Plan time for a side-by-side check of flag states in each environment before any production traffic moves.

Can our own team run the Flagsmith migration without a partner?

Yes, many teams with experience in Docker, Kubernetes and PostgreSQL can run the import and the SDK changes themselves, because Flagsmith publishes self-hosting and Helm documentation. The questions to answer honestly are whether someone can own the upgrades, backups, database sizing and security configuration over time, and whether the team has capacity during cutover. If those are gaps, a fixed-scope engagement can plan, implement, document and hand over the platform, and a retainer can cover ongoing upgrades and support.

Does the Flagsmith LaunchDarkly importer copy everything?

No. The importer copies projects, environments, boolean flags with their on and off states, and multivariate flags, mapped to Flagsmith multivariate values. Archived or deprecated flags come in as archived. It does not replace your targeting rules, segments, approvals, audit history or the way each application calls the SDK, so check those by hand. It also overwrites existing environments and flags in the target project, which is why you should import into a fresh project. Review the Flagsmith LaunchDarkly importer documentation before you start, and compare imported values with LaunchDarkly for every environment.

Do we need Flagsmith Enterprise features for this migration?

Not for the core migration. The self-hosted open-source version has no API request limits, and the importer and flag evaluation work without an Enterprise license. Enterprise features such as role-based access control, SAML single sign-on, Okta integration and certain database integrations are closed source and require a license. The governance features, including roles, permissions, change requests and audit logs, start at the Scale-Up plan on the pricing page. If your LaunchDarkly setup depends on SSO or approval workflows, confirm which of those you need before you choose a design.

How does the Flagsmith license affect internal use?

Flagsmith's code is mostly BSD 3-Clause, which permits internal use, modification and redistribution with the license notice kept intact, while the Enterprise Edition features are closed source and need a commercial license. Internal use of the open-source edition in your own infrastructure does not require a paid plan. Read the Flagsmith FAQ on open source and self-hosting and the license file before you decide, and have your legal team confirm how the Enterprise boundary applies to the features you plan to use.

How DeployOpen scopes, runs and supports the migration

DeployOpen approaches Migrate from LaunchDarkly to Flagsmith as a fixed-scope engagement, with scope, deliverables and timelines agreed in writing before work starts. We plan and implement the self-hosted Flagsmith deployment inside your own infrastructure, then document and support it after handover.

How we scope

Confirm which LaunchDarkly projects and environments are in the import and which belong in a fresh Flagsmith project.
Inventory boolean and multivariate flags, archived flags and the targeting each application relies on before any import runs.
Agree in writing who holds the LaunchDarkly access token, where Flagsmith runs and how cutover is sequenced.

How we build

Deploy Flagsmith in your environment, choosing Docker Compose or Helm with an externally managed PostgreSQL database for production.
Run the built-in importer against a fresh target project, since it overwrites existing environments and flags in that project.
Review each imported flag by hand, then test SDK calls and swap application code to Flagsmith or an OpenFeature provider.

How we hand over

Document the deployment, the import record, the flag-by-flag review results and the SDK changes made in each application.
Walk your platform and engineering teams through running Flagsmith, including upgrades, backups and access roles.
Confirm in writing which Enterprise features you need, such as SAML or RBAC, and which open-source capabilities cover the rest.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover Flagsmith version upgrades, database maintenance and checks on flags that change after cutover.
Ask us to scope the retainer in writing, including response expectations, before the migration closes.