Bionic to Horizon Rules Migration Experience!

Great to hear a success story! I had posted in the community Slack channel a couple months ago a document I put together to help track migration progress (for an overall view of the JIRA tickets involved) that might be a helpful aid to organize and operationalize the above strategy, or something similar: https://docs.google.com/spreadsheets/d/1KodnegMQKtsZHLjvg4LmCIwv2sRdtFTSO-MyjwA0IDQ/copy

This is basically a template for our roadmap, and can be dialed up or down depending on how much effort/time you want to put into it.

@melissa_davenport @mark_walseth Check this out! 

Thank you so much for partnering with us and sharing your success story, Kathryne and thank you Bradley for sharing that awesome sheet! 

Keep the tips, tricks, best practices, etc. coming! 

Hi Kathryne,

Thanks so much for sharing your experience! Can you elaborate more on how you leveraged  Gainsight Analyzer & Designer to consolidate rules and Data Designer to maximize the potential of our rules in the new environment?

Thanks,

Rhonda

@rho_ran_experian Sure! Analyzer helped us identify where certain fields were being used, where they were coming from, etc. which helped us figure out where we could consolidate / combine multiple use cases into a single rule, instead of having them spread out across a handful of rules. As a result, we had fewer rules to migrate which helped speed up the process, but also left us with a simpler rules engine in the end.

Additionally, using Data Designer assisted in an easier transition from bionic to horizon rules since the feature has many similarities to what is offered in horizon rules. In other words, it helped to prime us on the capabilities of horizon rules.

@rgupta91 in case I’ve missed anything important!

@bradley That’s a great template for the migration process, thanks for sharing!

Hi Kathryne, curious why you had to ‘Conduct test runs and meticulously compare data outputs to ensure a successful transition.’?

Is it because you expected to find issues with the migrated rules? On our end, I was hoping to migrate a few rules of different complexity and if no issues were found, then migrate the rest in bulk without a QA. Side note: We have about 430 rules and 2 admins

I know there are still a lot of bugs being worked out so I was wondering if that was the reason for the extensive planning. 

Thank you,

Jasmina

I can share my view on this: I participated in the Beta for Horizon Rules and there were feature gaps between the two engines. Additionally, when migrating a few test rules to try out the migration tool, there were again issues with migration where I would have unexplained failures, or worse, “successfully migrated” rules that had problems requiring a total rebuild, support ticket, or waiting entirely.

In some cases I’ve even found migrated rules to give different results for the same set of filters as a Bionic Rule or a manually build Horizon Rule.

Because there are some advantages of horizon rules (such as Snowflake as a Data source and ease at getting picklist values instead of IDs, for example), some rules can also be optimized to run better in Horizon vs Bionic rules, so I also take the opportunity to streamline if possible.

I will, at minimum, do a test run of the original and migrated rule and compare results, and I plan on keeping the originals as long as I can once the Horizon versions are in production, just in case.

 @jivanova To Bradley’s point, we had a few rules where the feature gap issue came into play, particularly with filter operators for us. There were certain filter configurations in bionic rules that horizon rules didn’t like, so we would make the necessary adjustments. This only happened in a few rules.

To answer your question, after migrating a rule we would test run it before turning it on to run live. Once the test run was complete, we would do a general comparison of the number of records that passed between the latest live bionic run and the test run. We did this mostly so we could ensure that the horizon rule was performing the same as the bionic rule (based on # of successful records) which gave us the confidence to switch the horizon rule live and turn the bionic one off. We did keep the bionic rules in a separate folder in Rules Engine just in case something went wrong with the horizon rule, but we didn’t come across a need to turn any of the old rules back on and ended up deleting them a few weeks after we fully migrated to the horizon experience.

Having only 2 admins to migrate 430 rules is quite a big task. We migrated over 100 rules with 1 admin, and it was done over the span of a few months, one by one, folder by folder, test running each one just to be sure things would run smoothly. We had too many important processes and automations dependent on our rules to bulk migrate them all especially without QA. If you can slim down your 430 rules at all, that could help speed up the migration process - it definitely helped us!

Let me know if you have any other questions 😁