Moving From an On-Premise ITSM to a Cloud ITSM Platform with Clayton Chancey

(Intro:)

Welcome to another episode of Hitchhiker’s Guide to IT podcast, brought to you by Device42. On this show, we explore the ins and outs of modern IT management in the infinite expanse of its universe. Whether you’re an expert in the data center or cloud, or just someone interested in the latest trends in IT technology, the Hitchhiker’s Guide to IT is your go-to source for all things IT. So buckle up and get ready to explore the ever-changing landscape of modern IT management. 

(Host:Daniel Litwin)

Hello everyone and welcome to another episode of the Hitchhiker’s Guide to IT podcast series brought to you by Device42. I’m your host Daniel Litwin, the voice of B2B. And folks, thanks so much for joining us on another episode of the show. As you are getting today’s insights and lessons, make sure that you’re heading to our website device42.com. Again, that’s device, the number four, the number two, dot com, and make sure that you’re subscribing to the Hitchhiker’s Guide to IT on Apple podcasts and Spotify. Just hit that subscribe button and you’ll have a full catalog of previous conversations as well as notifications when we drop new episodes of the show. So let’s jump in. On today’s episode of the show or today’s chapter of the Hitchhiker’s Guide. We’re going to be sharing our lessons learned for migrating a traditional on-prem IT service management solution to a cloud version of a similar or same solution. More and more companies are having their IT teams take advantage of the flexibility of cloud solutions for IT management, but not all IT professionals may have a go-to strategy for such a lofty transition. So we’re here to smooth over some of those misconceptions or mysteries, right? And pass along some strategic advice for your own transitions. And after getting our go-to strats in about 30 minutes or less, you’ll know what red flags to keep an eye out for when moving your IT ecosystem to the cloud. You’ll better know the differences and integration approaches for on-prem versus cloud solutions. And you’ll have a guideline for prioritizing your integrations and determining what actually needs to be part of the transition. So let’s get started, folks, to guide us for today’s episode. We are joined by our special guest, Mr. Clayton Chancey. He’s an enterprise solutions architect for C Prime, which is an IT service management company offering consulting, managed services, and custom IT solutions. Clayton Chancey, great to have you on, man. How you doing today? 

(Guest: Clayton Chancey)

I’m great. Thanks for having me. 

(Host:Daniel Litwin)

Absolutely. Real pleasure having you on the Hitchhiker’s Guide to IT here today. Before we get into the meat of the episode, let’s get a little intro on you. So I know your career in the field started out doing help desk and IT system administration’s work. Then you worked as an Atlassian admin and developer, as well as a platinum partner for consulting on Atlassian. Can you give us a little more of a breakdown there, just the rest of your career, some of your touch points as of late, and how they tie into today’s conversation points, right? Break down how your experience relates to today’s chapter of the guide. 

(Guest: Clayton Chancey)

Yeah, well, I’m from the West Coast. I’m from LA. And when I worked over there, I first cracked into the consulting space over there. And there’s a lot of startups who are very cloud first, always migrating to cloud, always trying to push to get this cutting edge technology, take advantage of the industry trends. And then when I moved over here to the East Coast and started tackling a lot of clients and use cases here, it’s a very different set of clients, set of use cases, much more monolithic, much larger organizations, a lot slower to turn the ship around. But the industry is still pushing them to make those same changes, to go to cloud, to have obviously cutting edge IT service management tools. And so I’ve been able to put to practice some of the same techniques, same experience in very different use cases, really. And so it’s been exciting to get to do that for a number of different Fortune 500 and Fortune 100 companies throughout my time at C Prime. 

(Host:Daniel Litwin)

Fantastic. Thanks for the context there, Mr. Clayton. Now let’s get into it. So let’s start pretty high level, the go-to things to keep in mind. What would you say are some of the core, most critical things to look out for when you’re moving your ITSM tools from on-prem to the cloud, and more specifically to Atlassian cloud? 

(Guest: Clayton Chancey)

