Migrate from LaunchDarkly with OpenFeature as a buffer

Why decouple from LaunchDarkly with OpenFeature before you migrate

Wrapping LaunchDarkly calls behind the OpenFeature API lets you change the flag system by changing a provider, but targeting rules, segments and user bucketing still need deliberate work. Picture a team whose LaunchDarkly SDK calls appear in dozens of services, with a renewal approaching and a data residency review underway. Every service that imports the LaunchDarkly SDK directly is a service that must change when the flag system changes. Moving evaluation calls to the OpenFeature API first turns that migration into a provider swap plus a verification exercise, rather than a rewrite of every call site.

Platform engineers usually own this wrapping work because they can add a shared OpenFeature client layer, provider configuration and a common evaluation context once. Application engineers then adopt it service by service, starting with the services that carry the most flags. OpenFeature is a Cloud Native Computing Foundation project, accepted on June 17, 2022 and moved to the Incubating maturity level on November 21, 2023, according to the CNCF OpenFeature project page. The effort is moderate and the risk sits mainly in evaluation behavior: check that the OpenFeature provider for LaunchDarkly returns the same values as the SDK it replaces for the same user context.

Plan for what the wrapper does not carry. Activation rules, segments, percentage rollouts and the hashing used for user bucketing live in the flag system, so a provider change can move a user from one variant to another if the bucketing key or the context fields differ. Before cutover, confirm with your team which context attributes drive each rollout, then reproduce those rules in the target system and compare assignments for a sample of users. Ask the provider maintainers and the target vendor to document how their bucketing works, and treat any mismatch as a planned exception rather than a surprise.

Which LaunchDarkly capabilities move cleanly behind OpenFeature

This table maps the LaunchDarkly capabilities that applications reach through the SDK to their Unleash, Flagsmith and GrowthBook equivalents. Each cell is marked clean, needs rework or gap. OpenFeature covers evaluation calls only, so flag management such as creating flags, approvals and audit trails stays in the target platform and must be planned separately.

Capability	Unleash	Flagsmith	GrowthBook
Boolean flag evaluation	Clean: on and off toggles evaluate through the Unleash OpenFeature provider	Clean: on and off states carry over in the LaunchDarkly importer	Clean: boolean evaluation works through the GrowthBook provider; confirm the provider version
Multivariate flags	Needs rework: LaunchDarkly variations become strategy variants; recheck each one	Needs rework: variations map to multivariate values; check each one by hand	Needs rework: verify variations after import and confirm return types in code
Targeting rules	Needs rework: rules map to activation strategies; rebuild and test each rule	Needs rework: the importer copies rules and overwrites the target project, so verify	Needs rework: the importer aims to carry over targeting; verify each rule before cutover
Segments and context attributes	Needs rework: segments export as references and must exist before import	Confirm: check how segments and attributes import in your setup	Confirm: check segment and attribute mapping in the importer preview
Prerequisites	Needs rework: LaunchDarkly prerequisites map to flag dependencies	Confirm: test prerequisite logic after import with known user cases	Needs rework: the importer aims to carry over prerequisites; verify each one
Relay Proxy and edge caching	Needs rework: Unleash Edge replaces the Relay Proxy; OSS Edge ends December 31, 2026	Needs rework: optional Edge Proxy for lower latency; size it in your design	Gap: confirm how SDKs fetch flags at scale before choosing a proxy design
Server and client SDK languages	Needs rework: confirm an Unleash provider exists for each language before starting	Needs rework: confirm a Flagsmith provider exists for each language and framework	Needs rework: confirm a GrowthBook provider exists for each language and framework
Client-side evaluation	Needs rework: browser and mobile keys and provider setup differ; test each app	Needs rework: client-side flags need a client key; confirm per environment	Needs rework: client SDK keys and payloads change; retest front-end flags
Flag management and governance	Gap: OpenFeature does not create, approve or audit flags; use Unleash admin tools	Gap: OpenFeature does not manage flags; RBAC and SAML need the Enterprise edition	Gap: OpenFeature does not manage flags; approval workflows need the Enterprise edition

How the OpenFeature buffer works in application code

