At GreenLight, we are often asked how customers should change one piece of software to another. For various reasons, customers need to do so - they could be changing vendors, or the vendor provides an updated/new solution on a different architecture, or the customer has finally approved a project after numerous years, and now they need to modernize.
In 2020, GreenLight was asked to work with an existing customer to help them migrate from a legacy Service Management solution to a newer version. However, due to resources and funding, the project needed to be split over multiple budget cycles, the result of which was that we could not move all work out of the old system.
We had to devise a plan to get maximum value from the new solution without retiring the old system until the budget could be obtained to finish the transition.
Normally, when dealing with moving from an oldIT service management system to a new one, there are two approaches:
a) “Big Bang”: move everything all at once with a big Go Live
b) “Phased”: a process-by-process move from the old to the new. Many times, Request Management is chosen to move first, followed by Incident, Problem Knowledge, and ultimately Change Management. Service Asset and Configuration Management (SACM) is constantly in a state of change in this model, as there are some SACM components and data needed for most of the ITIL processes.
There are pros and cons to each approach, but due to the customer’s budgetary constraints, it was collectively agreed to start with a subset of Request Management. Specifically, the End User Self Service Portal would be the first - and only - thing to move in 2020. The Self Service Portal was chosen for its broad visibility across the entire company. If implemented with an integration to the old IT service management system, it would allow Request Fulfillment to be performed out of either the old or the new system. This led to a low-cost second stage to slowly migrate ALL Request Fulfillment into the new system. Additionally, this served as a contingency plan if funding could not be provided in 2021 since progress could still be made migrating from old to new.
Over the years, I have been involved in writing similar Case Exchange-style integrations, where there are basically two systems that must represent the same Request. These spanned many ITSM technologies such as HP OVSD, Peregrine ServiceCenter; CA Service Desk, ServiceNOW, and numerous others. After joining GreenLight Group in 2012, I have seen still more of these efforts for customers.
Having been part of many ITSM integrations between different ticketing systems over the years, I knew there were a handful of use cases that would need to be implemented in this current effort:
The UPDATE operations have numerous variances. Comments, for instance, should only be sent from the old system to the new system if the “visible to customer” attribute is set by the fulfillment engineer when entering the comment into the old system.
Of course, there would be problems to solve, such as how the extremely customized approval process in the old system would be implemented in the new system, as well as other issues to be identified. None of the forecast’s challenges were unsolvable technical problems, so it was agreed that the project would move forward and build a stable solution that would support a larger migration effort. This would also support the rest of the ITIL processes at some point in the future.
By the time the project’s Go Live had arrived in mid-2020, we had successfully implemented a new and modernized portal from the new system for end-user consumption.
The result was a reduction of more than 30% in Service Catalog offerings - reduced through combining many offerings together to improve the end-user experience - and the creation of a custom integration to support all the customer’s use cases and process variations.
The integration was written using modern webhook-style methodologies, leveraging NodeJS, running in a containerized environment, utilizing almost 10,000 lines of JavaScript code in NodeJS, many branches of source code in the GitHub repo, including branches for DEV, TEST, and PROD, defect resolution, new functionality creation, etc.
If you’d like to read more about how we managed branches for this project, we based our model off of the “Environment Branches with Gitlab Flow” section of https://docs.gitlab.com/ee/topics/gitlab_flow.html#environment-branches-with-gitlab-flow
Below are a few graphs from just after Go Live from our GitHub repo. Like many projects, this one became more complex as it went on!
