Migrating from Heat Classic to Ivanti Service Manager

Are you planning to move from Heat Classic to Ivanti Service Management
Here is what you need to know…

Lets get started with the basics. On January 23, 2017 Clearlake Capital Group announced it had completed the acquisition of LANDESK. In conjunction with the transaction close, LANDESK and HEAT Software announced the two organizations have united under a new corporate name: Ivanti.

Ivanti Service Manager (ISM), powered by HEAT, is the most affordable, flexible, and complete cloud-optimized ITSM solution available on the market today. With its ability to automate workflows, eliminate costly manual processes all while allowing a business to become more efficient, compliant, and secure.

Whether you’re looking for an IT help desk/support ticket solution or need to perform more advanced ITIL service management processes, Ivanti Service Manager (ISM) can easily scale and adapt to meet your specific business needs.

Until now there has not been a clear upgrade path for migrating from Heat Classic to Ivanti Service Manager. ISM is a new state-of-the-art service management product that provides ease of use and flexibility in implementation and configuration.

So why make the move?

  • ISM is web-based so you don’t have to worry about client installs!
  • ISM is adaptable to your organizational requirements!
  • ISM is scalable!
  • ISM has a great history of feature and product support!

So how do you make the transition?

What you are reading is part 1 in a series of articles that create a workshop we will use to identify the requirements to migrate from HEAT Classic to Ivanti ISM. Over a series of blog posts and videos, we will discuss our proven methodology for migrating HEAT Classic (or any other service application) to Ivanti Service Manager.

What is the expectation?

Keep in mind that there will be required adaptations since ISM is structured differently than HEAT Classic. The graphic description below shows the key differences in terminology.

The key difference is that Heat Classic uses “Call Log” for all “Service” related items, whereby ISM uses separate modules for Incident, Service Request, and Change. The bulleted list below provides a brief overview of each:

  • Incident: Break/Fix
  • Service Request: New Feature/Service/Equipment
  • Change: Change to an existing Feature/Service/Equipment

To begin the workshop we will start with a set of basic questions. This will help us help us develop the requirements and scope for the ISM migration.

Through interactive discussion with the client we begin to get a clear understanding of their environment:

  • What is the existing service management application? In our case we are assuming HEAT Classic.
  • How many service desk analysts are active on the system at any given time?
  • Do they utilize self-service capabilities and how many users access self-service capabilities?
  • How is the company organized and what is the user landscape? How many locations, employees, teams, etc. are involved?
  • Are there any specific security requirements or special considerations?
  • If using HEAT Classic, can we acquire a copy of their database so that we can perform additional investigation?

Ivanti ISM has Two Hosting Options

Software as a Service (“SaaS”) (hosted by Ivanti) or On-Premise (hosted by the client)

  • SaaS: With the SaaS option all application servers and databases are maintained and hosted by Ivanti. This provides for a lower total cost of ownership (“TCO”)
    Note: Integration with your local domain, ADFS, or other local applications may require a VPN Tunnel.
  • On-Premise: With this option the client will need to provision servers. A Configuration that can support up to 50 analysts consists of a SQL Server and 2 Application Servers as outlined in the table below:

Workflow Definition

The next step in our workshop will be an examination of the clients existing HEAT Classic System from an overall workflow perspective.

A thorough demonstration of the clients existing HEAT Classic System will help us identify functionality that falls outside ISM’s out-of-the-box features.

The HEAT Classic review and demonstration should include such items as:

  • Call Type: This corresponds to the type of issue within ISM which could relate to Incident, Service Request, Change, etc.
  • Categories: This corresponds to the service in ISM.
  • Quick Actions: Quick actions may correspond to Templates or Quick Actions in ISM.
  • Call Log Detail Screens: These are based on the type and Category of the Call Log and would loosely correspond to the Workspaces that we use within ISM. Let’s take a break/fix as an example. In ISM this would correspond to Incident while Heat Classic Call Types are associated with Service Request, Change, etc.
  • Notifications: Notifications are used to inform clients and teams of Call Log progress. The same concept exists in ISM.
  • Integrations: HEAT Classic and ISM both use integrations to LDAP, Email, etc.

With an understanding of the existing environment and requirements, we begin to develop a concept of how ISM will be leveraged.

Let’s say that we will need Incident, Self-Service, and Service Request. How do these features compare with Heat Classic? We will go through each of these “Workspaces” and note how they work natively and then identify where we can adapt them to suit our needs.

In the screenshots below you can view examples of the HEAT Classic Call Log Workspace. We can see client information and details of the Call Log based on the Call Type and Category. As we continue to reference additional differences, you will see some other screenshot examples of how ISM differs from HEAT Classic.

ISM – Example of the Incident Workspace: The screenshot below depicts the ISM Incident Workspace. Here we can see Client Information, Notes, Escalations, Status, and additional information as needed.

ISM – Example of the Self-Service Workspace: The image below is an example of the “Self-Service Workspace” in ISM. This interface provides easy access for creating new incidents and service request offerings in addition to the status of existing Items.

ISM – Example of the Service Request Workspace: The Service Desk Analyst can easily create new “Service Requests” or manage “Service Requests” created by “Self-Service”.

Training Requirements

During our workshop, we identify the necessary administrative and support staff training that is essential in taking full advantage of ISM. The bulleted list below outlines our typical training recommendations.

  • Administrator Training: We recommend that your ISM Administrators be exposed to the application prior to the workshop. This will allow them to acquire the skills they need to understand the implementation and maintain the application. Training is available through the Ivanti Global Academy.
    https://www.ivanti.com/services/training-certifications
  • Courses of interest:
    ILT-SMC-1701: Service Manager Configuration – 2019
    CE-SM-2017: Certified Service Manager 2017 Administrator Exam
  • Knowledge Transfer with Professional Services: During the project, knowledge transfer will occur between our consultants and the assigned client resources. This is not a replacement for formalized training however it does provide a great deal of awareness. We also encourage the participation of Administrators during the Configuration Phase.
  • Support Analyst Training: Support Analysts are generally brought in after the Configuration Phase before making the system live to users.

An important consideration is understanding your options for preserving existing data. We finish with the question.

Do we need to preserve existing data and what is the best way to do so?

We recommend that you keep the your HEAT Classic system in place and but make it unavailable for users to access once ISM is live. This way your history prior to ISM will always be available for any auditing or reference needs.

Note: There is a migration tool for HEAT Classic that can be used to move Call Log data into Ivanti ISM in a special “read only” Call Log Workspace. This tool has limited capabilities and functionality. The use of the “Migration tool” is beyond the scope of our workshop series. 

Please contact us if you have questions!

In my next blog post, I will outline additional aspects of our ITSM methodology discussing the design elements of your ISM implementation. As always, Critical Design Associates will be here to assist you through every step of the process.

Sincerely,

Bill Davidson
Senior Consultant
Critical Design Associates

LinkedIn Profile