How to Migrate from LaunchDarkly to OpenFeature in 6 Steps

Most engineering teams don't rethink their feature flag setup until something breaks. When a third-party outage removes your ability to ship, roll back, or respond, the real problem becomes clear: dependency.

LaunchDarkly is an excellent feature flagging solution, but the October 2025 AWS outage that heavily impacted their platform made this limitation painfully real for many engineering teams who found themselves locked out of their own release controls.

Plus, as your engineering organisation grows, you'll need to consider the pricing and scaling concerns that come with it.

In this guide, we'll show how to introduce OpenFeature alongside LaunchDarkly so that you can reduce dependency and easily migrate from LaunchDarkly when it's the right time for you. Switching feature flag tools is no small feat, which is why a phased approach works for many teams.

But first, what's OpenFeature, and how does it work with LaunchDarkly?

What is OpenFeature?

OpenFeature is a CNCF incubating project that provides a vendor-neutral, open standard for feature flags. You can think of it the way you might think of OpenTelemetry. But instead of standardising observability, it standardises feature flag evaluation.

Essentially, the project gives you an abstraction layer between your application's code and your feature flag provider. Your developers write code against OpenFeature's API and a "provider" handles the translation to whatever backend you're actually using—whether it's LaunchDarkly, Flagsmith, or something else.

When you couple your code to a vendor's SDK, it makes it challenging to switch providers because you have to rewrite every flag evaluation in your codebase. With OpenFeature, you bypass this issue. All you have to do is change the configuration, and you're ready to go. OpenFeature helps you future-proof your codebase.

Note: You can check out our interview with an OpenFeature founding engineer to understand the story behind it.

What is LaunchDarkly?

LaunchDarkly is the market leader in feature flag management. Founded in 2014 and valued at $3 billion, the platform serves over 5,000 customers. If you're reading this, you probably already know the product well.

It has various platform capabilities, including feature management and experimentation. It offers extensive SDK support across languages such as .NET, Java, Node.js, and PHP. It's the kind of polish you'd expect from a company that's raised $330 million in venture funding.

That said, it's also a closed-source proprietary platform. You can't access or audit the source code and you're heavily reliant on its product roadmap and company direction. This means you'll eventually run into vendor lock-in issues if you want to move away from it in the future.

How OpenFeature and LaunchDarkly work together

LaunchDarkly offers official OpenFeature providers for both server-side and client-side implementations. You can use the platform's feature flagging features through OpenFeature's standardised API without losing any functionality.

The architecture looks like this:

• Your application code talks to the OpenFeature SDK
• The SDK talks to the LaunchDarkly provider, which talks to LaunchDarkly's backend
• Your existing flags, targeting rules, and segments all work exactly as they did before.

If you move to OpenFeature, you can keep LaunchDarkly running and retain control over which platform to use in the future. When you decide to move to a different provider, the hard work is already done.

Why you should consider migrating from LaunchDarkly

Here are a few reasons we've seen engineers switch from LaunchDarkly:

1. The AWS outage exposed single points of failure

In October 2025, an AWS US-East-1 outage took LaunchDarkly offline, along with much of the internet. Businesses that were using the platform had no fallback. They couldn't update or create feature flags, so all rollbacks were delayed. For some organisations, production incidents dragged on longer than they should have because the tool meant to help them respond was itself unavailable.

LaunchDarkly's bells and whistles make for complex architecture, in addition to their reliance on SaaS. Flagsmith's architecture is simple in contrast. Additionally, when using Flagsmith's SaaS platform, you get access to our Edge API, which is deployed to eight different regions, each with a local datastore. So even if we lose a region, or in a worst-case scenario, the head is cut off, and we lose the ability to make changes to flags via the dashboard, our ability to serve them is never affected—meaning that our customers' applications will never be affected. Our network architecture always ensures that traffic is routed to the nearest healthy region, which will continue to serve traffic, even in the event that any combination of the eight AWS regions are completely offline. When your feature flag provider goes down, you lose control of your release process at exactly the moment you might need it most.