Yeah, I think there’s… I like to think of it in two ways. One would be knowing what your migration is, and then knowing what it isn’t. And what it isn’t is just as important. When you’re migrating to the cloud, a lot of people throw around the term lift and shift, meaning let’s just take the data that we have in our on-prem architecture, lift it up, shift it over to the cloud, and then drop it down. And we really shouldn’t see anything different between the two platforms. And as anyone who’s ever really done a migration before knows, it’s not a super realistic expectation. And the Atlassian cloud is no different, particularly when you’re talking about Jira service management, any of your ITSM tools, I’m talking about configuration management database or CMDB. It’s not a lift and shift. 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. So that’s what your migration isn’t. It usually isn’t a lift and shift. What it is, is an opportunity to change things. And I think a lot of people get scared of that because the migration typically isn’t a time period where people want to undergo change. You’re actually trying to minimize change when you’re going through a migration typically. But it’s an opportunity for your IT teams to increase their business value. It’s an opportunity for your middle managers, your IT directors, and those sorts of personas to better support the executive level. It’s basically an opportunity for you to get stuff that you don’t have on your on-prem architecture and try to build that in because your migration is a key inflection point. You’re moving to a tool that has different capabilities. And also, this push to cloud is not and at least shouldn’t be a project without a reason behind it. 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. Because when we get onto our new platform in the cloud, we’re actually using a better tool as well. And so we’re not trying to create a lot of churn and inflict a ton of unpredictable change on our users. We do need to minimize that and we need to manage that change. But at the same time, you want to treat the migration as an opportunity. So that’s kind of what it is and what it isn’t. And those are, I think, at a very high level, some of the things that I want folks to keep in mind when they’re migrating ITSM tools over to the cloud architecture. 

(Host: Daniel Litwin)

So what are your thoughts there on how different layers of a company, whether it’s the IT team, middle managers, executive level, can all kind of work together to turn that transition away from a burden and actually into an opportunity to improve processes across the board and maybe even identify some pain points that could be addressed as part of a larger transition? 

(Guest: Clayton Chancey)

Well, I mean, everything you’re saying really speaks to the need for an assessment phase or a discovery phase. And that is a typical part of most migration efforts, whether you’re like me, a consultant doing this work for someone else or whether you’re an IT contributor within your own organization doing it. But 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 that they’re excited? And a lot of times, unfortunately, users aren’t excited for the migration. There’s a maybe cost is a factor pushing us to the cloud or people at a higher level in the company see the need for cutting edge cloud first solutions, but folks that are reporting to them, maybe a little further down the IT ecosystem don’t echo those sentiments. And so the assessment is a time period not just to gather technical requirements, but to gather business requirements and to obtain buy-in from all these stakeholders. If you can’t obtain buy-in, everyone at every level should be asking, is this worth it? Is this good if we’re not really bought in? You’re never going to get 100% buy-in realistically for anything you do unless you’re a startup with five people in it. But even if you can get 75%, 80% buy-in, then it may be a good move. And so we want everyone to be thinking about how this move helps us achieve our goals and helps other personas in the IT organization support their goals. So a help desk support technician, which is how I started out my career, may have a temptation to just think, man, I’m going to have to learn a new system, I’m going to spend a month ramping up on stuff. It’s going to slow down my mean time to resolution metric, which is what my bonus is maybe generated off. And so that’s maybe that persona. But it’s important for those types of individuals to think about what kind of metrics are reporting is my boss getting? Maybe it’s the director of the IT organization. How can he see and better incentivize me to work on the higher priority tickets, sort of IT managers? And that goes all the way up to CISOs, VP of ITs, all those sorts of personas. How is this change impacting others? How is it empowering me? So everyone needs to work together to obtain buy-in for this migration. 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. 

(Host: Daniel Litwin)

If you do the legwork to align, to create synergies across teams and across different silos within IT teams, too, you know, not even just from, you know, between executives in the IT team, just among the team itself. Yeah, it makes the transition not the point where now you have to address inconsistencies and buy-in, but it makes the transition the point of executing on an already level playing field. So totally agree there. Let’s get some more use cases, right? Let’s kind of get your perspective, but from in practice experience, you mentioned CMDB integrations. Could you fill us in on some other considerations that you’ve learned along the way from, you know, or excuse me, when moving from on prem, excuse me, to the cloud in the context of specifically CMDB integrations? 

(Guest: Clayton Chancey)

