OpenFeature migration & flag cleanup

Your flags.
Your code.
Your choice.

Free your code from vendor-specific APIs. Move supported LaunchDarkly calls to OpenFeature through reviewable PRs, then automate obsolete flag cleanup.

Request migration assessment Inspect a generated diff

Pilot: LaunchDarkly Node.js · JavaScript / TypeScript
LaunchDarkly stays your backend.Check support for your stack

A change you can inspectIllustrative examples

src/checkout.tsTypeScript

Before

−const enabled =
−  await ldClient.variation(
−  'new-checkout',
−  { key: user.id },
−  false,
−);

After

+const enabled =
+  await flags.getBooleanValue(
+  'new-checkout',
+  false,
+  { targetingKey: user.id },
+);

Preview → draft PR → your review

Call-site illustration. Provider setup and context mapping are part of the full change plan.

Change the call. Keep the behavior in view.

A supported evaluation moves to the OpenFeature API. Your current provider still serves the flag.

The new connection

Own the API boundary. Keep the choice of backend open.

Your applicationThe code you own
OpenFeatureYour portable API boundary
LaunchDarklyRetained in the current pilot

Follow the work

From vendor-specific code
to a change you control.

Explore a real generated preview, including the checks that stop it. Every stage has a purpose. Every unresolved step stays visible.

example/shopSynthetic input · actual engine output

Synthetic source

Start with the code you have.

A small Node.js repository, one flag evaluation, and the LaunchDarkly SDK. This is the actual input to the generated preview.

src/flags.ts

import * as ld from '@launchdarkly/node-server-sdk'
const FLAG_KEY = 'new-checkout'
const client = ld.init(process.env.LD_SDK_KEY!)

export async function enabled(): Promise<boolean> {
  await client.waitForInitialization()
  return client.variation(
    FLAG_KEY,
    { key: 'customer-1', custom: { plan: 'pro' } },
    false,
  )
}

1 / 5

LaunchDarkly remains the runtime backend. No customer data, live CI, publication or merge in this example.

Inspect the complete diff & provenance

Find your starting point

What does your
migration look like?

Choose your stack. See the registered stage, check the SDK boundary, and bring that context into your assessment.

Your current stack

Flag provider

Language

Runtime

Source registry · 2026-09-17
A capability snapshot, not a live availability check.

Inspect the source snapshot ↓

Different stacks. Different starting points.

Get the scope before
you make the move.

Some paths support assessment only. Others can preview changes or progress through a draft PR and static verification.

Select your language and runtime to see the exact candidate profile.

Scheduled cleanupSimulator exercise

Find it. Remove it.
Check it’s gone.

temporary flagintended branch retained

Actual Piranha transformation checked
Draft → CI → human merge simulated
Default-branch verification in simulator

Four JavaScript/TypeScript fixtures, covering manual and scheduled cleanup. No live GitHub PR, customer CI or real human merge.

Inspect the exercise & source code

Keep it clean

Temporary flags.
Not permanent baggage.

The feature ships. The flag sticks around. So does the old branch, the extra test, and the question nobody wants to answer.

Hosted cleanup checks connected repositories for eligible flags, prepares removal PRs, and keeps checks and follow-up work visible. Each new candidate starts the cycle again.

Your team sets the policy and reviews the changes. Adoption and cleanup are separate workflows today; you can start with cleanup before a migration, too.

Explore cleanup Check removal support

Inspect before you commit

Start with the evidence.

Read the generated changes. Check the exact boundaries. Start with the right scope.

Inspect an example migrationGenerated diff, input, checks, and full assessment Check your migration pathAssessment, preview, draft PR and verification Open-source scannerRead the code on GitHub ↗

Before you begin

Good questions.
Straight answers.

Talk to the team

Does this let us leave LaunchDarkly completely?

The current pilot moves supported application evaluations to OpenFeature while retaining LaunchDarkly as the runtime backend and flag-management system. It does not migrate flag configuration or perform a backend cutover. You reduce vendor-specific application code now; a complete provider exit is a separate project.

