open-source

Flipt's LaunchDarkly Migration Guide Recommends FlagLint

Jul 5, 2026 - 2 min read

Flipt is an open-source feature flag platform — one of the most popular self-hosted alternatives to LaunchDarkly. Their official documentation includes a guide for migrating a Node.js application from the LaunchDarkly SDK to OpenFeature, and that guide now recommends FlagLint for the codebase analysis step.

Here’s what that looks like in practice and why it makes sense.

The migration Flipt’s guide covers

Flipt supports OpenFeature through its official provider — so a team moving away from LaunchDarkly can route flag evaluation through the OpenFeature API to Flipt’s provider instead. The flag evaluation backend changes, but the application code uses the same vendor-neutral API regardless of which provider is behind it.

The challenge isn’t the provider setup. It’s the application code. A typical Node.js service has dozens of direct LaunchDarkly SDK calls — boolVariation, stringVariation, jsonVariation — all using LaunchDarkly’s argument order. OpenFeature’s equivalent methods take arguments in a different order, and a naive find-and-replace will silently swap your fallback values and context in every call site.

That’s the problem FlagLint solves before you write a single line of migration code.

How FlagLint fits into the Flipt workflow

Flipt’s guide recommends running three FlagLint commands as an optional but practical first step for larger codebases:

# See every direct LaunchDarkly call site in your codebase
npx flaglint scan ./src

# Get a migration readiness score and per-flag risk classification
npx flaglint audit ./src

# Preview the exact rewrites FlagLint will make, without touching any files
npx flaglint migrate ./src --dry-run

The dry-run output shows you exactly which call sites will be rewritten and what the rewritten code looks like — before anything changes. Call sites that FlagLint cannot safely rewrite (dynamic flag keys, detail methods, bulk evaluation) are reported for manual review and left untouched.

After reviewing the diff, --apply writes the changes. Then you wire in the Flipt OpenFeature provider, run your tests, and enforce the boundary in CI with flaglint validate.

Why this pairing makes sense

FlagLint and Flipt don’t overlap. FlagLint analyzes and rewrites your application’s call sites. Flipt evaluates your flags at runtime through an OpenFeature provider. They’re doing completely different jobs at different layers of the stack.

What they share is a user: someone who has decided to move away from vendor lock-in and is doing the actual migration work. FlagLint handles the static analysis half; Flipt handles the runtime half.

If you’re in that position — evaluating Flipt as a LaunchDarkly replacement and trying to understand the migration scope — flaglint audit is a good first step. It gives you a concrete inventory and readiness score before you commit to any approach.

npx flaglint@latest audit ./src

No API key, no source upload, runs locally in under a minute. See the full migration guide for everything that comes after the audit.