Yeah, CMDBs are really great use case because they’re one of the more complex use cases or feature sets or capabilities to actually migrate to the cloud. So there’s a lot of things to keep in mind because there are different approaches that you can take when doing CMDB work, CMDB configuration in on prem versus on cloud. So if you’re used to working, I’m thinking of like a JIRA data center, an on prem Atlassian instance, and maybe you have JIRA service management on your data center and it’s on prem, you’ll be able to execute custom groovy code. 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 and your Jamf and Intune and get all your devices synced right in there. You don’t really need any plugins to do that. When you go to the cloud, there are naturally on the cloud infrastructure, a lot more limitations around the execution of custom code, right? Because you can’t execute your custom code in a multi-tenant architecture like Atlassian. That’s not going to be secure for any of Atlassian’s other customers or for you. 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’s 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 Meraki, Okta, you name it. 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 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 Workata 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 calls over here, pulling in data and then pushing it to JIRA. All of that is going to have a lot more limitations when you go to the cloud. And so it doesn’t mean that you shouldn’t move to the cloud. It just means you’re going to have to design a much more streamlined and maintainable set of integration. So that’s one of those big things to think about. And that kind of leads, you know, most of the teams I work with, those considerations lead them to ask the question, well, what really needs to be integrated then? Because there’s a lot of work that could be done and you could dive down 15 different rabbit holes, which for someone like me are all very fun, but they may not all be cost effective or time effective. So what needs to be integrated? And frankly, it can be extremely tricky to even identify what is integrated today. In the example of this, you know, some of the, 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 Intune or Cisco Meraki. And they may not be, they may just be being pushed in by a script that breaks the minute you go to cloud. So you really need to have that assessment phase where you’re having conversations with the other folks in IT, you’re really deep diving and double clicking into as many topics as you can to identify your existing integrations. I think it highlights the importance of being very detailed and thorough in your discovery, not just to obtain buy-in, but then even going back and just getting your technical requirements fleshed out. So all of those are the kind of things you would want to think about when you’re moving a CMDB because there’s going to be a lot more moving pieces than if you were just strictly moving JIRA tickets over to the cloud. Now you’ve got integrations to other systems that also have to be configured on that new platform. 

(Host: Daniel Litwin)

Obviously that means then that if you’re prioritizing certain integrations or you are making that assessment of what even needs to be integrated and consolidated in the first place, that there will be some tools identified as, actually this doesn’t need to be migrated to the cloud. It’s fine on-prem, works fine on-prem and may actually cause more challenges or take too long or just be inefficient to also be part of this transition. Do you find that teams are comfortable handling that sort of dual infrastructure once the transition is done? And kind of like with that end state in mind, how do you make the transition also an educational session or a chance to create new standards for how to manage both pools now of tools?

(Guest: Clayton Chancey)

Right. I mean, that is a great question because it goes back to the importance of design in your enterprise application ecosystem. So if we all, our source of truth system was maybe on-prem JIRA and the IT help desk folks were really just looking in that one application and now we’ve realized, well, all of our mobile devices are managed by this other platform over here and the integration is not going to be cost effective for us to replicate on cloud for another 18 months. Now we’re going to have to say, all right, well guys, now your list of bookmarks is going to increase by at least one because when you’re trying to solve customer tickets that come in and you need to know what phone model this person is referring to, that’s not going to be in the same window. That’s going to be a new tab. You’re going to have to do another click. You’re going to have perhaps authenticate with another program. There’s going to be another cloud application that’s not just being synchronized with JIRA, but 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. And so that’s where the importance of buy-in comes in. As you’re designing these types of migrations, as you’re performing this assessment phase, you really need to be thinking about the user experience at all levels, not only for customers, but for the actual agents, IT agents who are triaging tickets, IT agents who are resolving tickets, developers who are involved in the resolution of an incident or the execution of a change. All of these people are going to be interacting with these systems. So that is exactly what you need to bear in mind when you’re prioritizing. And that’s the trade-off that you’re making when you say we’re going to de-prioritize this integration. It’s not just how many hours of work does it take and is it cost-effective. It’s also how long will this or how much will this increase our mean time to resolution for issues? Who’s looking at that report? Who cares about those metrics? How is it affecting us as a business? And that’s 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. 

(Host:Daniel Litwin)

