OpenFeature in NestJS: Migrate Your LaunchDarkly Feature Flags Service by Service
The problem with migrating LaunchDarkly feature flags in a NestJS codebase is the same as every other migration problem: you don’t know what you’re dealing with until you’ve already touched something.
NestJS services are injectable, which means direct LaunchDarkly SDK calls end up scattered
across services, controllers, and guards — each one evaluated inside an injected class with
its own lifecycle. You can grep for ldClient and get a rough count, but grep won’t tell
you which call sites use dynamic flag keys that block automation, which ones call
variationDetail and need a different OpenFeature API, or what fraction of your call sites
can be rewritten without any manual review. You need a measurement before you make a plan.
This guide covers the complete cycle: audit the LaunchDarkly flag debt in your NestJS source, wire in the OpenFeature provider as a shared NestJS service, run a safe automated rewrite, and add a CI gate that blocks new direct LaunchDarkly SDK calls going forward.