Migrating from LaunchDarkly

This guide is for teams that run feature flags on LaunchDarkly and want to move them to ConfigDirector. It maps the LaunchDarkly concepts onto ConfigDirector's, walks through recreating the flags, and shows how to switch each SDK over so that both services run side by side until you remove the LaunchDarkly one.

If you are new to ConfigDirector, read Core Concepts first. It takes a few minutes and makes the mapping below easier to follow.

Before you start

1. Pick one LaunchDarkly project to move first. A project with a handful of flags and one or two services is a good rehearsal. Everything below is done per project.
2. Make a list of the flags, with their variations and targeting. LaunchDarkly has no flag export, but its REST API lists every flag in a project with its variations and a summary of the targeting in each environment: GET /api/v2/flags/{projectKey}, with ?env=production&summary=false for the full rules. See the LaunchDarkly API documentation. For a small project, the flag list in the LaunchDarkly dashboard is enough.
3. Decide which flags not to move. A migration is the best moment to clean up. A flag whose status is launched or inactive in every environment serves one value and has nothing left to decide. Hardcode that value in the code instead of recreating the flag. Only active flags, and the permanent ones you still rely on, need to move.
4. Create your ConfigDirector organization and project. Sign up, create a project, and add an environment for each LaunchDarkly environment you use. Test and Production are created for you. Mark the environments that serve real traffic as live.

How the concepts map

Projects, environments, and flags

Targeting

Contexts

SDKs and delivery

Recreate the flags

Create the configs in ConfigDirector while the LaunchDarkly flags keep serving your applications. Nothing changes for your users until the SDKs switch over.

For each flag you decided to move:

1. Create a config with the same key, the role and type from the tables above, and the lifetime. Set its initial value to what LaunchDarkly serves most users in production today, so an application that reads it before its rules exist gets a safe value.
2. Set the SDK availability to match where the flag is read.
3. In each environment, recreate the targeting: individual targets as identifier is one of rules, rules as conditional rules, the rollout as a percentage rollout, and the fallthrough as the default targeting rule value.
4. Check a few contexts with the targeting rules tester. The result should be the value LaunchDarkly serves them.

There are three ways to do this:

• The dashboard, for a project with a few flags. The config form and the targeting rules editor cover everything above.
• The Terraform provider, if your LaunchDarkly flags were managed with LaunchDarkly's Terraform provider. The ConfigDirector Terraform provider has configdirector_config for the flag and configdirector_config_targeting_rules for the rules of each environment, with the same structure as the tables above. Translate the resources once and apply.
• The MCP server, for a project with many flags that you manage by hand. Connect the MCP server to your coding assistant, give it the flag list from the LaunchDarkly API, and ask it to create the configs and their targeting rules. Review what it created in the dashboard before switching any SDK.

Switch the SDKs

Switch one application at a time. Pass the value LaunchDarkly serves today as the in-code default value, so that a config that is missing, or read before the client is ready, still gives the result users get now.

Server SDKs

A Node.js service reading a flag with the LaunchDarkly server SDK:

import * as LaunchDarkly from "@launchdarkly/node-server-sdk";

const ldClient = LaunchDarkly.init("YOUR-LAUNCHDARKLY-SDK-KEY");
await ldClient.waitForInitialization({ timeout: 10 });

const context = {
  kind: "user",
  key: "user-123",
  name: "Example User",
  email: "user@example.com",
  plan: "enterprise",
};

const newCheckout = await ldClient.variation("new-checkout", context, false);

The same flag with the ConfigDirector Node.js SDK. The context's custom attributes move under traits, and the key becomes id:

import { createClient } from "@configdirector/server-sdk";

const client = createClient("YOUR-SERVER-SDK-KEY");
await client.initialize();

const context = {
  id: "user-123",
  name: "Example User",
  traits: {
    email: "user@example.com",
    plan: "enterprise",
  },
};

const newCheckout = client.getValue("new-checkout", false, context);

A context of another kind sets kind:

const organization = { id: "acme", kind: "organization", name: "Acme Inc.", traits: { plan: "enterprise" } };

const newCheckout = client.getValue("new-checkout", false, organization);

getValue is synchronous: the server SDK evaluates the rules it already holds in memory. The type of the value is the type of the in-code default value you pass, so a string flag is read with a string default and a JSON flag with an object. The Python, Java, .NET, and Go SDKs follow the same shape.

Browser and mobile SDKs

A web application with the LaunchDarkly JavaScript client SDK:

import * as LDClient from "launchdarkly-js-client-sdk";

const ldClient = LDClient.initialize("YOUR-CLIENT-SIDE-ID", {
  kind: "user",
  key: "user-123",
  name: "Example User",
  plan: "enterprise",
});
await ldClient.waitForInitialization(5);

const newCheckout = ldClient.variation("new-checkout", false);
ldClient.on("change:new-checkout", (value) => render(value));

await ldClient.identify({ kind: "user", key: "user-456" });

The same with the ConfigDirector JavaScript SDK. The context is given to initialize, changes arrive through watch, and identify becomes updateContext:

import { createClient } from "@configdirector/client-sdk";

const client = createClient("YOUR-CLIENT-SDK-KEY");
await client.initialize({
  id: "user-123",
  name: "Example User",
  traits: { plan: "enterprise" },
});

const newCheckout = client.getValue("new-checkout", false);
client.watch("new-checkout", false, (value) => render(value));

await client.updateContext({ id: "user-456" });

initialize resolves when the first values arrive or after its timeout, 3 seconds by default; after a timeout the client keeps connecting in the background and reads return the in-code default value until values arrive. The React, Vue, React Native, Flutter, Swift, and Android SDKs follow the same shape, with a hook, composable, stream, or flow in place of watch.

Applications on OpenFeature

If your code reads flags through OpenFeature with the LaunchDarkly provider, the code does not change: register the ConfigDirector provider instead. The targetingKey becomes the context's identifier. Attributes the ConfigDirector provider reads are kind, name, traits, and anonymous, so move the custom attributes your rules use into a traits attribute. See OpenFeature with ConfigDirector for the providers and the full mapping.

Which SDK replaces which

ConfigDirector has no SDK for Ruby, PHP, Rust, C++, Erlang, Haskell, Lua, Roku, or Electron, and no edge SDKs. If you need one of them, write to sdks@configdirector.com with the SDK you are looking for and we will let you know the projected date for its release.

Verify, then remove LaunchDarkly

Once an application reads a config from ConfigDirector:

• Evaluation Activity on the config shows the values being served in each environment. See Evaluation Activity.
• Alerts catch the mistakes a migration makes: a key the application asks for that does not exist, a config read with the wrong type, an in-code default value that drifts from the value served, and the default value served more often than expected. See Alerts.
• For a flag you rolled out by percentage, the same identifier gets the same value on every evaluation, as in LaunchDarkly. The split itself is assigned afresh, so a user who was in LaunchDarkly's 10% is not necessarily in ConfigDirector's. Switch the SDK over at a point in the rollout where that is acceptable, or at 0% or 100%.

When every application has switched, remove the LaunchDarkly SDK and its keys from the code, and archive the flags in LaunchDarkly. From then on, the config lifecycle tells you when each temporary config has settled and can be removed from the code too.

Metering

The two services meter different things, which matters for the bill once you are past the free allowance. LaunchDarkly counts client-side monthly active users and service connections. ConfigDirector counts client sessions, which are client SDK instances with a session that lasts up to 6 hours in a browser, service connection hours of your server SDKs, and Admin API requests. Pricing and billing explains the three and the free allowance, which applies on both pricing options.