Migrating LaunchDarkly Node.js SDK Usage to OpenFeature: A Safe, Practical Guide

What changes when adopting OpenFeature

Adopting OpenFeature changes where in your application the flag evaluation boundary lives. Today, most LaunchDarkly Node.js codebases call the LaunchDarkly SDK directly from business logic — every boolVariation, stringVariation, or jsonVariation call is a direct dependency on the LaunchDarkly SDK.

Four things to understand before starting:

• OpenFeature is a vendor-neutral evaluation API standard — it does not replace LaunchDarkly. LaunchDarkly may continue to evaluate your flags through its official OpenFeature provider.
• The flag service does not change. Your existing LaunchDarkly flags, targeting rules, and environments stay exactly as they are.
• The migration moves the evaluation boundary into application code. You are changing how your application calls the flag service, not what the flag service does.
• FlagLint does not configure or operate the provider. FlagLint analyzes your source code and rewrites call sites. Initializing the OpenFeature client with a LaunchDarkly provider is a separate manual step covered in the OpenFeature Provider Setup guide.

Why the migration is deceptively risky

If you were to migrate by hand or with a naive find-and-replace, you would almost certainly introduce a silent runtime bug. The root cause is an argument-order inversion between the LaunchDarkly SDK and the OpenFeature API.

// LaunchDarkly: (key, context, fallback)
ldClient.boolVariation("checkout-v2", context, false);

// OpenFeature: (key, fallback, context)
openFeatureClient.getBooleanValue("checkout-v2", false, context);

The equivalent migration diff looks like this:

- return ldClient.boolVariation("checkout-v2", context, false);
+ return flags.getBooleanValue("checkout-v2", false, context);

A mechanical migration can still produce incorrect code, especially in:

• JavaScript — no type enforcement at all
• Loosely typed or any-typed TypeScript — the compiler cannot catch the mismatch
• Wrapper APIs or codemods — tools that transpose the method name without also transposing the arguments

In strictly typed, direct SDK usage, TypeScript may catch the incorrect ordering — but teams should not rely on type checking as their migration strategy. Type errors depend on how the client and context types are declared; they are not guaranteed.

Migration-pattern classification

Not all LaunchDarkly call sites are equally safe to rewrite automatically. FlagLint classifies every detected call site by migration pattern before deciding whether to rewrite or report for manual review.

Complete migration workflow

FlagLint provides four commands that form a complete migration workflow. Run them in order.

npx flaglint@latest audit ./src

npx flaglint@latest migrate ./src --dry-run

npx flaglint@latest migrate ./src --apply

npx flaglint@latest validate ./src --no-direct-launchdarkly

Enterprise checkout service case study

This case study uses the FlagLint enterprise-checkout-service demo fixture, a realistic checkout service with intentionally mixed patterns — static evaluations, dynamic keys, detail calls, and a shared wrapper function.

The three changed files are checkout.ts, pricing.ts, and product.ts — the files that contained only static-key evaluations. The remaining two files (analytics.ts and flags-wrapper.ts) were left unchanged because they contain dynamic keys, detail calls, or bulk evaluation patterns that require manual review.

Actual audit output from flaglint audit:

✓ Audit complete: 13 flags — 3 high risk, 10 medium risk

Migration readiness: 50/100  ·  moderate
[█████████████░░░░░░░░░░░░] 50%
10 safely automatable  ·  10 require manual review

A readiness score of 50/100 means roughly half the call sites in this codebase require manual review before migration can be declared complete. In this fixture, that is primarily due to dynamic flag keys inside a shared wrapper function in flags-wrapper.ts that accepts a flag key as a parameter. Resolving those 10 manual-review calls — for example, by extracting keys to constants where possible — would push the score toward 100/100.

Rewrite and refusal examples

The following examples come directly from flaglint migrate --dry-run output on the enterprise-checkout-service fixture.

// Before
return ldClient.boolVariation("checkout-v2", ctx, false);
// After
return openFeatureClient.getBooleanValue("checkout-v2", false, ctx);

// Before
return ldClient.stringVariation("payment-provider", ctx, "stripe");
// After
return openFeatureClient.getStringValue("payment-provider", "stripe", ctx);

return ldClient.boolVariation(flagKey, ldContext, defaultValue);

Manual review required: dynamic flag key

return ldClient.boolVariationDetail(flagKey, context, false);

Manual review required: detail methods skipped — OpenFeature detail APIs exist,
but LaunchDarkly/OpenFeature detail result parity requires manual review

Provider boundary

Rewriting application call sites is necessary but not sufficient. Before the rewritten code will work in production, the OpenFeature client must be initialized with a LaunchDarkly provider that routes evaluation calls to the LaunchDarkly service. That is a separate manual setup step — see the OpenFeature Provider Setup guide for instructions.

• FL
  Source-code migration

  FlagLint handles: rewrites call sites, transposes arguments, renames methods
• M
  OpenFeature client initialization

  Manual setup: initialize OpenFeature with your chosen provider before evaluations
• M
  LaunchDarkly provider configuration

  Manual setup: register the LaunchDarkly OpenFeature provider with your SDK key
• M
  Application rollout and testing

  Manual: verify flag behavior is unchanged in staging before promoting to production
• FL
  CI enforcement

  FlagLint handles: flaglint validate --no-direct-launchdarkly gates the boundary in CI

Preventing regression in CI

Once the migration is complete, add a validation step to CI to ensure no new direct LaunchDarkly calls are introduced as the codebase evolves.

npx flaglint@latest validate ./src --no-direct-launchdarkly

After the 10 safe rewrites only — 10 manual-review calls still remain in analytics.ts and flags-wrapper.ts. Strict validation fails at this intermediate state:

10 direct LaunchDarkly calls remain. Resolve manual-review findings before enforcing this gate.

Once all 10 manual-review calls have been separately resolved or removed, validation passes. The output below is from the enterprise-checkout-service after-complete fixture — a completed-state demonstration where those calls have already been resolved:

✓ validate --no-direct-launchdarkly: no direct LaunchDarkly evaluation calls found.
  Scanned 5 file(s).

GitHub Actions snippet:

- name: Enforce OpenFeature boundary
  run: npx flaglint@latest validate ./src --no-direct-launchdarkly

Get started

Run the audit command to see where you stand. FlagLint runs entirely locally — your source code does not leave your machine.

npx flaglint@latest audit ./src