2. Pricing that's hard to predict

LaunchDarkly's currently published pricing looks straightforward until you read the fine print. You might have signed up looking for straightforward feature flagging, but LaunchDarkly's feature-rich platform means you may end up paying for extra bells and whistles, even if you don't need them.

Here's an example of what we mean:

They do offer a free tier and a $12 paid tier, but if you need to export your data or need bulk user management, you have to sign up for the Enterprise plan. Many engineering teams have reported price increases at renewal, which can be prohibitive. Additionally, variable pricing components will likely add additional cost to each plan.

"LaunchDarkly's price was high, but more than that, the developer experience fell short." That's Dan Bovey, Senior Fullstack Engineer at OakNorth, describing why his team moved to Flagsmith.

3. Vendor lock-in and switching costs

Every LaunchDarkly SDK call in your codebase ties you to the platform. The more flags you have, the more services you've instrumented, the harder it becomes to leave. It's the nature of proprietary SDKs that creates dependencies that compound over time.

The lock-in isn't malicious. But the knee-deep integration creates switching costs, which give the vendor leverage at renewal time. If you've ever felt uneasy signing a contract knowing you'd have to rewrite thousands of lines of code to leave, you know the dynamic.

OpenFeature was designed to solve this problem. Since it offers a vendor-neutral platform that integrates with most feature flagging platforms and works with a variety of programming languages, you can set it up once and switch providers without rewriting code.

4. Technical challenges with LaunchDarkly SDKs

As with any enterprise platform, every update carries the risk of new issues. After a recent update, some developers have reported friction with LaunchDarkly's SDK implementations. The initialiser has been a particular pain point recently, and many users have complained about buggy behaviour during startup.

You can consider moving from its SDKs to something more reliable, such as OpenFeature as it's made to be lightweight and flexible.

5. Integration complexity and technical debt

Some teams find LaunchDarkly's setup and ongoing management more complex than anticipated. The initial integration goes smoothly, but as flag usage scales, the complexity compounds. Workarounds accumulate. Documentation sprawls. What started as a straightforward implementation becomes a source of technical debt.

The onboarding experience has also drawn criticism. After signing up, the call to action is to create a flag—but the path from "flag created" to "flag evaluated in your code" isn't always clear. New users sometimes find themselves hunting through documentation for the next step.

6. Deployment flexibility 

LaunchDarkly is SaaS-only. At the moment, there's no on-premise option or a private cloud deployment. If you're operating in a data-sensitive or regulated industry, this can be a deal breaker.

Many engineering teams work in regulatory environments that prevent their data from living in a public cloud.

Also, without an on-premise or private cloud deployment option, you don't have full control over who can access and use the data. You need a feature flag provider that lets you choose where to host your data.

Why you should consider using OpenFeature and LaunchDarkly together

• Vendor-neutral API with LaunchDarkly's backend: OpenFeature gives you a consistent, CNCF-backed interface for flag evaluation across all your services and languages. LaunchDarkly handles the actual flag management, targeting, and experimentation behind the scenes. Your code speaks a standard language while LaunchDarkly does the heavy lifting. It makes things easier when you want to switch from LaunchDarkly to any other provider.
• Future-proof architecture that doesn't require immediate migration: Let's say you plan on migrating to another feature flagging provider, but you want to future-proof your tech stack. You can keep your existing LaunchDarkly projects running while writing all new code against OpenFeature. This way, you protect yourself and don't have to force a complete switch immediately.
• Standardised flag usage across polyglot stack: OpenFeature SDKs provide a unified programming model across .NET, Java, Node.js, Python, Go, and other languages. Even though LaunchDarkly maintains official providers for major server-side SDKs, it offers community providers covering additional platforms. Your team doesn't need to spend time learning how to work with a new SDK all the time. You can switch and move between feature flagging platforms with ease.
• Cleaner observability and tooling integrations: OpenFeature was designed to integrate with cloud-native tooling from the start—including tying flag evaluations directly to OpenTelemetry traces. LaunchDarkly sits as the provider for these flows, giving you visibility into how flags affect performance and behaviour. But your teams can build reusable internal libraries and governance features around the OpenFeature API while still leveraging LaunchDarkly's UI.
• Flexibility for platform and enablement teams: If you're building a platform function that serves multiple product teams, OpenFeature gives you a standard flagging API that works across all services. Even if you're not using LaunchDarkly, you get the same architecture. You define the patterns once, and the underlying provider helps with implementation only.

