Migrating from HP Service Manager to ServiceNow

Moving from HP Service Manager to ServiceNow is a migration of legacy ITSM data, custom workflows and integrations. Large HPSM deployments often build extensive custom code, and their relationship-heavy CMDB may not map cleanly to ServiceNow, so the work covers extraction, mapping, CMDB reconciliation, workflow rebuild and cutover.

HP Service Manager Platform and Deployment Context

HP Service Manager (HPSM), built on the Peregrine platform acquired by HP, has served many large enterprises for many years. Like other legacy ITSM platforms, it manages incidents, problems, changes, and requests through integrated modules. The system typically runs on Windows or Linux with a SQL or Oracle backend, and organisations often deployed it on-premises. HP Service Manager stores all service management data in a single database, including a configuration management database containing IT assets and their relationships. After HP divested the software business to another vendor, updates became sporadic; many organisations running HPSM are now operating with aging platforms far removed from initial implementation.

Large HPSM deployments often developed extensive custom code: workflows written in HP’s Process Designer language, integrations via web services to external systems, and custom reporting built on HP’s reporting engine. The HPSM interface is Windows client-server based, though browser-based interfaces became available in later versions. Support staff accustomed to HPSM will have significant learning curve transitioning to ServiceNow’s modern, cloud-native interface.

Data Extraction and Compatibility Assessment

Begin by examining HPSM’s data model and custom extensions. HP Service Manager’s incident table typically includes standard fields (title, description, priority, status, assignment group) plus custom fields specific to your organisation. Extract a complete dump of incidents, problems, changes, and requests from the past three years; be prepared for large datasets because HPSM deployments often accumulate millions of historical records. Query the CMDB for CI records and relationship data; HPSM’s relationship model can be complex (hardware components, software dependencies, business service relationships) and may not map cleanly to ServiceNow.

Assess custom code embedded in HPSM: Process Designer workflows, escalation rules, and automated actions. These cannot be migrated directly to ServiceNow and must be rebuilt. Document the intent of each custom workflow so you can translate it into ServiceNow’s workflow engine. Examine integrations: if HPSM exchanges data with other systems (ERP, help desk, network management), understand the direction and frequency of integration. ServiceNow must support these integrations, either natively or through middleware.

Data Mapping and Transformation Challenges

Incident and problem records map relatively straightforwardly to ServiceNow. The primary challenges are status value translation (HPSM uses statuses like “active”, “resolved”, “closed” that may have different semantics than ServiceNow’s) and custom field handling. HPSM often uses custom fields extensively; decide which custom fields are worth migrating to ServiceNow (those supporting business processes) versus dropping. Request management is more nuanced: HPSM request tracking might handle diverse request types (new access requests, infrastructure changes, service requests) through a single request table. ServiceNow separates requests into the request fulfillment module with predefined catalog items, requiring decisions about how to structure requests in ServiceNow.

Change management presents mapping complexity. HPSM changes link to specific CIs and may have custom approval workflows. ServiceNow’s change management supports CAB (change advisory board) approvals and workflow automation similarly, but the detail varies. Status values and change category mappings require careful attention: HPSM change categories may not align exactly with ServiceNow’s. Build a detailed mapping spreadsheet showing each HPSM field, the corresponding ServiceNow field, any transformations needed, and decisions about fields without direct equivalents.

CMDB Reconciliation and Asset Integrity

HPSM CMDB data is often inconsistent after years of operation. CIs may be duplicated, outdated records may be marked inactive but not removed, and relationships may be stale. Before migrating, conduct a CMDB quality assessment: compare the CMDB against a current asset inventory from a separate source (network scanning, IT asset management system, cloud inventory). Identify and merge duplicates, remove obsolete CIs, and correct stale relationships. This cleanup is one-time work that improves downstream operations; ServiceNow will benefit from a cleaner, validated CMDB than HPSM’s.

Plan a phased CMDB migration: consider migrating active CIs and relationships that directly support incident and change management, and leaving historical or deprecated CIs behind. ServiceNow’s CMDB may be designed differently; you might consolidate CI types, standardise attributes, or remodel relationships based on ServiceNow best practices. This is an opportunity to improve, not just replicate, the CMDB.

Workflow and Automation Rebuild

HPSM’s Process Designer workflows cannot be directly ported to ServiceNow. Instead, examine each workflow’s intent and rebuild it in ServiceNow’s workflow module or flow designer. Common HPSM workflows include incident routing (automatic assignment based on category and priority), escalation (priority increase or reassignment if incident remains unresolved), and approval workflows for changes. ServiceNow’s assignment rules and workflow engine support these patterns, but syntax and configuration differ. Prioritise high-value workflows: those that execute frequently or prevent critical errors.

Integrations built through HPSM’s web services layer must be rebuilt. If HPSM integrated with a ticketing system, ERP, or network management platform, determine whether ServiceNow has native connectors for those systems (likely for major enterprise platforms) or whether you need middleware like MuleSoft or Boomi. Test integrations thoroughly in a sandbox before cutover to ensure data flows correctly between systems.

