Considering making the switch?

Switching feature flagging platforms—whether from LaunchDarkly to Statsig, or just in general—is a significant move that can improve workflows, improve feature management, and give your team's experimentation culture a fresh start. Like any migration, though, it requires careful planning and execution.

In this guide, we'll walk you through the process of migrating your feature flags from LaunchDarkly to Statsig, including additional considerations and basic instructions to ensure a smooth transition.

Understanding the migration process

Migration is more than just a technical task; it's a strategic opportunity to refine your processes and embrace a new platform that can streamline your feature flag management. Here's what you need to know:

What migration is not:

• An automated process

• A direct transfer of every single flag from your old platform to the new one

• A process that necessitates an immediate and complete switch-off of the old platform

What migration is:

• A chance to clean up tech debt and optimize your feature flagging strategy

• An opportunity to educate and empower your teams for faster adoption of the new platform

• A process that involves taking stock of existing metrics and data sources for measuring feature impact

• A project that requires technical setup and integration of necessary data sources

Conceptual considerations

The distinction between experiments and feature flags

On LaunchDarkly, everything is a feature flag, and feature flags may have variants and return different types. Statsig deliberately distinguishes between feature gates (for immediate action) and experiments (for deeper inquiry). They can be used together or separately.

On Statsig, feature gates are purely boolean. When deciding to ship a feature, this becomes a matter of flipping a switch. There are no variables within the feature that must be altered or replaced.

Separately, Statsig supports a structure called Dynamic Configurations.

Using feature flags with LaunchDarkly that may contain many variants, and that may return multi-type dynamic configurations, introduces a layer of complexity that can obscure the path to full implementation:

When the time comes to transition to full deployment and remove the flag, references to those dynamic configurations need to be replaced, introducing potential points of failure and delaying the shipping process.

This necessitates extra diligence and refactoring that could have been avoided with a simple boolean check. And, as we all know, teams may already be slow in cleaning up feature gates.

More than a matter of convenience, this is a strategic approach that enhances decision-making clarity, accelerates the release process, and helps cultivate true experiment culture without slowing down development speed.

Environments vs. projects

In Statsig, the hierarchy is designed with a single project that contains multiple environments, such as Development, Staging, and Production. This structure allows for centralized management of feature flags and experiments across different stages of development within the same project, simplifying access control and reducing the complexity of handling multiple API keys.

Conversely, LaunchDarkly adopts an Environment > Project hierarchy, where each environment can be considered a separate project with its own set of feature flags.

The key difference lies in the centralization versus separation of environments: Statsig centralizes environments within a project for streamlined management, while LaunchDarkly treats each environment as a distinct project.

Defaults

Currently, false is the global default option for feature flags in SDK. If you want the default to be true, you may consider inverting the gate check logic. For Experiments in Statsig, defaults are provided in code.

Authentication

Are you using SSO? Are you assigning custom roles via SSO? If so, read on.

Currently, we haven’t hooked role definition into auto provisioning yet. For automatic provisioning with SSO, new users authenticated by Okta can be automatically provisioned into a Statsig organization.

If your project within the organization is set to open, users will default to having access. For private projects, they must request access.

Each JIT-provisioned user would have member access. You will to update their roles manually/via API. It’s a similar pattern with teams and roles right now.

This is on our roadmap. (Inquire if you're interested in early access.)

Planning your migration

Inventory and decision-making

Start by reviewing your current feature flags in LaunchDarkly, and shedding some technical debt:

• Temporary flags: Identify flags used for rollouts that are no longer active. These can be removed to reduce tech debt.

• Permanent flags: Determine which flags are essential for ongoing operations, such as kill switches or targeted functionality, and plan to migrate these to Statsig gates.

Technical considerations

• Codebase review: Have you built any wrappers or abstractions on top of LaunchDarkly? This can simplify the migration to Statsig.

• Flag volume: Assess the number of flags to determine how much automation is possible. We have automated ways to migrate most segments and boolean flags into Statsig today. We have an automated import tool in our product and an open-source script you can extend to import nonboolean flags (to experiments and dynamic configs) and metrics if necessary.

• Training needs: Identify training requirements for different teams and plan sessions accordingly.

Statsig vs Launchdarkly, head to head

Wondering how Statsig stacks up against Launchdarkly in a feature comparison? We've got the data.

Let's compare!

Metrics and event tracking

Ensure that your key metrics and event tracking are ported over to Statsig. Statsig supports integrations with various data warehouses, CDPs, and analytics providers, making it easy to continue measuring the success of your features and experiments.

Executing the migration

Step-by-step approach

1. Clean up: Remove any unnecessary temporary flags from your codebase.

2. Migrate permanent flags: Use Statsig's tools to migrate boolean feature gates and most segments, then manually migrate any more bespoke configurations that the script didn’t handle.

   1. We offer two solutions to help automate/kick-start this process:

      1. A UI-based wizard to help you import LaunchDarkly feature flags and segments into Statsig. It will tell you which gates and segments were migrated and which weren’t.

      2. An open-source script template that migrates feature flags from LaunchDarkly to Statsig. This is a good option if you want to customize the integration logic. It will also spit out a CSV of all of your LaunchDarkly flags, along with migration status and relevant URLs to the flag in LaunchDarkly and the gate in Statsig.

3. Integrate data sources: Connect Statsig with your existing data and analytics systems for seamless metric tracking.

4. Communicate & educate teams: This is probably the most important factor in a successful transition. Train your teams on using Statsig and establish new workflows for feature flag management.

Post-migration

1. Monitor and optimize: After migrating, keep an eye on your feature flags' performance and make adjustments as needed. Gather feedback from the team and iterate as necessary.

2. Phase out the old platform: Gradually reduce dependency on LaunchDarkly until you can confidently switch off the old platform.

We’re here to help!

Migrating from LaunchDarkly to Statsig is a strategic move that can lead to more efficient feature flag management and a stronger experimentation culture. By following this guide, you'll be well-equipped to make the transition with confidence.

Remember, Statsig's team is always ready to assist you throughout the process, ensuring your migration is successful.

Request a demo

Statsig's experts are on standby to answer any questions about experimentation at your organization.

Grab a Demo

Related reading:

• Documentation: Migrating your feature flags from LaunchDarkly

• Statsig vs LaunchDarkly, head-to-head feature comparison

• Why Motion's Head of Engineering replaced LaunchDarkly with Statsig