Migrating from Ivanti Service Manager to ServiceNow

Moving from Ivanti Service Manager to ServiceNow means transferring incidents, problems, changes, requests and configuration items between two systems. The work starts with a data inventory and mapping, because ISM records often carry custom fields and status values that do not match ServiceNow defaults. The page then covers process translation, cutover, validation, staff transition and handoff.

Understanding Ivanti Service Manager Architecture and Data

Ivanti Service Manager (ISM), built on the HEAT platform, manages IT service delivery through incident, problem, change, and request management modules. The system stores configuration items (CIs) in a comprehensive CMDB, typically including IT hardware, applications, and business services. Organisations running ISM often rely heavily on the CI relationships and impact analysis features that flow through change management approvals. The data model is relational, with many interdependencies: incidents link to CIs and problems, changes link to CIs and may trigger related changes, and requests track fulfillment through workflows. Custom fields and extensions are common, particularly in large deployments where ISM has evolved over many years.

Ivanti’s architecture includes workflow engines that can create complex approval chains and conditional routing. Many organisations have built incident routing rules, change approval matrices, and problem investigation workflows directly into ISM’s configuration. Custom tables and views extend the standard data model. If your organisation uses Ivanti’s IT Asset Management (ITAM) module alongside Service Manager, asset data will need to be inventoried separately as migration planning begins.

Data Inventory and Mapping Strategy

Begin by extracting a complete data snapshot from ISM: all incident records for the period you plan to migrate, problems, changes, requests, and CIs. Quantify the volume of each record type, since volume drives migration effort. Analyse the distribution across status values; ISM often accumulates large numbers of closed incidents that ServiceNow environments wish to archive. Examine custom fields attached to core tables: ISM frequently uses custom fields to augment incident data (cost centre, business impact ratings, customer segment), and these must be either mapped to ServiceNow fields or dropped after stakeholder approval.

Map ISM’s data structures to ServiceNow equivalents. Incidents map directly to ServiceNow incidents; the challenge lies in status values (ISM uses statuses like “assigned”, “pending”, “on hold” that may differ from ServiceNow’s default “new”, “in progress”, “resolved”, “closed”). Problems in ISM map to problem records in ServiceNow, but the workflow and approval logic may differ. Changes map directly, though ISM change categories may not align exactly with ServiceNow’s. Requests are more complex: ISM request management may serve different purposes (IT service requests, internal HR requests, facilities requests), and ServiceNow typically handles these in a single request fulfillment module with catalog items as the primary construct.

CI data requires careful attention. ISM’s CMDB may contain thousands of CIs, many stale or duplicated. Validate the asset data against a current CMDB snapshot or IT asset management system before migration. Decide whether all CI records are worth migrating or whether a clean CMDB refresh makes sense. Relationship data between CIs (hardware depends on network, applications depend on databases) should be exported and validated; ISM relationships often become brittle after many years of changes.

Process and Workflow Translation

ISM’s service management processes often reflect the organisation’s IT culture as it stood when ISM was implemented and customised. Incident routing rules in ISM might assign based on assignment group, priority, or incident category; these translate into ServiceNow’s assignment group logic and assignment rules. Problem management workflows (problem creation, investigation phases, root cause analysis, implementation) should be documented from ISM and recreated in ServiceNow; the module is similar but workflow automation points may differ slightly. Change management is the most complex: ISM change approvals often involve multiple stakeholders (CAB approval, peer approval, vendor approval) with conditional logic; ServiceNow’s workflow engine supports this, but the implementation details require careful attention.

Examine how ISM handles knowledge management and runbooks. If ISM contains knowledge articles or solution articles used by support staff during incident resolution, these should be migrated to ServiceNow’s knowledge management module. Many ISM implementations have scattered knowledge in custom tables or as attachments; prioritise high-value content that will directly improve ServiceNow’s efficiency.

Cutover Planning and Validation

Plan a cutover window aligned with the organisation’s service window: a weekend or planned maintenance period when the volume of new incidents and requests is low. Parallel running is impractical for service management because it requires support staff to log incidents in both systems simultaneously, creating confusion and duplicate records. Instead, plan a flag day cutover: ISM remains production until the cutover date, then transitions to read-only mode whilst ServiceNow becomes the primary system. Cutover typically spans a single business day or a long weekend.