The OpenFeature buffer works because application code calls one evaluation API and never calls a flag vendor's SDK directly. Your code asks for a boolean, string, number or object value by flag key and evaluation context, and a *provider* decides where that answer comes from. During the LaunchDarkly phase, the provider is the LaunchDarkly provider. At cutover, you register the Unleash, Flagsmith or GrowthBook provider instead, and the calls in your services stay the same. The provider is the translation layer, so the vendor-specific work sits in one place per runtime rather than in every feature branch.

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 including React and Angular. Confirm two things for each service before you commit to this design. First, that the OpenFeature SDK for your language and runtime version is maintained, and that the provider you plan to use for Unleash, Flagsmith or GrowthBook supports that same language and runtime. Provider coverage is not guaranteed to match SDK coverage, so check the provider entry for each target system in the OpenFeature ecosystem provider list. Second, whether any service evaluates flags in a browser or mobile client, because client-side providers carry different context and key-exposure considerations than server providers.

Be clear about what the buffer does not hide. Targeting rules, evaluation context fields, segments and user bucketing still differ between LaunchDarkly and the target system, so an OpenFeature wrapper can keep a call compiling while the answer changes for some users. Treat the wrapper as a seam for parallel running and staged cutover, and plan the rule and bucketing checks separately. Ask your team to list every service that calls the LaunchDarkly SDK directly, including scripts and background jobs, because any call that bypasses the abstraction layer will not switch with the provider.

What to export from LaunchDarkly and what to rebuild

Moving off LaunchDarkly splits into two jobs: copying flag definitions out and rebuilding the pieces that do not copy cleanly. The cards below cover the documented export paths, the items you must recreate by hand in the target system, and the Edge end-of-life date that affects the Relay Proxy replacement.

Flag and environment definitions via REST API

LaunchDarkly exposes flag, segment, environment and project definitions through its REST API, authenticated with an access token. Export them as JSON before any import, so you keep a dated copy of the source state. Check that archived and deprecated flags are included in your export, because they are easy to lose. Use a token with the narrowest read scope that works, and revoke it once the export is complete.

Built-in importers in Flagsmith and GrowthBook

Flagsmith and GrowthBook both ship LaunchDarkly importers that read projects, environments and flags through the REST API with an access token. Flagsmith overwrites existing environments and flags in the target project, so import into a fresh project. GrowthBook fetches into a preview first, which lets you review items before committing. Neither importer replaces the manual review of targeting and fallback values.

Recreate context fields and segments first

Targeting rules reference context attributes and segments, and Unleash imports segments and custom strategies only as references. Recreate the context fields your rules depend on, then the segments, before importing or recreating flags. Otherwise imported flags point at segments that do not exist yet. Confirm that each attribute keeps the same name and type, because a renamed attribute silently changes who matches a rule.

Relay Proxy replacement with Unleash Edge

The LaunchDarkly Relay Proxy serves flags inside your network, and Unleash Edge is the documented counterpart for that role. Open-source Edge reaches end of life on December 31, 2026, so any design that depends on it needs a dated plan, whether that is an Enterprise plan or another caching layer. Confirm the Edge version and its support status with Unleash before you size the deployment.

SDK changes in application code

Importers move flag definitions, but they do not change your application. Each service still calls the LaunchDarkly SDK until a developer swaps it for the target SDK or an OpenFeature provider. Inventory every service, client and language that calls LaunchDarkly, including mobile and front-end code, before you schedule cutover. This inventory is the list that determines how much code changes at cutover.

Historical data is a separate export

Flag definitions and evaluation history are different things. The REST API exports what flags and segments look like now, not the evaluation or custom events that LaunchDarkly recorded over time. Evaluation and custom event export runs through the Data Export add-on, which is a separate contract with its own setup. Ask LaunchDarkly what history is retrievable and plan experiment analysis around that answer.

Parallel run and bucketing checks

Running LaunchDarkly and the new system side by side is the documented way to validate a cutover. Compare the returned variation for a sample of users in both systems before switching traffic. Partial rollouts are the highest risk: if the hashing or bucketing key differs, users move between variations. Record the result of each comparison so the cutover decision rests on evidence rather than on a single test user.

Migration sequence from wrapped calls to decommissioned LaunchDarkly

