How to Migrate from LaunchDarkly to Unleash

Teams that move from LaunchDarkly to Unleash most often do so to reduce licensing costs, frequently combined with requirements for self-hosting and keeping user data within their own infrastructure. The move is more straightforward than you might expect: LaunchDarkly concepts map cleanly to Unleash, the entire data migration can be scripted thanks to Unleash’s API-first architecture, and with a phased approach your teams are productive on Unleash within days.

This post covers the concept mapping, how to move your flag definitions, what changes in your application code, and the behavioral differences worth planning for.

TL;DR:

• Follow the five migration phases: plan, pilot, migrate, cut over, and onboard.
• LaunchDarkly targeting rules map to Unleash activation strategies, multivariate flags to strategy variants, segments to segments, and the Relay Proxy to Unleash Edge.
• Export flag definitions with the LaunchDarkly REST API, then recreate them through the Unleash Admin API or import functionality. AI assistants can do the conversion, with your team reviewing the translated targeting rules.
• Run both systems in parallel behind an abstraction layer, and cut over once evaluation results match.
• Plan for re-bucketing of percentage rollouts (see stickiness), instance-unique flag names, and different archived-flag behavior.

Why teams switch from LaunchDarkly to Unleash

Cost is the most common driver. Beyond price, Unleash gives you architectural control: backend SDKs evaluate flags locally in your application, and frontend evaluation can run on Unleash Edge inside your own network, so sensitive user context never leaves your infrastructure. You choose between cloud-hosted, hybrid, and fully self-hosted deployments. For a feature-by-feature view, see Unleash vs LaunchDarkly.

 

Run the migration in five phases

Before diving into the mechanics, anchor the project in a proven sequence: plan the scope and target state, creating all new flags in Unleash from day one and deleting stale flags instead of migrating them; pilot with one or two teams; migrate team by team while running both systems in parallel; cut over and decommission LaunchDarkly once its evaluation traffic reaches zero; and onboard your teams with single sign-on, per-team permissions, and flag hygiene routines.

 

 

The migration guide covers each phase in detail and includes a downloadable checklist with a repeatable per-team migration plan. The rest of this post covers the LaunchDarkly-specific mechanics that fit inside those phases.

How do LaunchDarkly concepts map to Unleash?

Most of your existing setup translates directly:

 

LaunchDarkly	Unleash
Projects and environments	Projects and environments, with one flag entity across all environments
Targeting rules	Activation strategies with constraints
Multivariate flags	Strategy variants with payloads
Segments	Segments
Percentage rollouts	Gradual rollout with stickiness
Prerequisites	Flag dependencies
Contexts and context kinds	Unleash context with custom context fields
SDK keys, mobile keys, client-side IDs	API tokens, scoped to projects and environments
Relay Proxy	Unleash Edge
Approvals and scheduled changes	Change requests
Experimentation	Strategy variants with impression data analyzed in your analytics platform

 

The full mapping, including individual targeting and list-based segments, is in the migration guide’s searchable concept table.

Moving your flag definitions

Unleash provides two ways to bring flag definitions in programmatically: the Admin API, which can create and configure every part of a flag, and the import functionality, which loads a JSON file of flags and their configuration per project and environment. A typical data migration looks like this:

1. Export your flag and segment definitions as JSON using the LaunchDarkly REST API.
2. Create custom context fields and segments in Unleash first, since flag strategies reference them.
3. Recreate flags and their strategies through the Admin API, or transform the exported data into the import format and load it per project and environment.

An AI assistant can handle the transformation between the two formats, including translating targeting rules. Review each translated rule rather than trusting the output blindly, because rule semantics rarely map one-to-one between providers. With the Unleash MCP server, an assistant can go further: create the flag in Unleash and rewrite its call sites in a single workflow.

Updating your application code

The SDK architecture maps cleanly. LaunchDarkly server-side SDKs and Unleash backend SDKs both evaluate flags locally in your application. LaunchDarkly client-side SDKs and Unleash frontend SDKs both receive evaluated results, so no targeting rules or user data are exposed to the client. One difference to plan for: LaunchDarkly SDKs stream updates by default, while Unleash relies on polling by default because it is a more stable architecture, with changes propagating within seconds. You can enable real-time streaming if you need it.

At the call-site level, client.boolVariation(key, context, fallback) becomes isEnabled(key, context), and the typed variation calls (stringVariation, numberVariation, jsonVariation) become getVariant(key, context) with the value carried in the variant payload.

Most teams wrap flag evaluation in a small abstraction layer so each call site only changes once; during the transition the wrapper evaluates both systems, logs mismatches, and serves LaunchDarkly’s answer until the results match. If you already use OpenFeature with the LaunchDarkly provider, you can keep your call sites unchanged and swap in an Unleash provider.

Behavioral differences to plan for

• Flag names are unique per instance. LaunchDarkly flag keys are unique per project; Unleash flag names are unique across the whole instance. If the same key exists in multiple LaunchDarkly projects, rename on migration, for example by prefixing with the project name.
• Percentage rollouts re-bucket on cutover. The two systems use different hashing algorithms, so the users inside a 50% rollout will not be the same after migration. Where possible, migrate flags while they are at 0% or 100%.
• Archived flags behave differently. LaunchDarkly serves the in-code fallback value for archived flags. Archived Unleash flags are no longer exposed to SDKs, so evaluation returns false or your SDK-level default. Verify your defaults are safe before archiving migrated flags.
• Typed defaults move into code or variants. LaunchDarkly stores per-flag default and off variations server-side. In Unleash, a disabled flag evaluates to false, and non-boolean defaults belong in your code or in variant payloads.

Frequently asked questions

How do I migrate from LaunchDarkly to Unleash?

Export your flag definitions with the LaunchDarkly REST API, recreate them through the Unleash Admin API or import functionality, update your application code to use Unleash SDKs, and run both systems in parallel until evaluation results match. Work in five phases: plan, pilot, migrate, cut over, and onboard.

How do I transfer my flag definitions from LaunchDarkly?

Use the LaunchDarkly REST API to export flags and segments as JSON, then recreate them through the Unleash Admin API or transform them into the import format. AI assistants can automate the conversion; always review the translated targeting rules manually.

Can I run Unleash alongside LaunchDarkly during the migration?

Yes, and you should. Keep LaunchDarkly as the authoritative fallback while you verify that Unleash returns the same results, then cut over per flag, team, or service. Running two flag systems in parallel is safe and common.

Will the same users be in my percentage rollouts after migrating?

No. LaunchDarkly and Unleash use different hashing algorithms to assign users to rollout buckets, so plan the cutover of partially rolled-out flags accordingly. Within Unleash, stickiness keeps assignments consistent.

How long does a LaunchDarkly migration take?

With incremental execution, individual teams are typically productive on Unleash within days, while the migration of legacy flags runs alongside normal work over weeks or months. The migration is complete when LaunchDarkly serves no evaluation traffic.

Start your migration

Read the full LaunchDarkly migration guide, download the migration checklist, and see how other teams made the switch. Ready to compare with your own flags? Start a free trial or book a demo.