Best Practices When Migrating Feature Flag Tools

Migrating from one tool to another is never the easiest process in the world. This is especially true when it comes to developer tools that are hooked into your application or deal with your infrastructure. Engineering and DevOps teams often avoid switching to better platforms just to avoid the pain of the migration and the bugs that can come with it.

When it comes to migrating feature flag tools, though, we’ve found that it’s really not as big of a deal. In this blog, we’ll take a look at why that is, and what you should keep in mind as you look ahead to your next feature flag management solution - hopefully ours (on that note, keep your eyes peeled in our DevOps tools pages for product comparisons between Harness Feature Flags, Optimizely, LaunchDarkly, Split.io, and more - coming soon!).

One quick note before we get into it: all of this advice applies to both commercial solutions as well as internal solutions. If you’re looking for more specific advice on how to leave behind your homegrown feature flag solution, we have a two-part series specifically on how we did that - the product side and the technical side.

Identifying Short-Term vs. Long-Term Flags

The first thing to think about when it comes to migrating feature flag tools is to do a bit of an inventory on the types of flags you have today. 

First, identify which flags are temporary. These are flags that are currently serving a purpose, usually used as part of your rollouts, or new code deployments or as part of experiments, but that will eventually expire and be deprecated.

Next, identify which flags are long-lived, or permanent. These will be your ops/feature toggles, account management flags, and other flags that are intended to stick around in the product for the long haul, such as flags related to infrastructure.

It’s important to know the difference between these two types of flags, because you won’t handle them the same in the migration.

Build Forward - Don’t Replace

The reason separating your flags by longevity is important is: for short-term flags used for rollouts and testing, which for most teams will be the vast majority of your flags, we don’t recommend migrating at all.

Feature flags aren’t like Continuous Integration (CI) or Continuous Delivery (CD) tools, in the sense that you don’t necessarily need a hard cutover at a fixed date all at once. You can’t use multiple CD tools at once on the same project because it will break your deployments, but you can use multiple feature flag tools in your codebase without risk of any downtime or bugs.

For the bulk of your feature flags, the short-term ones focused on rollouts, experiments, and canary testing, we recommend building forward on the new solution. Let the old and new solutions coexist, put all new flags on the new system, and deprecate your old flags as their utility expires. Eventually, you will be able to easily turn off the old solution without investing in any cumbersome migration or replacement effort.

The only flags you will need to truly migrate will be your long-lived flags. In this case, you have a smaller subset of flags and you will mostly only need to swap out the conditional statement defined by the SDK, or whatever code path is controlling the toggling. 

If you’re migrating to Harness Feature Flags, we can help you bulk-create all necessary flags via API to avoid the time-intensive process of creating them one by one. 

By doing it this way, you avoid the excessively painful - and filled with complexity and risk of introducing critical bugs - part of most tool migrations: the part where you need to guarantee everything will keep working while you change the engine out mid-flight.

If You Have to Cut Over 

Occasionally, we do hear about a team that simply has to cut over solutions all at once. A contract renewal is coming up, or the only engineer who knows how to maintain the old system is leaving. A contract renewal is coming up, or the only platform engineer who knows how to maintain the old system is leaving. Luckily, these scenarios are few and far between, but the change, in these cases, needs to happen right away.

The advice in this case is not that different. First, do a pass and see how many flags are still in use. Do you have a lot of legacy flags in there that you can just remove? Oftentimes, we find the answer to that question is yes.

Once you’ve determined which flags need to come with you to the new solution, you will need to begin replacing the code path conditions with the SDK of your new solution. This can take some time, but is usually not the most difficult process and shouldn’t require any downtime - though you will want to verify the behavior is as expected at the end of the process. And, we’re happy to help if you need - just get in touch with support. As above, we can help with APIs to bulk-create flags so that you can all-at-once add the flags you’ll need in Harness.

Don’t Forget Enablement 

One last note when thinking about migrating: don’t underemphasize the people side of it.

When we migrated off of our internal solution and into Harness Feature Flags, we realized how easy it is to forget about the longer trail of internal processes that can be built around feature flags over time. 

It’s very likely that there are people that use feature flags, are dependent on flags, are used to changing flags, or even teams that have built functionality dependent on flags that may be undocumented and that you’re not aware of. Because of this, it’s important to make sure you get feedback from every potential stakeholder early in the process to ensure that you’re not missing some current use-cases for feature flags.

Conclusion 

Migrating feature flag tools isn’t without any friction, but because it can be done over time, using your new and old solutions concurrently in your codebase, it is much easier than you might think (and requires no infrastructure-level changes) - and certainly quite a bit easier than most other types of software development migrations! 

The benefits of feature flags are far and wide, as Google, Netflix, Facebook, and tons of other leading tech companies can attest. Being able to run A/B tests before rolling out new features to your entire user base is amazing - but there’s so much more than feature flags can do. If you’re not into feature flags yet but are considering it, we recommend reading another piece we’ve written: 5 Feature Flag Use Cases You May Not Have Thought Of. Sneak peek: one of them has to do with one of our favorite topics - metrics!

If you need any help, or want to discuss how we can assist in planning your migration, get in touch with support now! And if you’re just getting started on the feature flag path, learn more about Harness Feature Flags today.