This sequence moves an application from direct LaunchDarkly SDK calls to an OpenFeature abstraction, then to a self-hosted flag system, one flag at a time, so that each stage can be checked and rolled back before LaunchDarkly is turned off.

Inventory every LaunchDarkly call and flag
The application team lists each place the code calls the LaunchDarkly SDK, including variation calls, client-side initialization, context construction and any custom events. Alongside it, they record every flag key, its owner, its type (boolean or multivariate), whether it is archived or prerequisite-linked, and which services depend on it. The output is an inventory list that maps each call site to a flag key, and the step is done when the owners of every service have signed off on it.
Wrap SDK calls behind OpenFeature
Engineers replace direct LaunchDarkly calls with the OpenFeature client API and register the LaunchDarkly provider as the initial provider. Evaluation context is built in one place so that the same user or service attributes reach both the old and new paths. The output is a wrapped service with unit tests that confirm each wrapped call returns the same value as the original call for a fixed set of test contexts.
Export flag and segment definitions
The team exports flag and segment definitions as JSON through the LaunchDarkly REST API, using an access token with the minimum read scope needed. They store the exports in version control so every later change can be compared against a known baseline. The output is a versioned set of definition files, and the step is complete when a second person has confirmed that the export covers every environment in the inventory.
Rebuild segments and context fields in the target
Before importing flags, the team creates the segments and context fields in the target system, because Unleash exports and imports reference segments and custom strategies rather than copying them. Targeting rules are mapped to the target's activation strategies, multivariate flags to strategy variants, and prerequisites to flag dependencies, as the Unleash migration guide describes. The output is a mapping document that lists each LaunchDarkly rule and its target equivalent, reviewed by the flag owners.
Pilot one low-risk flag
The team chooses one flag with a simple boolean rule, low traffic impact and an owner who is available during the window. They create the same flag in the target, switch the OpenFeature provider for that flag only, and compare evaluation results for a sample of contexts against LaunchDarkly. The output is a short reconciliation report with any differences explained, and the pilot is closed only when the report shows no unexplained mismatches.
Run both systems in parallel
Both systems run behind the OpenFeature abstraction while the team compares decisions across production traffic. Engineers check that partial rollouts keep the same users in the same buckets, since re-bucketing users changes their experience, and they log any mismatch with the flag key and context. The output is a running reconciliation dashboard or log summary, and the step ends when mismatch rates for every flag in scope are understood and documented.
Cut over flag by flag
Each flag moves to the self-hosted provider in a separate change, starting with flags whose behavior is already verified, and the team keeps the LaunchDarkly definition available for rollback. Owners confirm the result in production before the next flag is switched. The output is a cutover log that records the flag, the date, the change reference and the verification result for each flag.
Decommission LaunchDarkly
After every flag is served by the target and the rollback window has closed, the team removes LaunchDarkly provider configuration, revokes access tokens, deletes the Relay Proxy or other LaunchDarkly-dependent components, and archives the final exports. The output is a decommissioning record confirming that no code path still calls LaunchDarkly, and it should be reviewed against the contract terms and data retention obligations your legal team confirms with LaunchDarkly.

What still changes at cutover: targeting rules, bucketing and SDK behavior

Unleash expresses targeting differently from LaunchDarkly, so the provider swap does not carry rules across by itself. LaunchDarkly targeting rules map to Unleash activation strategies, multivariate flags map to strategy variants, segments map to Unleash segments and prerequisites map to flag dependencies. Unleash's migration guide recommends exporting LaunchDarkly definitions as JSON through the REST API, then recreating them through the Admin API or the import feature.

Activation strategies: Rewrite each targeting rule as an activation strategy and confirm the context fields it reads exist in Unleash before importing.
Segments first: Import export files only reference segments and custom strategies, so create them in the target environment before importing flags.
Variants: Check that each multivariate flag's weights and default variant match the LaunchDarkly definition.
Dependencies: Recreate prerequisites as flag dependencies and test the evaluation order.
Hashing: Rollout percentages are computed by Unleash, so confirm that users already in a partial rollout keep their assigned variant.

Before cutover, run both systems in parallel behind the OpenFeature abstraction and compare evaluations for a sample of real user contexts.

What goes wrong when teams wrap flags without planning the cutover

