This blog was created from a recent episode of Device42’s podcast, The Hitchhikers Guide to IT. You can find the latest episodes here.
In the U.S., less than half (49%) of companies have a dedicated IT service management (ITSM) solution with predefined processes, while globally 57% do. Yet, more than nine out of 10 executives want to improve this critical function over the next 12 months.
In a recent episode of The Hitchhiker’s Guide to IT podcast, Clayton Chancey, Enterprise Solutions Architect for Cprime, joined Host Daniel Litwin, the voice of B2B at MarketScale. The topic of the day? The growing enterprise trend of migrating an on-premise IT service management (ITSM) platform to the cloud.
Host Litwin said that while companies want to take advantage of the flexibility of cloud solutions, “not all IT professionals may have a go-to strategy for such a lofty transition.” He and guest Chancey discussed common misconceptions, red flags to watch out for, and different integration approaches to make a cloud ITSM migration a successful reality.
Chancey’s career has spanned help desk and IT system administration, working as an Atlassian administrator and developer, and then serving as a platinum consulting partner for Atlassian. He has leveraged his past experience working for cloud-native and cloud-first companies to support Cprime clients, which include Fortune 100 and Fortune 500 companies seeking to adopt cutting-edge IT service management tools. Cprime is an IT service management company offering consulting, managed services, and custom IT solutions.
Preparing to Migrate ITSM Tools to the Cloud
So, what should IT professionals consider as they prepare to migrate ITSM tools to the cloud?
Chancey said it’s important to understand both what the migration isn’t – and what it is. He said that many individuals want to do lift and shift migrations – which take existing architectures and data stores and drop them in the cloud. They think they’ll work the same as before, which isn’t realistic.
According to Chancey, working in the Atlassian cloud will be different, especially when it comes to Jira Service Management tools and configuration management databases.
“The two architectures have slightly different features. The path to getting over there is going to be complex, and you’re going to need to involve different methods of moving that data over for different types of data. And so you can’t just lift and shift. Jira data, for example, by itself, just your tickets, your issues, stories, bugs, might be a little bit more of a lift and shift. That’s one thing, your Jira data. But the Jira Service Management and the CMDB metadata is a completely different story,” said Chancey.
Migrations are an opportunity to make improvements. While choosing a different path to the cloud can introduce more risk and complexity, it also provides an opportunity for IT to increase business value by adding new capabilities.
“Often, this push to cloud architecture can serve as a catalyst for process refinement. So your team should be thinking about, “Hey, is our incident management workflow something we’ve been frustrated with for a year and it’s kind of hard-coded into the tool that we’re using, but we’re okay with it. Well, let’s not just lift and shift that faulty or unreliable workflow that’s hard-coded into your tool. Let’s use this migration as an opportunity to fix that workflow,’” said Chancey.
Migrations can cause disruption, Chancey said. So teams should plan the path forward well to avoid inflicting unpredictable change on end-users.
How to Engage Stakeholders in Executing Successful Cloud Migrations
To plan migrations, IT teams or their partners need to execute an in-depth assessment.
“A lot of times, what’s overlooked is the need to obtain buy-in from your various stakeholders. So we may get all the technical requirements that we would need to do a lift and shift type move, but have we really got buy-in from the folks who are going to be using this new platform… [Are they] excited? And a lot of times, unfortunately, users aren’t excited for the migration,” said Chancey.
IT teams should use the assessment phase to gather business requirements and to obtain buy-in from all key stakeholders. It may not be realistic to strive for 100% buy-in, said Chancey. However, gaining buy-in from 75%-80% of these individuals can help create collective will to change.
IT teams can help build this momentum by helping stakeholders understand how their contributions flow up the chain and help achieve corporate goals. For example, IT service management (ITSM) technicians may be tempted to resist the migration, because it will negatively impact their personal mean time to resolution (MTTR) metric. However, IT teams can help these professionals understand how the new system will provide better metrics that help senior leaders make critical decisions, which could end up generating better work assignments for the technicians.
“And there’s going to be a big sort of tug of war between different motivations, different ideologies within the IT space. This is a great time period, this assessment phase, to really wrestle with your values as an IT organization. That way, when you pull the trigger on the migration to the cloud, you’re alive and you’re ready and excited to get to that next state of your platform,” Chancey stated.
Migrating CMDBs to the Cloud
The conversation turned to use cases for cloud migrations. Chancey said that configuration management databases (CMDBs) are one of the more complex for companies to operationalize.
As an example, organizations operating an on-premise Jira Service Management solution, can “execute custom groovy code,” he said. “You’ll be able to automatically use all the great import modules in the asset management feature of Jira Service Management. You’re going to reach out to your LDAPs [lightweight directory access protocols] and your Jamf and Intune and get all your devices synced right in there. You don’t really need any plugins to do that, said Chancey.
However, in the cloud, there are more limitations around executing custom code, because providers have multi-tenant architectures.
“So you’re not going to be able to run the same types of groovy scripts or Python scripts or all these crazy, cool customizations that you could do on-prem. There [are] good reasons for that, but that might limit some of the integrations that you’re trying to accomplish between Jira and your other systems, maybe [Cisco] Meraki, Okta, you name it,” said Chancey.
“Some of the import modules that exist inside JSM itself and that assets feature also have limitations. So the out-of-the-box LDAP connector is not there in [the] cloud. Some of the other out-of-the-box import modules are not there. There’s actually a little bit more configuration, more expertise, more technical knowledge that’s required to integrate between Jira Cloud and some of your endpoint platforms or CMDB platforms. And then even the other workarounds that you could develop, you’ve got automation rules that come out of the box. You have middleware solutions like Workato or Zapier, ConnectOL, MuleSoft. You’ve got scripts running on intermediary servers. So maybe you’ve got a Python script that’s running on some server somewhere, and it’s making API [application programming interface] calls over here, pulling in data and then pushing it to Jira,” he added.
As a result, IT teams will need to design more streamlined, maintainable integrations, Chancey said. They will typically spend significant time during the assessment phase considering what actually needs to be integrated, which can be a challenging process.
“I keep mentioning these Python scripts that are making API calls out. Sometimes if you’re just an endpoint and your Jira instance is just getting API calls that are made into it, it can be difficult to figure out where that information is even coming from. You may be assuming that Jira tickets are being created manually by your users or that assets are being synchronized from a CMDB system like Jamf or [Microsoft] Intune or Cisco Meraki,” said Chancey.
“And they may not be, they may just be being pushed in by a script that breaks the minute you go to [the] cloud,” he added.
Making Decisions About What Stays On-Premise
Host Litwin noted that this means that IT teams should identify which tools don’t need to be moved to the cloud and can stay on-premise. He asked if IT teams are comfortable managing hybrid infrastructures and if they should capitalize on the opportunity to create new standards to manage two sets of tools.
Chancey said that was a great question and shared a potential scenario of migrating an on-premise Jira platform to the cloud, where it is not cost-effective to migrate mobile devices for another 18 months. In that example, help desk technicians would need to increase their bookmarks, ask callers which phone model they’re using, and possibly authenticate with another program to address tickets. “There’s going to be another cloud application that …. actually it isn’t being synchronized with Jira and you need to go out and access that information there and then perhaps manually copy and paste some of that over into a Jira ticket,” Chancey said.
As IT teams consider these issues, they’ll evaluate how the user experience is impacted, costs, timeframes, and how delaying integrations will impact key metrics.
“The bottom line is we’re doing what’s right for the business. And so the migration, even though it can seem like a simple thing, when we have CMDB and ITSM in the mix, it can become very complicated. So that prioritization of what integrations we’re going to move over and what integrations we may not move over, it’s a set of hard decisions. And you really need to get by them from everyone who’s involved,” said Chancey.
How to Prioritize Integrations
Chancey gave advice on how to prioritize integrations. IT teams should consider what data the integration provides and who uses it.
He gave an example of a client that integrated its CMDB with Jamf to categorize all the MacBooks and Apple devices it operated. Since executives didn’t derive meaningful data from the integration, their impulse was not to do it. However, the organization’s help desk technicians supported the marketing department, which exclusively used Mac and Apple devices. They reported back that not integrating with Jamf would increase their MTTR by 40% on these tickets, and that marketing tickets made up 60% of the incidents they processed on a weekly basis.
“So that spoke the executive level’s language. And they go, “Oh, OK, we better work and prioritize this Jamf integration, even though it’s going to be technical,’” said Chancey.
Other issues to consider are how frequently the integration is used, whether it is standard or custom, and how difficult it is to maintain. IT teams will typically want to reduce complexity wherever possible, unless the custom integration is supporting business-critical processes.
Chancey gave an example of an integration supporting an application monitoring system like SolarWinds. SolarWinds checks the uptime and downtime of critical applications, such as ecommerce platforms that produce a significant amount of revenue. If SolarWinds detects a device outage, it immediately creates an incident ticket in a company’s ITSM platform, so that the IT team can prioritize resolving the issue.
However, IT teams should also consider if they are able to redesign processes to avoid an inefficient integration altogether. They may be able to bring another tool into the Atlassian suite to provide needed capabilities, eliminating the need to integrate the process altogether.
“And so there’s a certain amount of change management, like we mentioned before, that comes with making these decisions while you’re migrating. You don’t want to completely reinvent every wheel on the car at the same time. But in some cases, actually redesigning and streamlining your processes might remove the necessity of integrating at all and then it takes something off of your backlog. So I would think through those sorts of questions when you’re prioritizing your integrations and your APIs,” said Chancey.
After making these decisions, teams will then analyze data. CMDBs organize asset data via schemas. Different schemas may provide data on employees, locations, and other attributes; assets; applications and software licenses; and software components and development tools. IT teams should consider these schemas and their metadata, including objects and object types, to determine which need to be moved and which will be replaced with a new process.
Chancey gave an example of Jira data. Tracking objects means tracking tickets, which have fields, custom fields, and issue links between tickets and relationships with CMDB objects. All of these items need to be migrated to the cloud, as well as the CMDB data.
Then the Jira system would need to be configured with workflow conditions and automation rules to power ITSM activities. “It’s not the actual data itself, but it’s the configuration that makes it work and live and breathe and serve the company and deliver value,” said Chancey.
Next, IT teams would need to consider the reporting processes ITSM systems support. That report may live in the application natively, such as a Jira dashboard or a Jira service management report. Or it may require an integration to an external platform like Tableau or Microsoft Power BI or be a plugin like eazyBI for the Atlassian suite. Any reports that are migrated to the cloud will also require a data migration.
IT teams will use different techniques to migrate report data from on-premises to the new cloud architecture. They can use the Jira Cloud Migration Assistant (JCMA), a tool in the Atlassian suite, to port Jira on-premises data over. However, the tool won’t bring over CMDB data, advanced roadmap information, or other metadata. To move that data, teams should use the JCMA tool and CSV (comma-separated values) files that contain lists of objects and attributes, such as scripts and custom development work that query the API on the old system. They’ll then post that data in its correct remapped format to the API of the new system.
Another possible strategy is to use the Site Import method to do a big-bang migration of an entire instance. However, IT teams will have to use other techniques to route data, application links, and integrations to the right places. They’ll likely have to do a major CSV import, API to API integrations, and configuration work with the JCMA tool. This type of migration can require a stressful weekend of work and testing to make sure systems work correctly by Monday morning, Chancey.
Planning for Large-Scale Migration Projects
Host Litwin asked Chancey for final thoughts he wanted to leave with the audience.
Chancey urged listeners not to get intimidated by cloud migrations; gain buy-in from all key stakeholders; and work together with their team in a collaborative, iterative fashion.
“Think about how you’re going to deliver that value in the best possible way as a result of this migration. So the outcome’s centered rather than just pulling the trigger on something that you’ve been maybe told that you need to do. We’re really focusing on what’s the outcome that we’re seeking here. And this will kind of steer the way that you perform that migration to be something that really does deliver value and really does execute successfully,” said Chancey.