Yeah. And like you said, having the workflows in mind first and foremost, how will the folks that now have to maneuver the new tools or the new architecture behind the tools and the ecosystem that supports them, how will that look on Monday when this is finally done? Wow. Man, if it takes one weekend to achieve, that would be a pretty great transition. But yeah, no, right, like getting the team and their workflows as one of the top priorities behind the integration or to not integrate decision is key. So with that in mind, you kind of teed me up perfectly here. How would you then approach migration? How would you approach prioritizing your integrations and your APIs? What kind of questions do you have to ask yourself as a team lead here, as someone on the decision making team? Go ahead and break that down for us. 

(Guest: Clayton Chancey)

Yeah. So when it comes to prioritizing those integrations, I think some of the questions you might ask yourself would be, what kind of data does this integration provide and to whom does it provide that information? So I’m thinking of a use case with one of my clients where we integrated with Jamf. And this is a way of categorizing all the MacBooks and Apple devices in the organization. And it was a little bit of a difficult integration at that time. This was a few years ago. It’s actually quite a bit easier now. But what kind of data does this provide? The executive level really didn’t get any meaningful information out of that. So their instinct naturally was going to be, well, let’s just not integrate it. It’ll take a long time. But the help desk technicians who service the entire marketing department exclusively using Macs and Apple devices went, oh, man, if we don’t integrate with Jamf, this is going to increase our mean time to resolution on these tickets by, and they came up with some statistic data driven decision making. It’s like a 40% increase in MTTR for these marketing tickets. And marketing tickets make up 60% of the incidents that we process on a week to week 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. And it’s going to be difficult to accomplish. So what kind of data does this integration provide and who’s processing or ingesting that data? Another question would be, how frequently are we actually using this integration? Is this something that someone, if they want to, if they need the information, is pushing a button and drawing information? And we’re really only using that info maybe once a month. Or on the other side of the spectrum, is this something like it’s actually integrating with Okta or our HR systems? And this is running every few minutes or every hour. And when a new hire comes into our company, the IT ticket that represents their onboarding process is actually mastered by an integration to Okta. So how frequently are we using this? That’s another thing that would obviously potentially bump something up or down in the list of your prioritized integrations. Another thing which we kind of alluded to a little bit here is, alluded to a little bit already here, is how complex or easy to maintain is this integration? So is this completely custom integration? It’s not like a plug-in that we bought. It’s not an out of the box feature. It’s not middleware. It’s like a Python script that’s sitting on someone’s laptop in a data center running 24 hours. Well, should we prioritize trying to replace that integration or should we deprioritize that and say, we’re not moving in that direction. We want to get rid of those sorts of integrations. Another way of phrasing many of these questions would be looking at it from the negative. If we didn’t migrate this integration over, what would be impacted? An example I can think of there would be an integration with your monitoring systems, application monitoring systems. So if you have an integration with SolarWinds, and SolarWinds is checking the uptime and downtime of critical applications your business uses or maybe an e-commerce platform that is a direct correlation to revenue your company is bringing in, and if something goes down, it creates an incident in your system and that rallies all of your IT team to tackle the incident and resolve it as soon as possible. Well, you have to integrate SolarWinds with your new platform. There’s no not integrating that. So what would be impacted? That’s a good question to ask. And obviously, the answers there are going to vary depending on the platform and who needs it. And then I think another related but different question that as a consultant to me is very interesting is if we redesigned the way that your ITSM processes work, could that remove the necessity of this integration altogether? And so there are a lot of integrations that people have that may be inherently inefficient. The data is just stored over there somewhere in a big database or a data lake, and that’s why we have to integrate it. And if you ask the question, well, what if we brought it into the Atlassian suite or what if we brought it into another tool that could handle it? Well, we wouldn’t need to do that integration anymore. And so there’s a certain amount of change management, like we mentioned before, that comes with making those 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. And then when it comes to actually now implementing, because we’ve talked a lot about the assessment phase, how we would ask some of these questions. I think the next step is really determining what data needs to be moved. So we’re looking at various types of schemas and collections of data. We’re thinking about when we’re thinking about a CMDB, we should be thinking about asset schemas. So we may have one schema in our CMDB that points to people and locations and employee attributes. And maybe that’s synchronized with your HR tools and with Active Directory. Now that may be a very separate schema from the one that looks at your assets, your physical assets, laptops, switches, access points, and so on and so forth. And then you may have other schemas that look at applications and software licenses. And software components and pieces of development work that your team is doing. So these may all be different schemas. You’re not necessarily lifting one thing and moving it over. They’re actually going to be different schemas. So you would want to consider that as well as all the metadata with all of those different objects and object types in each of those schemas. Some of those may not need to be moved. Like we said before, we may be replacing some of that functionality and some of that schematic with a new process. And so which schemas, which objects actually need to be migrated, you’re obviously going to be migrating your JIRA data as well. So the actual work tracking objects, this would be like issues in JIRA, tickets. You’ve got fields and custom fields and issue links between different JIRA tickets. You’ve got the relationships between CMDB objects and JIRA tickets. All of these are basically the ticket data. And so you need to migrate that as well as the CMDB data. And then the third area would be the actual JIRA configuration itself. So not CMDB configuration, not the tickets themselves, but workflow conditions, automation rules, all those sorts of things that are sort of the engine powering all of the ITSM activities that are going on. 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. And so you’ve got all these different things. And all of those things may or may not need to be migrated to meet your objectives and to be successful. So you’ve got to make some deliberations about which projects are we moving, which schemas are we moving. And then the layer on top of all of that, which much of this would be a moot point without this would be your reports and your metrics. Because as we all know, these complex systems, sometimes impenetrably complex systems are often simply driving a report that demonstrates value. And so someone somewhere wants to read the story about what this system is doing for us, about what these teams are accomplishing for us, about the revenue we’re bringing in or the value we’re delivering to our customers. And all of that is typically visualized in a report. That report may be in the application natively. So that may be like a JIRA dashboard or a JIRA service management report, or it may not be. That may be another integration to an external platform like Tableau or Power BI or a plugin like EasyBI for the Atlassian suite. So all of those things need to be considered as well. Which of these reports are we bringing over to our new process? We need to migrate all of that data. All of these are the conversations that need to be had, the assessments that need to be sort of conducted, the buy-in that needs to be obtained. And then actually moving the data over from the old on-prem architecture to the new cloud architecture is going to be a combination of techniques. There are two basic categories of techniques for how you would move the data over. One would be, and this is in the Atlassian suite, one would be the JIRA Cloud Migration Assistant, which is a tool that Atlassian has developed. It’s kind of a wizard tool that Atlassian has developed to port over JIRA on-prem data over to the new cloud. And it’s going to do a lot of the heavy lifting for you, but it is not going to bring over all your CMDB information. It’s not going to bring over all the advanced roadmaps information. There’s going to be a lot of other metadata, like we’ve talked about, that’s not strictly JIRA issue data. And you’ll need to find another additional technique for bringing that over. So it will always be the JIRA Cloud Migration Assistant plus some other technique. And that could be a series of CSV files that contain lists of objects and attributes that you’re then going to upload into the new system. That could be scripts and custom development work that’s querying the API on your old system, and then posting that data in its correct remapped format to the API of your new system. Somehow, some way, you’re going to need to use the JIRA Cloud Migration Assistant plus these other techniques. And your migration teams and your custom development folks are going to help you develop those techniques in a way that makes sense for the fields and the scope that you’ve developed in your assessment. The other potential method would be not using the JIRA Cloud Migration Assistant, but using what’s called the Site Import method. And this is what you would usually use when you’re moving the whole instance over. No ifs, ands, and buts. We’re not picking projects. We’re not picking teams. We’re not doing a phased migration. We’re not doing wave one and then waiting two weeks and then doing wave two. We’re going to do a big bang, huge migration over a single weekend or a couple of days or whatever. Then you would use the Site Import approach. And you’re basically taking the entire JIRA instance, ripping it up, and then dropping it down in the cloud. Now that sounds like a lift and shift, which I said earlier is not possible. And that’s because indeed, the Site Import method, when you drop that thing down, some of those routes aren’t going to go into the right places. You’re not going to have all your CMDB data just plugged in magically to your new system. And so the same thing applies. It’s going to be Site Import plus a series of other techniques like a giant CSV import, like API to API integrations, all the same configuration work you’d have to do with the JCMA tool. You’re probably going to have to do with your Site Import tool as well. So that’s kind of the way to think about actually moving the data over is you’re using these base techniques that help you get the base application, the Atlassian applications over into their infrastructure. That’s going to be your 75%, 80% of your JIRA ticket data, your historical team work items, all those sorts of things will get into the cloud. And then you need to bring the CMDB stuff, the links, the integrations over by a series of various techniques. And then after that’s done, you’re always going to have to set up the new system correctly. So you’ll have some maintenance window. Maybe it’s at 3 a.m. on a Monday morning. That’s what it was for me last weekend when I did the most recent of these. But maybe it’s hopefully a little bit more reasonable hour. But you’re going in, all the data is there. And now you’re going to set the thing up and you’re going to configure your integrations, your application links, you’re going to get Ops Genie and JIRA and Confluence all integrated together in the cloud. You’re going to flip the switches and push the buttons that you need to as a system administrator to get this thing ready for Monday morning when users are logging in. So it’s a huge approach. It’s a huge effort. There’s a lot of questions and there’s a lot of work associated with it. But if you do it right, you can actually, I know it feels mythical, but you can actually have that Monday morning where the users log in and go, hey, this is pretty good. I don’t really have any bugs to submit. My CMDB is working. I can tackle an incident. And you know what, it’s actually even better than it was on Friday at 4 p.m. when I was handling the last issue of the day. It is possible. So those are the things I would consider in order to achieve that type of an outcome. 