Wrapping LaunchDarkly calls behind OpenFeature is the easy step. Most migration problems appear later, when flags, segments and user buckets move to a new system. The cards below cover the failures we see most often and the checks that prevent each one.

Users re-bucketed in partial rollouts

If the target system hashes users with a different key or salt, a user who saw the new variant in LaunchDarkly can fall back to the old one after cutover. This breaks experiments and makes support tickets hard to trace. Before cutover, compare how each system buckets a sample of user keys and confirm that the rollout percentages and bucketing attributes match. Keep the context key stable across the OpenFeature wrapper so both providers receive the same identity.

Segments missing at import

Unleash exports segments and custom strategies only as references, so the target must already contain them before a flag import. A flag that depends on a missing segment can evaluate to off or fail silently. Recreate context fields and segments first, then import flags, and check each targeting rule in the target environment against the LaunchDarkly definition.

Importers overwriting an existing project

Flagsmith's LaunchDarkly importer overwrites existing environments and flags in the target project. Running an import into a project that already holds working flags can replace configuration that production depends on. Import into a fresh, empty project, confirm the project name and environment mapping, and review the result by hand before any SDK points at it.

Archived or deprecated flags imported unexpectedly

Flagsmith imports archived or deprecated LaunchDarkly flags as archived, and other importers may bring stale definitions along with live ones. Old flags that still appear active can be evaluated by code paths nobody has reviewed for years. Export the flag inventory, mark retired flags in LaunchDarkly, and decide explicitly which archived flags move before the import runs.

Unleash Edge end of life for OSS

The open-source version of Unleash Edge reaches end of life on December 31, 2026, and Unleash recommends that OSS Edge users move to an Enterprise plan. A self-hosted design that relies on OSS Edge for SDK caching needs a replacement path before that date. Confirm the Edge version and support plan in the target architecture, and include the Edge decision in the cutover timeline rather than after go-live.

AGPLv3 review for Unleash v8.0.0 and later

Starting with v8.0.0, the Unleash server source code moved to AGPLv3, while the official Docker images stay under Apache 2.0. Internal use without modification generally does not change, but offering a modified Unleash as a public or commercial service requires publishing source or buying a license. Have legal review the version you deploy, whether you modify the server, and whether any internal tooling wraps it.

OpenFeature wrappers left in place

Teams often keep the OpenFeature calls and the LaunchDarkly provider after the migration, which leaves a second dependency and a provider that may no longer receive updates. The wrapper then becomes permanent scaffolding. Set a removal date for the LaunchDarkly provider, track its remaining call sites, and delete the provider once parallel running ends and the target provider has been verified in production.

What drives the effort and duration of the buffer and cutover

This table lists the factors that set how much work the OpenFeature buffer and the later cutover will take, why each one matters, and how to keep it manageable. Read it before you ask for a scope or quote, because each row is a question your own inventory can answer. The main takeaway is that the number of flags, segments and owning teams usually matters more than the choice of target platform.

