A provider outage can expose how deeply application code depends on a single feature-flag SDK.

A provider outage can expose how deeply application code depends on a single
feature-flag SDK. OpenFeature creates a neutral application boundary without
forcing teams to abandon LaunchDarkly.

This article walks through the local audit, migration preview, and CI enforcement
path that lets teams add that boundary incrementally.

The Vendor Lock-In Problem

Direct SDK calls look like this:

import LaunchDarkly from 'launchdarkly-node-server-sdk';
const ldClient = LaunchDarkly.init(process.env.LD_SDK_KEY);

const enabled = await ldClient.boolVariation('checkout-v2', ctx, false);

Your application code is coupled to LaunchDarkly's API surface.
Switching providers means rewriting every evaluation call.

OpenFeature decouples this. Your application calls the OpenFeature API.
The provider (LaunchDarkly, or anything else) is a configuration detail.

The Migration That Stalls

Most teams agree to add OpenFeature. Most migrations take 6+ weeks
and nearly break production at least once.

The reasons:

• No inventory of where direct SDK calls live
• Argument-order differences cause subtle production bugs
• Phased migrations partially reverse when new engineers join
• No CI enforcement to prevent new direct calls

One of those reasons is an API difference that breaks even careful rewrites — the argument-order trap between LaunchDarkly and OpenFeature →

What FlagLint Does

Before you can migrate, you need to know what you're migrating.

npx flaglint scan ./src

AST-based inventory of every direct LaunchDarkly SDK call.
File, line, call type, flag key, whether it's safely automatable.

Then:

```bash frame="none"
flaglint migrate ./src --dry-run

Reviewable diffs for safe call sites. Argument order corrected.
Dynamic keys, detail methods, and bulk calls reported for manual review.

Then:



```bash frame="none"
flaglint validate ./src --no-direct-launchdarkly

CI gate. Fails the build if any new direct LD call appears.
The migration doesn't rot.

LaunchDarkly Stays As Your Provider

This is not a migration away from LaunchDarkly.

LaunchDarkly offers an official OpenFeature provider. After the migration,
LaunchDarkly still evaluates your flags — you're just calling the
OpenFeature API instead of the LaunchDarkly SDK directly.

The difference: if you need to switch providers, you change the provider
configuration. Your application code doesn't change.

→ Start with the scan

→ GitHub

Related: Why LaunchDarkly → OpenFeature Migrations Break in Production →

Originally published at flaglint.dev