Which languages and SDKs can you migrate?

Support depends on the exact source SDK, runtime, and stage. Assessment, code preview, draft PR publication, and verification have different boundaries. Check the current support matrix for your stack before requesting access.

Check migration support

Will FlagShark merge changes automatically?

No. The adoption workflow produces validated previews and controlled draft pull requests. Your team reviews and merges them using your existing branch protections. Unsupported cases and missing evidence remain explicit blockers.

Can we remove dead flags during a migration?

Hosted cleanup can propose eligible flag removals separately. The current adoption pilot and cleanup workflow are distinct. We will review removal opportunities when scoping your migration; a combined automatic removal-and-migration workflow is not currently promised.

What is free, and what is paid?

The open-source Action detects flag references and posts findings on pull requests. Hosted cleanup manages removal PRs and their lifecycle. Migration Autopilot is a limited pilot with separate approval and onboarding, not part of the self-serve cleanup plans.

See cleanup plans and pilot access

What access do you need?

Assessment starts with repository access. Provider evidence uses a connected LaunchDarkly project; code-only assessment leaves provider-dependent questions unassessed. Publishing a draft PR is a separate permission boundary. Review the exact data handling and access requirements before connecting.

Read security and permissions

Your next move

Find your path
to OpenFeature.

Tell us about your SDKs and repositories.
We’ll review pilot fit, scope, and the next step with you.

Request migration assessmentLimited pilot. Separate approval and onboarding.Just looking for the free scanner? Start here

Your flags.
Your code.
Your choice.

Free your code from vendor-specific APIs. Move supported LaunchDarkly calls to OpenFeature through reviewable PRs, then automate obsolete flag cleanup.

Pilot: LaunchDarkly Node.js · JavaScript / TypeScript
LaunchDarkly stays your backend.Check support for your stack

import * as ld from '@launchdarkly/node-server-sdk' const FLAG_KEY = 'new-checkout' const client = ld.init(process.env.LD_SDK_KEY!) export async function enabled(): Promise<boolean> { await client.waitForInitialization() return client.variation( FLAG_KEY, { key: 'customer-1', custom: { plan: 'pro' } }, false, ) }

Temporary flags.
Not permanent baggage.

The feature ships. The flag sticks around. So does the old branch, the extra test, and the question nobody wants to answer.

Hosted cleanup checks connected repositories for eligible flags, prepares removal PRs, and keeps checks and follow-up work visible. Each new candidate starts the cycle again.

Your team sets the policy and reviews the changes. Adoption and cleanup are separate workflows today; you can start with cleanup before a migration, too.

Your flags.Your code.Your choice.

From vendor-specific codeto a change you control.

Start with the code you have.

What does yourmigration look like?

Get the scope beforeyou make the move.

Find it. Remove it.Check it’s gone.

Temporary flags.Not permanent baggage.

Start with the evidence.

Good questions.Straight answers.

Find your pathto OpenFeature.

Your flags.Your code.Your choice.

From vendor-specific codeto a change you control.

Start with the code you have.

What does yourmigration look like?

Get the scope beforeyou make the move.

Find it. Remove it.Check it’s gone.

Temporary flags.Not permanent baggage.

Start with the evidence.

Good questions.Straight answers.

Find your pathto OpenFeature.

Your flags.
Your code.
Your choice.

From vendor-specific code
to a change you control.

What does your
migration look like?

Get the scope before
you make the move.

Find it. Remove it.
Check it’s gone.

Temporary flags.
Not permanent baggage.

Good questions.
Straight answers.

Find your path
to OpenFeature.

Your flags.
Your code.
Your choice.

From vendor-specific code
to a change you control.

What does your
migration look like?

Get the scope before
you make the move.

Find it. Remove it.
Check it’s gone.

Temporary flags.
Not permanent baggage.

Good questions.
Straight answers.

Find your path
to OpenFeature.