Driver	Why it changes effort	How to keep it down
Services and languages	Each service and SDK language needs its own OpenFeature provider configuration and wrapper, and each one must be tested after the switch. OpenFeature lists server SDKs for many languages, but you must confirm your own languages are covered by both the LaunchDarkly and target providers.	Inventory every service and language first. Retire unused services and consolidate duplicate SDK wrappers into one shared client module before the buffer is built.
Flag and segment count	Every flag needs a target definition, a test case and a parity check between LaunchDarkly and the new system. Segments must exist in the target before flags that reference them can be imported, so segment counts add a second dependency chain.	Export the full flag and segment inventory through the LaunchDarkly REST API, then mark stale flags for removal. Migrate only live flags and archive the rest with a documented decision.
Prerequisites and multivariate flags	Prerequisites become flag dependencies in the target, and multivariate flags map to strategy variants or multivariate values. Both need manual review because importers may not reproduce every nested condition, and mistakes here change which users see which variation.	Flatten chains of prerequisites where possible. Prioritize multivariate flags for side-by-side testing, and confirm the variation mapping with the owning team before cutover.
Client-side versus server-side evaluation	Client-side SDKs ship keys and evaluate in browsers or apps, so changing them means a client release and cache invalidation. Server-side evaluation is usually easier to switch because you control the deployment, but both need a plan for in-flight sessions.	Separate client and server flags in your inventory. Move server-side calls behind OpenFeature first, and schedule client changes with your release train.
Relay Proxy topology	The Relay Proxy sits between your services and LaunchDarkly, so its placement decides which services must be repointed and which network paths must be opened to the new flag server. Unleash Edge or another cache plays the same role after cutover.	Draw the current proxy layout, list the clients behind each proxy, and choose the target caching layer before the buffer goes live. Check the Unleash Edge end-of-life date against your design.
Environments	Each LaunchDarkly environment has its own keys and targeting, and each target platform has its own environment limits. Unleash Open Source allows 2 environments per the Unleash pricing page, so more environments can force an edition or design decision.	Count environments per project and confirm the target edition supports that number before importing. Remove environments that no service uses.
Number of teams that own flags	Flag ownership, approvals and naming conventions must be agreed before parallel running. Each owning team has to verify its own flags, and disagreements about targeting slow the cutover more than technical work does.	Name an owner for each flag group, agree naming and review rules in writing, and schedule verification sessions per team rather than one central review.
User bucketing in partial rollouts	Changing the hashing or bucketing logic moves users between variations and can break experiments or gradual rollouts. Ask each target vendor how it buckets users and whether it can reproduce LaunchDarkly assignments.	Confirm bucketing behavior with a test set of users before cutover. Keep rollout percentages unchanged during the parallel run where the target supports it, and document any residual re-bucketing.

How the buffer approach changes by starting point

When one service calls LaunchDarkly from a small number of places, the OpenFeature wrapper is a short piece of work. You add the OpenFeature SDK, register the LaunchDarkly provider, and route each existing evaluation call through the OpenFeature client. The cutover usually depends on whether the flag set can be recreated quickly and checked by hand, not on the wrapper itself.

Wrapping scope: Limit the change to the handful of call sites and keep flag keys and default values identical so behavior does not shift during the switch.
Parallel run length: Often short, because the flag count is small enough to verify each flag against its LaunchDarkly result before turning the target provider on.
Target setup: Unleash Open Source allows 1 project and 2 environments, which may fit one service. Confirm that the environments you need are covered before you choose it.
Governance: Approval flows and audit features are less pressing for a single team, so you may not need an Enterprise license at all.
Import path: The built-in importers in Flagsmith and GrowthBook can copy the definitions, after which you check each flag by hand.

Before cutover, confirm that the number of flags and environments in your LaunchDarkly account matches what the target plan allows.

Questions teams ask before wrapping LaunchDarkly with OpenFeature

Is OpenFeature worth the effort for a small migration?

For a small flag count with one application, a direct cutover can be simpler, but the wrapper is cheap insurance when the migration may stretch over several releases. OpenFeature describes itself as a vendor-agnostic API whose providers translate between application code and the flag system, so the code that calls flags does not have to change when the provider does. The decision depends on how many services evaluate flags and how many release cycles you expect before the old system is switched off. Ask your team to count the call sites first. If that count is small and one team owns them all, a short, well-tested cutover may be enough. If flags are evaluated in many repositories or languages, the abstraction layer usually pays for itself.

Can our own engineers wrap LaunchDarkly with OpenFeature without outside help?

Often yes, if the team already owns the SDK calls and can run a staging environment. The wrapping work is mostly mechanical: replace direct LaunchDarkly client calls with OpenFeature client calls, configure the LaunchDarkly provider, and add tests that compare evaluation results before and after. The harder parts are the ones that need judgment: inventorying every flag and its owner, deciding which SDK languages need a provider, and agreeing on who signs off the cutover. OpenFeature's documentation lists server SDKs for many languages, including Go, Java, Node.js, Python and .NET, and client SDKs for mobile and web frameworks, so confirm that your languages and frameworks are covered before you plan the work. DeployOpen plans and implements this work under a written, fixed scope if your team prefers outside support.

What does the work require from engineering and product owners?