Before cutover, run full test migrations at least twice: once to validate data extraction and loading, and a second time to validate that transformed data loads cleanly and that reference data (assignment groups, categories, priorities, status values) aligns correctly. Assign a validation team to check data samples across all major record types and confirm counts match between source and target. Create a detailed cutover playbook that covers data extraction from ISM, data transformation, ServiceNow load, index rebuilding, and rollback steps if issues arise during cutover. Test rollback procedures at least once in a non-production environment.

Support Staff Transition and Acceptance

ISM support staff have learned ISM’s interface, search capabilities, and workflow over many years. ServiceNow’s interface and capabilities differ; plan formal training sessions covering incident creation and update, knowledge search, problem and change submission, and reporting. Early access to ServiceNow allows power users to become familiar before cutover; consider making a sandbox copy available for a period before go-live so support staff can practice workflows. Appoint superusers in each support team who can mentor peers and escalate questions during the first weeks post-cutover.

The first week after cutover will uncover issues: data that did not migrate cleanly, workflows that require tuning, and features support staff relied on in ISM that require a different approach in ServiceNow. Plan for extended support availability and a rapid-response incident management process to handle cutover issues. Most organisations experience a temporary increase in incident volumes post-cutover because new users are learning the system; staff the service desk accordingly.

Handoff Criteria and Stabilisation

Define success metrics before cutover: data completeness (percentage of incidents, problems, changes, and CIs successfully migrated), accuracy (spot-checks confirming data integrity), and performance (query response times, report generation times matching or exceeding ISM). Declare stabilisation achieved when the organisation has run a complete incident management and change management cycle in ServiceNow, no outstanding critical issues remain from cutover, and support staff proficiency reaches acceptable levels. How long this takes depends on how many issues the cutover exposes. After stabilisation, turn off ISM access to prevent confusion and drift between systems.

Knowledge content is the part of an Ivanti move that users read every day

For many organizations the knowledge base in their Ivanti Service Manager instance is the quiet workhorse. Users search it before they raise a ticket, and the service desk relies on its articles for first-line answers. Losing that content, or moving it in a state where nobody trusts it, pushes volume straight back into the queue. The migration question for knowledge is therefore less about storage and more about whether each article still deserves to be published, and who will keep it correct once it is in the new platform.

Sorting Ivanti articles before they are imported

Old knowledge bases accumulate duplicates, expired procedures and articles written for systems that no longer exist. Importing them unchanged gives the new search function a harder job and gives readers more chances to find the wrong answer. Sort the content into four groups before anything is loaded, and treat each group differently.

Procedure for moving articles without losing their meaning

• Export articles with their status, owner, last update and view counts, so the sorting decision is based on evidence.
• Map the Ivanti article fields to the knowledge table fields, and write down every field that has no equivalent.
• Load the current group into a sandbox copy and check how tables, images and attachments render.
• Set a knowledge base owner for each category before publishing, so review tasks have someone to land with.
• Publish in batches by category, and check search results for the top questions the service desk receives.

Where portal links and search behavior break

Ivanti portals often link articles to one another and to forms by internal identifiers. Those links can break during a move unless the identifiers are carried across and resolved after import. A broken link inside a procedure is worse than a missing article, because the reader believes they have found the right step and then cannot follow it. Test a sample of linked articles from the portal, not only from the admin list.

Search is the second risk. Articles that were findable under their old titles may not rank the same way after the move, especially where the title was a label rather than a question. Keep the old title as a synonym where the search configuration allows it, and review the first hundred or so searches the service desk logs in the first month.

When not to move the whole knowledge base

If the Ivanti knowledge base has been left unmanaged for a long period, moving it whole imports the problem with it. In that case it is often better to publish a small, verified set that covers the top requests, leave the rest in an archive, and build new articles from real tickets. That approach is slower to fill the library but much faster to earn trust.

Questions Ivanti teams ask about knowledge

Should we keep article numbers from the old system?

Keep them as a reference field, not as the identifier. Staff and older tickets will quote them for years, and a reference field lets you find the new article from the old number.

Who decides whether a rewritten article is ready?

The owner of the process the article describes, with a service desk reviewer who has actually used the procedure. A knowledge editor can check the wording, but only the process owner can confirm the steps are still right.

The criteria for judging each article are covered in the quality review note, and ownership rules in the article lifecycle note.