How to use OpenFeature and LaunchDarkly together

If you still want to continue using LaunchDarkly, you don't have to choose between LaunchDarkly and OpenFeature. You can run them together while keeping your existing infrastructure in place.

Here's how.

OpenFeature uses a provider pattern. Your application code interacts with the OpenFeature SDK, which defines a standard interface for flag evaluation. The provider, i.e., LaunchDarkly's official OpenFeature provider, translates those standard calls into LaunchDarkly-specific operations.

Picture it like a power adapter for international travel. Your laptop (your code) has a standard plug. The adapter (the provider) handles the translation to whatever outlet (backend) you're plugged into.

This architecture means your flag evaluation logic stays clean and portable. OpenFeature handles initialisation, context translation, and communication with LaunchDarkly's servers. Your code just asks "Is this flag enabled?" as it always does.

In your actual day-to-day, nothing changes. You still manage everything in LaunchDarkly's dashboard. For example, defining targeting rules, segments, and variations.

The only difference is how your application code requests flag values. It doesn't talk to LaunchDarkly's SDK. Instead, it talks to OpenFeature's SDK.

Available LaunchDarkly OpenFeature providers

LaunchDarkly maintains official OpenFeature providers for most major languages and platforms.

• Server-side: Node.js, Java, .NET, Go, Python, and Ruby
• Client-side: JavaScript (browser) and Node.js

Here's more information on how these providers work.

How to migrate LaunchDarkly SDKs to OpenFeature

Here's how you can migrate from LaunchDarkly to OpenFeature:

Step 1: Audit your current LaunchDarkly implementation

Before writing any code, understand what you're working with. Identify every service that uses LaunchDarkly SDKs and document which SDK versions you're running and which languages are in play. If there are custom objects or an initialisation flow, note them.

This exercise lets you scope the work, and you'll know how many services need updating and can prioritise accordingly. Plus, it surfaces edge cases that might require special handling, such as custom integrations.

Here is an example express application that uses the LaunchDarkly SDK directly. 

import express from 'express';
import { init } from '@launchdarkly/node-server-sdk';

const LD_SDK_KEY = process.env.LD_SDK_KEY;

const client = init(LD_SDK_KEY)
client.waitForInitialization({timeout: 10})

const app = express();
const port = 8080;

app.get('/checkout', async (req, res) => {
  const context = {
    'kind': 'user',
    'key': req.query.userId || 'default-user',
  };
  const useStripe = await client.variation('use-stripe-checkout', context, false);
  res.send(`Processing payment via ${useStripe ? 'Stripe' : 'Braintree'}`);
});

app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

Step 2: Install the OpenFeature SDK and LaunchDarkly provider

For each service, you'll install two packages: the OpenFeature SDK for your language and LaunchDarkly's OpenFeature provider.

Here's what that looks like in Node.js:

npm install @openfeature/server-sdk @launchdarkly/openfeature-node-server

The OpenFeature SDK provides the standard API. The LaunchDarkly provider handles communication with LaunchDarkly's backend. You need both of them to get started.

Step 3: Initialise OpenFeature with the LaunchDarkly provider

This is where everything comes together. The setup code needs to run once, when your application starts—not inside individual routes or request handlers.

Update the app to initialise OpenFeature with the LaunchDarkly provider on startup. Rather than initialising LaunchDarkly through its own client, you create a ^{LaunchDarklyProvider} instance and pass it to OpenFeature before the server starts accepting requests:

import express from 'express';

import { OpenFeature } from '@openfeature/server-sdk';
import { LaunchDarklyProvider } from '@launchdarkly/openfeature-node-server';

const LD_SDK_KEY = process.env.LD_SDK_KEY;

const ldProvider = new LaunchDarklyProvider(LD_SDK_KEY);
OpenFeature.setProviderAndWait(ldProvider);

const client = OpenFeature.getClient();

^{setProviderAndWait} ensures the provider is fully ready before any flag evaluations run, so there's no risk of your checkout route firing before LaunchDarkly has finished initialising. Everything you've already set up in LaunchDarkly stays exactly as it is. The only thing that's changed is how your application talks to it.

Step 4: Refactor flag evaluations to use OpenFeature

This is where you update your actual flag calls. Essentially, you're replacing LaunchDarkly SDK methods with their OpenFeature equivalents.

Before (LaunchDarkly SDK directly):

const context = { key: 'user-123', email: 'user\@example.com' };
const useStripe = await client.variation('use-stripe-checkout', context, false);

After (OpenFeature with LaunchDarkly provider):

const context = { targetingKey: 'user-123', email: 'user\@example.com' };
const useStripe = await client.getBooleanValue('use-stripe-checkout', false, context);

Notice the pattern: ^variation() becomes ^{getBooleanValue()} (or ^{getStringValue()}, ^{getNumberValue()}, ^{getObjectValue()} depending on your flag type). The context structure shifts slightly—^key becomes ^targetingKey—but the data is the same.

So, now we end up with this: 

import express from 'express';

import { OpenFeature } from '@openfeature/server-sdk';
import { LaunchDarklyProvider } from '@launchdarkly/openfeature-node-server';

const LD_SDK_KEY = process.env.LD_SDK_KEY;

const ldProvider = new LaunchDarklyProvider(LD_SDK_KEY);
OpenFeature.setProviderAndWait(ldProvider);
const client = OpenFeature.getClient();

const app = express();
const port = 8080;

app.get('/checkout', async (req, res) => {
  const context = {
    'targetingKey': req.query.userId || 'default-user',
  };
  const useStripe = await client.getBooleanValue('use-stripe-checkout', false, context);
  res.send(`Processing payment via ${useStripe ? 'Stripe' : 'Braintree'}`);
});

app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

Step 5: Validate and test your migration

Don't flip the switch all at once. It is entirely possible to run your OpenFeature implementation alongside your existing LaunchDarkly integration. This will allow you to verify that both methods return the same results.

Try different testing scenarios and rectify issues before actually getting started with OpenFeature.

Step 6: Remove the legacy LaunchDarkly SDK

Once you've validated that the OpenFeature and LaunchDarkly provider works correctly, you can remove the direct LaunchDarkly SDK dependency. It'll prevent your team from using the wrong SDKs.

npm uninstall launchdarkly-node-server-sdk

Your flags still live in LaunchDarkly, and targeting rules still work. The only thing that changed is how your code talks to the service.

What are the benefits of using OpenFeature and LaunchDarkly?

You've done the migration work. Your SDKs now speak OpenFeature's standard language while LaunchDarkly handles flag management behind the scenes. What did you actually gain?

1. You can eliminate vendor lock-in

The best and most immediate benefit you'll experience is optionality. Your code no longer contains LaunchDarkly-specific calls scattered across every service. If you decide to switch providers next year or in five years, the migration is a simple configuration change.

You don't have to come from a place of inflexibility. You'll be able to negotiate better contracts and reduce the technical burden of switching in the future.

2. Your developers get a better experience

OpenFeature gives your teams a single API to learn. Whether a service uses LaunchDarkly, Flagsmith, or an internal feature flag system, developers use the same patterns. They can use the same feature flags with the same context structure and initialisation flow.

In the future, onboarding gets faster, and developers can move between projects without learning new SDKs. The cognitive load of "How do I check a flag on this platform?" becomes nil.