Engineering owns the code changes, and product owners own the decisions about which flags matter and what each one should do after the move. Engineers need to list each call site, the SDK language, and any client-side evaluation. Product owners need to confirm which flags are still live, which are retired, and which rollouts must not change for users mid-experiment. Both groups should agree on how partial rollouts are kept stable, because a change to the bucketing key can move users to a different variation. Ask for a flag inventory with owners and a sign-off step for each flag before the cutover window opens.

What drives the cost and effort of this work?

The main drivers are the number of call sites, the number of SDK languages, the number of client-side applications, and how many flags carry complex targeting, prerequisites or multivariate values. Each of these adds testing and review time. Costs fall into one-time work (wrapping code, building the provider configuration, writing parallel-run tests, and the cutover itself) and recurring costs (running the self-hosted flag server, its database, backups, and the people who maintain them). Separately, the license of the target platform matters for cost. Unleash Open Source is limited to 1 project and 2 environments, while GrowthBook's self-hosted Open Source plan allows 1 project with unlimited users. Ask any vendor or partner for a written quote that lists these items separately so you can compare them.

How is the parallel run structured between LaunchDarkly and the new provider?

A common structure is to keep LaunchDarkly as the source of truth while the new provider runs in shadow mode, evaluating the same flags with the same context and logging any differences. Unleash's migration guide recommends running both systems in parallel behind an abstraction layer before cutting over, and it also warns about keeping users in the same buckets during partial rollouts. Select a small set of low-risk flags first, compare results for several release cycles, then move the rest in groups. Keep a documented rollback path that switches the provider back in configuration, not in code. The exact duration depends on your release cadence and traffic, so set the window from your own data rather than a fixed number.

Can the OpenFeature wrapper be removed after the migration?

Yes, but removing it is a separate project and only makes sense once the flag system is stable. The wrapper is a set of calls to the OpenFeature API, so removing it means replacing those calls with the new platform's SDK, which is the step that switches each application off the abstraction. GrowthBook's importer documentation notes that the application still has to move from the LaunchDarkly SDK to a GrowthBook SDK after the import, and Flagsmith's documentation says imported flags should be checked by hand. Many teams keep OpenFeature because it reduces future vendor lock-in, so decide whether the abstraction is a permanent design choice before you plan a removal.

Which open-source license terms should we check before choosing the target provider?

Check the license of the server you will run, not only the SDKs. Unleash moved its server source code from Apache 2.0 to AGPLv3 starting with v8.0.0, while its official open-source Docker images remain under Apache 2.0, and its blog states that modifying Unleash to offer it as a public or commercial service requires publishing the source or buying a commercial license. Flagsmith's code is mostly BSD 3-Clause, but Enterprise Edition features such as role-based access control and SAML are closed source. GrowthBook is MIT outside its enterprise directories, which are under the GrowthBook Enterprise License. Ask your legal team to review the specific license files and the features you plan to use before committing.

How DeployOpen scopes and runs the OpenFeature migration

DeployOpen scopes this work from a written inventory and an agreed target platform, then runs it as a fixed-scope engagement inside your own infrastructure. The inventory is the starting point: every place the LaunchDarkly SDK is called, which languages and client frameworks those calls live in, which flag keys and segments are in use, and which services depend on the Relay Proxy. The target choice (Unleash, Flagsmith or GrowthBook) then determines the OpenFeature provider, the server or cloud accounts that host the flag server, and the database that backs it. Scope, deliverables and timelines are agreed in writing before work starts, so the cutover criteria are known to both sides.

A quote follows from that written scope. DeployOpen does not publish a price list, and the quote reflects the number of services and SDK integrations, the number of environments and flags to recreate, whether parallel running and rollback testing are included, and how much governance (SSO, approvals, audit logs) your target tier requires. Ask for the cost of the one-time work separately from any recurring retainer for upgrades, support and continuous testing. Confirm which licensing tier each option needs for your governance requirements before the quote is finalized, since the free self-hosted editions carry project and environment limits.

DeployOpen plans, implements and hardens the platform, but it does not issue audit reports, attestations or certifications. If your migration supports a compliance assessment, DeployOpen can prepare the configuration, access and change evidence, and your independent auditor decides what it proves. Before signing, ask the provider to name the people who will do the work, the environments where it will run, and the acceptance tests that mark the migration complete.

Decouple from LaunchDarkly with OpenFeature before you migrate