OpenFeature Adoption

Move supported application calls to OpenFeature through a reviewed migration. The current first-release focus is LaunchDarkly server-side Node.js/TypeScript, with LaunchDarkly retained as the runtime backend.

What changes

FlagShark assesses supported SDK usage and can prepare application call, initialization, context and dependency changes for its admitted Node migration contract. Your code calls OpenFeature; the configured LaunchDarkly OpenFeature provider still evaluates the flags. Targeting rules and flag definitions stay in LaunchDarkly.

Changing the evaluation backend or transferring flag configuration is a separate migration. OpenFeature adoption alone does not remove the runtime service dependency or its commercial agreement.

Availability and support

As of September 10, 2026, this is a scoped pilot. The source registry includes Node migration stages through post-merge verification; production access still requires pilot admission and a compatible repository assessment. Other stacks may have assessment or preview support only. Use the support selector for the current published stage projection and confirm the assessed support contract before proceeding.

SDK versions, runtime, module format, call shape, key/default/context semantics and lifecycle matter. A detected SDK is not automatically migratable. Unsupported wrappers, ambiguous provenance and dynamic patterns receive explicit blockers instead of speculative edits.

Review workflow

1. Request a migration assessment with your language, runtime, SDK and representative usage. Do not submit credentials in source examples or contact messages.
2. Establish authorized repository access and, where required, the retained provider/project binding. Code-only assessment cannot establish provider runtime state.
3. Review the scoped assessment and immutable preview, including unsupported files and required validations.
4. Run the declared validation. Unavailable required checks remain blockers; a generated diff is not proof of behavior preservation.
5. Publish the exact reviewed change as a draft PR when the assessed stage and permissions allow it. Source drift requires reconciliation.
6. Review CI and merge through your normal human-controlled process. Post-merge verification checks the actual default branch and reports residual or unsupported usage within its scope.

The homepage example is synthetic engine output for inspection. It is not a deployed customer migration or release certification.

Cleanup after adoption

Ongoing removal has a separate support contract. Existing OpenFeature JS/TS cleanup remains limited to its admitted draft stage. The new TypeScript boolean-call candidate has local migration, validation and post-merge verification coverage, including compiler-proven immutable constant keys. It is not yet a generally available verified-cleanup release.

Automatic removal also requires fresh terminal-state evidence and proof that the deployed application's SDK credential and options target the inspected LaunchDarkly project and environments. A management API connection alone is insufficient. Missing or revoked proof blocks cleanup. The first runtime-binding adapter targets explicitly configured published AWS Lambda deployments with trusted build provenance; other deployment styles require their own adapter and certification. Pilot provisioning and the complete live customer journey remain release requirements.

See cleanup boundaries and custom flag libraries.