Cutover Strategy and Continuity Planning

Plan a scheduled cutover window during a maintenance period when incident volume is expected to be low. On the cutover date, HPSM transitions to read-only mode (for reference and historical lookup), and ServiceNow becomes the production system. Unlike parallel running, this approach avoids duplicate data entry and confusion. Prepare detailed cutover procedures: data extraction from HPSM, transformation, ServiceNow load, index rebuilding, and validation steps. Create a rollback plan that allows reverting to HPSM if critical issues emerge during cutover; test rollback procedures at least once in non-production.

Support staff must be trained before cutover. HPSM veterans will need hands-on practice with ServiceNow’s interface, incident management workflow, knowledge search, and change request submission. Conduct training sessions well before cutover and provide sandbox access for practice. Identify power users in each support team who can mentor peers post-cutover. Plan for elevated support availability during the early period after cutover to address questions and handle cutover-related issues rapidly.

Post-Cutover Stabilisation and Decommission

After cutover, run a complete incident and change management cycle in ServiceNow, long enough to validate that core processes work correctly. Measure success against defined criteria: data completeness (all historical records migrated), accuracy (spot-checks confirming data integrity), system performance (query response times, report generation speed), and user proficiency (support staff comfortable with workflows). How long stabilisation takes depends on how many issues the cutover exposes. After stabilisation, disable HPSM access to prevent accidental data entry or confusion. Archive HPSM data for the compliance retention period your rules require, but keep it read-only, not in production.

Reporting parity decides what the cutover can honestly prove

Service Manager estates are usually judged on their reports long before anyone looks at the workflow. Operations reviews, audit packs and contract conversations all draw on figures that were produced by views, scheduled jobs and exports built up over many years. When the move happens, the question that matters is not whether the new platform can produce a similar chart. It is whether the figures it produces mean the same thing as the ones the organization has been quoting. A reporting inventory is therefore a prerequisite for the cutover, not a follow-on task.

Inventorying the reports that carry decisions

A report that nobody opens is a candidate for retirement. A report that a contract depends on needs an exact match and a documented definition. The table separates the two cases and shows what each needs before the cutover date is fixed.

Building the parity evidence in a usable order

1. List the reports leadership uses to make a decision, and mark the ones a contract, audit or regulator relies on.
2. Write the definition of each metric in plain language, including its start and stop states and its calendar.
3. Pick a closed period that both systems still hold, and produce the figures from each side separately.
4. Investigate every difference larger than the rounding you agreed, and record the cause rather than adjusting the number.
5. Get the report owner to accept the reconciled figures before the old platform is switched to read-only.

Where reporting parity fails without anyone noticing

The most dangerous difference is a definition that is technically the same and operationally different. A resolution time that stops at a closed state in one platform and at a confirmed state in the other will produce a clean-looking trend line with a step change at the cutover date. Nobody has made an error in the new platform, yet the organization will read the change as a performance shift. Look for step changes in every trend line for the months either side of the move.

The second failure is a scheduled export that the old platform sent to a mailbox and nobody has recreated. The first missed Monday report is often the first signal that a process depended on it. Build an inventory of scheduled outputs, not only of dashboards.

Questions about reporting during the move

Should we run both platforms in parallel to compare reports?

For the reports that carry contract or audit weight, a short parallel period is worth the cost. For operational views, a reconciled sample is usually enough, and a long parallel run tends to keep people entering data in two places.

What if the old definition was wrong?

Record the correction as a decision with a date and an owner. Restating history quietly is one of the fastest ways to lose trust in the new figures.

Who signs off the metric definitions?

The business owner of the process, with the platform team recording the definition. Leave the signature with the person who would explain the number to a board.

The controls that prove a reconciled figure are described in the controls note, and the measurement scope sits in the service level and experience service.

HP Service Manager and ServiceNow are different products

ServiceNow is not an HP product. HP Service Manager (HPSM) is an older IT service management tool from a different vendor lineage, and ServiceNow is a separate cloud platform that many HPSM customers move to when the old system becomes costly to keep current.

Searches such as “HP ServiceNow” usually come from one of two situations: a team running HPSM that is weighing a move, or someone who has seen both names in the same tender. The practical comparison looks like this:

Signs the move is worth planning

The signals that most often justify a move are upgrades that keep slipping, reports only one or two people can still change, integrations nobody wants to touch, and support staff working around the tool instead of in it. Any one of these is manageable. Several together usually mean the platform is costing more to maintain than to replace, and that is the point to compare the cost of a planned migration with another year of workarounds.

Common questions

Is ServiceNow made by HP?

No. They are separate products from separate vendors, with different architectures and different release cycles. Only the migration path connects them, and that path is a data and process rebuild, not an upgrade.

Can HPSM records be loaded into ServiceNow?

Yes. Incidents, problems, changes and CMDB records can be extracted, mapped and imported. The data migration and import sets guide explains the loading mechanics, and data migration and cutover with reconciliation covers proving the numbers match. For the wider picture, start at migrating to ServiceNow.