(Host:Daniel Litwin)

Maintain hope, folks. It is possible. I love it. Well, you basically covered everything there for us. Thank you so much, Clayton. We again, folks, we got a breakdown of how to prioritize your integrations, actually determining what data needs to be moved and then how to actually move that data over some strategies for creating those guidelines and executing. So Clayton, thank you so much for your thoughts. Let’s go ahead and wrap things up. Any final words of wisdom, excuse me, or just any sort of final tips or tricks that you want to leave our audience with? 

(Guest: Clayton Chancey)

Yeah, I think it’s just the overall guidance of don’t be intimidated. This can happen. It does happen every day with really large organizations and really small organizations. And all you need to do is get buy-in from everyone. Work together with your team, make it collaborative, make it iterative. 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.  And if you’ve been listening to me talk and talk and talk about all the different things that you could be thinking about and you go, well, I kind of want to see this. What would this look like with some of these actual applications? This is what this webinar is for. It will be on many of these same topics and it will have some screenshots, some real concrete use cases, some examples that you can look at and say, OK, this is the kind of work Clayton’s been talking about and what it would look like on my screen as I’m performing it. It’s going to be a little bit longer form than this podcast would be and go into more concrete detail. So if you’re interested and your interest is piqued, we would love to see you there. 

(Host: Daniel Litwin)

