Gainsight's Internal Horizon Rules Migration

We at Gainsight have been working through our internal migration to Horizon Rules in recent months and I wanted to share with the admin community what has worked well for us.
NOTE: This is a post with general advice on how to handle the migration to Horizon Rules and structure it as a set of tasks, not specifics related to the nuances of, say, the Amazon S3 import process. I am happy to answer any questions that I can, general or specific, in post replies!

Bottom Line Up Front: If you are a large enterprise Gainsight CS customer (or just very mature with your CS processes and team) with more than about 100 rules, don’t try to migrate everything all at once. 

Here’s how we came to that conclusion:

1. It’s tempting to view our Horizon Rules migration as a singular, overarching process with the goal of moving rules from one version to another as quickly as possible, and with that migration being the chief focus of a major operational project. 
   1. For a customer with high complexity of processes, possibly multiple admins, and a relatively large CS Ops org, that would functionally derail or block your overall CS Ops development pipeline for weeks or months. That is not a fair ask from us to you, or even a fair ask of ourselves. 
   2. We have CS operational needs that far exceed the perceived ROI from a more responsive and stable Rules platform, or the unification of disparate processes that comes from many rule overhaul projects. The SaaS market has been heavily disrupted by multiple headline events this year, and we have urgent changes that cannot wait several months.
2. You might think at this point: For an organization with several admins, why not have one migrate the rules while others continue to focus on urgent business priorities? 
   1. The answer is fairly simple - doing so would handicap one admin’s skillset relative to the others, and diminish or eliminate the effects of a cohesive team’s differing skills and approaches. It’s not Human First. 
   2. Additionally, Bionic Rules won’t be around for long, and our whole team, with varying degrees of skill, familiarity levels with Data Designer’s UI, etc, are invaluable as additional beta testers of Horizon Rules.

So we said we won’t do the migration as a single, roadmap-blocking project, and we won’t assign a portion of the team to do it while others focus elsewhere. What IS Gainsight doing then?

Our team is continuing business as usual in terms of following the CS org’s strategic priorities, but we are migrating the rules we are rebuilding or troubleshooting whenever we can, and we’re not building anything in Bionic Rules unless we find a show-stopping bug that prevents us from using Horizon Rules. We also haven’t seen any show-stopping bugs since August.

In practical terms, when we plan our ops sprints, we add 2 hours to the time estimate for any tasks related to rule creation or modification in order to either rebuild a rule from scratch or use the Bionic to Horizon Rules Migration Tool, and we are being extra careful about our SLAs for internal admin tickets as adhoc migrations are adding time there as well. When we use the migration function, we’ve noted that not only does the migrated rule’s activation deactivate the original, but it also clones the original rule’s schedule.

So this is all a plan, but how well is that working? 

• Our cutover date was August 17th. Since then we have created two new Bionic rules that remain scheduled today, and both are clones with variations that are part of a complex process that was just out of scope for mundane troubleshooting. They also happened in those first two weeks after the cutover.
• In September and October we created zero new Bionic Rules. We created about 40 Horizon Rules in that period, about 20 per month, though the number is growing.
• We have probably 400 more rules to move. That might seem pretty worrying if our current pace were to continue! We have no intent of waiting 2 x 10 = 20 months to finish our Horizon Rules migration, however. 
  • Many sets of rules are essentially (like many scorecard rules) 10-15 clones of the same process with slightly different source data on each, and so those will move faster.
  • We also anticipate doing some additional testing as Horizon Rules migration tools continue to improve. 
  • I suspect we will have some actual migration projects towards the end, mostly to move big, critical processes with low margin for error, all at once. It’s also possible, however, that we will roll those migrations into our annual and semi-annual revisions of those processes (Scorecards, usage data, Stakeholder Alignment, etc.)

Overall, we have been happy with the progress. The team is generally pretty comfortable with Horizon Rules now, we have learned the workarounds and new motions required in the new UI, and we are most importantly not dreading further migration and able to provide valuable internal feedback that will hopefully make this even easier and faster for each of you. ♥️