3. You can access OpenFeature's entire ecosystem

OpenFeature is more than an abstraction layer. For example, you get access to features like Hooks, where you can inject logic before and after flag evaluations without modifying your application code.

If you want to log every flag evaluation for debugging, just add a logging hook. Or send flag data to your observability platform using an OpenTelemetry hook. It works irrespective of which feature flagging provider you use.

Other than that, you can also access competing providers like Flagsmith through the same ecosystem. When the time to switch comes, you can migrate in a few steps.

How to migrate from LaunchDarkly to other feature flagging platforms

If you're considering a full migration to a different provider, here's what that path looks like:

1. Choose your new provider and verify that it has an OpenFeature-compatible SDK
2. Set up the new provider with your flag configurations—many providers offer import tools
3. Swap the provider in your initialisation code—this is often a one-line change per service
4. Validate in staging, comparing flag evaluations between old and new
5. Roll out to production, service by service or all at once, depending on your risk tolerance

How Flagsmith makes the final migration simple

If you've already made the choice to move to Flagsmith, we offer a LaunchDarkly importer to make that happen. It automatically imports your existing flags, segments, and configurations into Flagsmith. You don't have to recreate everything manually.

You need a LaunchDarkly access token to do this using the following steps:

1. Log in to your LaunchDarkly account
2. Navigate to Account settings > Authorisation > Access tokens
3. Create an access token and copy
4. Create a Flagsmith account
5. Create a new project or select an existing one
6. Go to Project Settings > Import
7. Paste the access token
8. Import your data

Once your flags are in Flagsmith, you swap the provider in your OpenFeature initialisation:

import { OpenFeature } from '\@openfeature/server-sdk';
import { Flagsmith } from 'flagsmith-nodejs';
import { FlagsmithOpenFeatureProvider } from '@openfeature/flagsmith-provider';

const flagsmithClient = new Flagsmith({ environmentKey: FLAGSMITH_SDK_KEY });
const flagsmithProvider = new FlagsmithOpenFeatureProvider(flagsmithClient);

OpenFeature.setProviderAndWait(flagsmithProvider);

That's it. Your flag evaluations now hit Flagsmith instead of LaunchDarkly. Your application code remains unchanged.

Why you should consider migrating to Flagsmith from LaunchDarkly

There are several reasons you should consider switching over to Flagsmith. Some of them include:

• We're open source. You can see exactly how Flagsmith is built and even contribute to where we're going.
• We offer SaaS, private cloud, and self-hosted deployment models. Irrespective of your engineering or compliance requirements, we can support you.
• We are resilient due to our infrastructure as we've built redundancy into Flagsmith.
• We also offer a predictable pricing model with transparent rates.
• We're part of the OpenFeature project and sit on its governance board.

"Flagsmith is a flag provider that works closely with us and is aligned with the way we work at OakNorth. Having a clear user interface to manage flags is really important to us, and one of the reasons we made the switch away from LaunchDarkly. We might be working on a feature for months, but we're still pushing code to production multiple times a day. It's safe because the flag is off in Flagsmith. Then when we're ready, we roll it out gradually."
‍
– Dan Bovey, Senior Fullstack Engineer, OakNorth

Prevent vendor lock-in with OpenFeature's feature flagging ecosystem

Most teams don't rethink their feature flag architecture until something breaks. It would be an outage or a surprise renewal price increase. At that point, migration can feel overwhelming, even though the lost trust and high pricing are worth the switch.

With a solution like OpenFeature, you can avoid all that and more. When you introduce an abstraction layer to decouple your code from your feature flagging provider, you can switch platforms in days rather than months—no need to refactor your code.

While the AWS outage in 2025 left many engineering teams unprepared, the next disruption doesn't have to.

Ready to migrate from LaunchDarkly? Here are your options:

• Choose LaunchDarkly's OpenFeature provider and migrate.
• Or start a free trial of Flagsmith to see if it's the right option for you.