And where can folks find that? Just on C Prime’s website? 

(Guest: Clayton Chancey)

Yeah, C Prime’s website. And then it will be posted out on LinkedIn and obviously any of those social networking platforms that C Prime uses for advertising. Perfect. 

(Host: Daniel Litwin)

All right, Clayton, I think that does it. So thank you again to our guest here, Mr. Clayton Chancey, Enterprise Solutions Architect for C Prime. Clayton, I appreciate you giving us this how to guide on transitioning your ITSM solutions from on prem to the cloud and like Clayton mentioned, go to C Prime’s website for more resources and that webinar specifically so you can see some of this in practice and start to visualize your own transition. Clayton, thanks again. We’ll be in touch and looking forward to chatting again soon. 

(Guest: Clayton Chancey)

Likewise. Thank you so much for having me. 

(Host: Daniel Litwin)

And thank you, everyone, for tuning into this episode of the Hitchhiker’s Guide to IT, a podcast brought to you by Device 42. If you like what you heard and saw today and you want some previous episodes or you want to make sure that you don’t miss out on future conversations, make sure you’re heading to our website, device42.com. Again, that’s device, the number four, the number two dot com or subscribe to the Hitchhiker’s Guide to IT on Apple podcasts and Spotify. And you’ll never miss more chapters of the guide. I’m your host, Daniel Litwin, the voice of B2B. And we’ll catch you on the next episode of the Hitchhiker’s Guide to IT.