BMC Remedy to ServiceNow migration requires mapping AR System forms to ServiceNow tables, rebuilding Active Links/Filters in Flow Designer, and translating BMC's CDM-based CMDB to ServiceNow's CSDM — none of it automatic.
Migrating from BMC Helix ITSM to ServiceNow is a legacy-to-cloud architectural shift with no native migration path or out-of-the-box plugin to connect the two platforms. BMC Remedy's AR System uses a form-driven architecture with tightly coupled data, logic, and UI—stored in proprietary T-tables, H-tables, and B-tables—while ServiceNow operates on a normalized, table-driven relational model aligned to the Common Service Data Model (CSDM). Every data structure requires explicit field-level mapping (including translating numeric Remedy Field IDs to human-readable ServiceNow columns), a custom ETL pipeline for on-prem extraction, and a full rebuild of workflow objects such as Active Links, Filters, and Escalations into ServiceNow's Business Rules, Flow Designer, and UI Policies.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
There is no official out-of-the-box plugin from ServiceNow that directly connects to BMC
There is no official out-of-the-box plugin from ServiceNow that directly connects to BMC Remedy or migrates data automatically. You need a custom ETL pipeline — whether built in-house using tools like Talend, Informatica, or custom Python scripts, or through a migration partner. ServiceNow's IntegrationHub ETL can handle the load side but does not extract from Remedy natively.
If you only inventory the visible Remedy screen and ignore its interface forms, you will
If you only inventory the visible Remedy screen and ignore its interface forms, you will miss fields that matter during create, update, and replay of historical records. BMC's own customization guidance shows that custom fields must be placed on both the business form and the interface forms used for create and edit. (docs.bmc.com)
Before mapping custom fields, export the Remedy form definitions from Developer Studio
Before mapping custom fields, export the Remedy form definitions from Developer Studio and generate a field-level data dictionary. This becomes your single source of truth for the entire migration.
Data Loss Risk
When migrating work log entries to ServiceNow, default API behavior stamps work notes with the migration user's name and the current timestamp. Use autoSysFields(false) in your ServiceNow transform scripts to preserve the original author and historical timestamps. Without this, you lose the chronological audit trail. Example in a Transform Map script:
If your BMC CMDB has duplicate-looking CIs across datasets, do not merge them into one
If your BMC CMDB has duplicate-looking CIs across datasets, do not merge them into one ServiceNow load until you decide which dataset is authoritative and how identifiers will be normalized.
Map workflow by business outcome, not by object count
Ten Active Links that only set defaults may become one cleaner rule in ServiceNow. One escalation with SQL side effects may become a bigger rebuild than fifty simple field actions.
If your ServiceNow instance cannot reach on-prem Remedy sources directly, you may need a
If your ServiceNow instance cannot reach on-prem Remedy sources directly, you may need a MID Server to bridge the network gap. The MID Server runs inside your network and communicates outbound to ServiceNow over HTTPS. (servicenow.com)
A clean pre-migration inventory usually saves more time than any migration tool choice
On old Remedy estates, the undocumented custom field or forgotten filter is what breaks UAT.
Do not let the implementation team redesign states, approvals, SLAs, service taxonomy,
Do not let the implementation team redesign states, approvals, SLAs, service taxonomy, and CMDB classes in the same sprint without a locked mapping baseline. That turns migration into uncontrolled reimplementation.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the service model, not just the ticket table.
Objective Agreed scope across incidents, changes, problems, requests, CMDB and knowledge, with the CAB bought in.
Keep these open
-
Inventory every record type in BMC Helix ITSM
Count incidents, service requests, changes, problems, releases, knowledge articles and CI records. ITSM migrations fail on scope more than technique: the CMDB and the request catalogue are usually far larger and more entangled than the incident table everyone focuses on.
Data Profiler Get real record counts instead of estimating from memory -
Document the CMDB and its relationships
Map CI classes, attributes and — critically — the relationships between them. CI relationships carry your impact analysis, and they are the hardest thing to migrate faithfully because ServiceNow almost certainly models them differently.
CI relationships rarely map one-to-one between ITSM tools. Losing them silently breaks impact analysis and change risk scoring.
-
Capture SLAs, OLAs and their calculation rules
Record every SLA target with its business calendar, pause conditions and escalation path. The rules matter more than the numbers: an SLA that counts pending time differently in ServiceNow will report different compliance on identical data.
-
Review the request catalogue and its fulfilment workflows
Each catalogue item is a form plus an approval chain plus a fulfilment workflow. These are rebuilt, not migrated, and they are usually the longest lead-time item in the whole project.
COI & ROI Calculator Build the 36-month business case you will need for sign-off -
Take the migration through change management
The migration is itself a major change and needs CAB approval, a risk assessment and a documented rollback plan. Start this early — CAB cycles are measured in weeks and will otherwise set your go-live date for you.
Helpdesk Migration Planner Turn ticket volume into a dated BMC Helix ITSM → ServiceNow timeline -
Build the business case and set the window
Model licence delta, implementation effort and the operational risk of running degraded. Choose a window that avoids change freezes, month-end and any regulatory reporting deadline.
Helpdesk Evaluator Sanity-check that ServiceNow is the right target before you commit
Don't move on until
- Counts confirmed across every ITSM record type including CMDB
- Change-management implications reviewed with the CAB
- SLA and OLA targets documented with their calculation rules
02 Data Audit Audit the service data and the configuration data separately.
Objective Profiled exports for every record type, with CMDB integrity and audit-trail requirements resolved.
Keep these open
-
Export and profile every record type
Profile incidents, changes, problems, requests, knowledge and CIs separately — they have different shapes and different defects. Reconcile each export against the API count to catch pagination truncation.
Data Profiler Profile the BMC Helix ITSM export for nulls, outliers and type drift -
Audit CMDB integrity
Find CIs with no owner, no class, or relationships pointing at deleted CIs, plus duplicates from overlapping discovery sources. A CMDB is usually the least-maintained data in the estate and migrating its decay wastes the one chance you have to clean it.
Duplicate CIs from multiple discovery sources will multiply on load unless you dedupe before migrating.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Resolve audit-trail and retention requirements
Confirm with compliance how much history and which audit fields must be preserved, and whether a read-only archive of BMC Helix ITSM satisfies the requirement. In regulated environments this often changes scope materially.
Regulated environments frequently require the immutable original audit trail, which no migration can recreate — plan for an archive.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Validate structure and encoding of the exports
Check delimiters, encoding and embedded newlines. Incident work notes and change implementation plans contain long multi-line text and pasted logs, which is exactly what breaks CSV parsing.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for PII and secrets in ticket text
ITSM tickets contain credentials, connection strings, internal hostnames and personal data pasted into work notes. Scan for both regulated data and secrets, and treat found credentials as a security incident in their own right.
Work notes commonly contain passwords and connection strings. Migrating them propagates the exposure into a new system.
-
Clean, normalise and produce masked test data
Normalise timestamps to UTC, standardise CI naming, trim whitespace, and generate a masked copy for the sandbox. Business-hours SLA calculations make timezone consistency non-negotiable here.
PII Masker Generate a safe copy for sandbox and vendor testing
BMC Helix ITSM → ServiceNow specifics
- Direct database extraction
- from on-prem Remedy SQL databases, bypassing API rate limits and handling multi-million-record volumes
Don't move on until
- Every record type exported and profiled against API counts
- CMDB orphans and broken relationships quantified
- Audit-trail retention requirements confirmed with compliance
03 Field Mapping Map record types, state models, CI classes and approvals.
Objective A signed mapping covering record types, state machines, CI classes and relationships, and approval chains.
Keep these open
-
Map record types before fields
Establish how BMC Helix ITSM record types land in ServiceNow — service requests may become a different object entirely, and incident/problem separation is modelled differently across tools. Get this wrong and every field decision downstream is built on sand.
Schema Mapper Opens pre-loaded with the BMC Helix ITSM → ServiceNow field pair -
Map the state model and the impact/urgency matrix
Enumerate every state and transition, plus how priority is derived from impact and urgency. Tools derive priority differently, so a straight priority copy will disagree with the target's own calculation and confuse everyone reading a report.
If ServiceNow derives priority from impact and urgency, migrating priority directly will produce records whose priority contradicts their own inputs.
-
Map CI classes, attributes and relationship types
Match each CI class and relationship type to a ServiceNow equivalent and document every gap explicitly. Where no relationship type exists, decide whether to approximate, flatten, or park the data in an attribute — and record the impact on change risk scoring.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map assignment groups, roles and approval chains
Build the group and user map including leavers, and map each approval chain to its ServiceNow equivalent. Historical approvals usually cannot be recreated as live approval records — decide how you preserve the evidence.
-
Plan knowledge article migration
Decide how article bodies, categories, permissions and linked-incident references translate. Confirm whether internal links between articles and attachment references survive, or need rewriting after load.
-
Set load order and freeze the spec
Sequence users and groups, then CIs, then CI relationships, then tickets, then knowledge — CI relationships need both endpoints to exist. Version and sign off the spec before the pilot.
BMC Helix ITSM → ServiceNow specifics
- Remedy selection fields
- (enumerated integers) → ServiceNow choice fields (string values with choice list entries)
- Remedy diary fields
- (append-only text) → ServiceNow journal fields (sys_journal_field entries on work_notes or comments)
- Remedy date fields
- (epoch or AR System format) → ServiceNow glide_date_time (UTC-normalized)
- Remedy currency fields
- (stored as numeric with separate currency code field) → ServiceNow currency type (single field with currency prefix)
- Remedy character fields with length > 4000
- → ServiceNow string fields max at 4000 characters by default; consider large_string or journal fields
Don't move on until
- State and priority models mapped, including impact/urgency matrices
- CI classes and relationship types mapped with gaps documented
- Approval chains and assignment groups mapped to target equivalents
04 Test Migration Pilot the whole service model, including a change with approvals.
Objective A sandbox pilot where tickets, CI relationships, SLAs and approvals all behave correctly.
Keep these open
-
Build the ServiceNow sandbox to match the target service model
Configure record types, states, SLAs, business calendars, assignment groups, CI classes and approval workflows before loading anything. In ITSM the configuration is the product, so an unconfigured sandbox tests nothing.
-
Pick a pilot slice spanning every record type
Include incidents at every priority, a change with a full approval chain, a problem with linked incidents, a catalogue request, connected CIs, and knowledge articles with cross-links. Coverage of types matters more than volume here.
-
Load in dependency order with full logging
Users and groups, then CIs, then relationships, then tickets, then knowledge. Log each request against its source ID so you can trace any failure without a full re-run.
-
Verify CI relationships and impact analysis
Confirm relationships survived and then run an actual impact analysis on a pilot CI, comparing the result to BMC Helix ITSM. Relationship counts matching while impact analysis returns something different means the relationship types mapped wrongly.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Reproduce SLA compliance on migrated records
Compare calculated SLA compliance on the pilot records against BMC Helix ITSM. Differences trace to business-calendar or pause-condition mapping and must be resolved before full load, since compliance reporting is often contractual.
SLA compliance is recalculated from loaded timestamps. Any approximation in timestamp or pause-state mapping shows up directly as a compliance variance.
-
Run a change through approvals and reconcile
Raise a change in the sandbox, take it through its full approval chain and implementation states, and reconcile the pilot batch on counts and fields. Then let service-desk agents work sample incidents before you sign off the pilot.
Don't move on until
- CI relationships verified intact for the pilot slice
- SLA calculations reproduce source compliance figures
- A change record runs end to end through its approval chain
05 Cutover Switch the service desk without losing an incident.
Objective All in-scope service data live in ServiceNow, monitoring and email integrations repointed, desk operating normally.
Keep these open
-
Pre-load history and the CMDB ahead of the freeze
Load closed tickets, knowledge and the CMDB while BMC Helix ITSM stays live. The CMDB load in particular is slow and benefits enormously from happening outside the window.
Helpdesk Migration Planner Size the freeze window from ServiceNow's real API limits -
Publish the runbook with CAB-approved abort criteria
A timed sequence with named owners, plus the rollback conditions the CAB signed off. In ITSM the rollback plan is a formal deliverable, not a verbal understanding.
-
Freeze BMC Helix ITSM and take the final delta
Stop new ticket creation, let the desk finish in-flight work, then export everything changed since the pre-load. Communicate the freeze across the whole organisation and staff a manual intake path for genuine P1s during the window.
A P1 incident raised during the freeze needs a documented manual path, or it will be worked in the old system and lost.
-
Load open tickets and the delta, then reconcile
Load open incidents, changes and requests, then verify counts and open-state accuracy before repointing anything. Open-state accuracy matters more than history here — it is what the desk works from at 9am.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint monitoring, email and integrations
Switch monitoring-tool integrations, email intake, self-service portal links and any orchestration or discovery connectors. Then fire a real alert through monitoring and confirm the incident it creates routes correctly.
Monitoring integrations still pointing at the old tool will create incidents nobody is watching.
-
Go/no-go and switch the service desk
Call the decision against the exit criteria with the change manager present, then move the desk with elevated support for the first shift. Keep BMC Helix ITSM read-only as the archive and rollback path.
BMC Helix ITSM → ServiceNow specifics
- CMDB class routing
- conditional Transform Map logic that maps Remedy's flat CI classes to ServiceNow's CSDM-aligned hierarchy, with coalesce rules to prevent duplicates
- Zero-downtime continuous sync
- both systems run in parallel during cutover, with delta sync capturing new records from Remedy until the final switch
- Compliance-ready infrastructure
- SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant
Don't move on until
- Historical load complete and reconciled before the freeze
- Monitoring, email and integration inbound paths verified live
- CAB-approved rollback point passed explicitly
06 Validation Prove service continuity, compliance and reporting.
Objective Evidence that records, CMDB, SLAs and workflows all survived, plus signed acceptance and a retained archive.
Keep these open
-
Reconcile every record type and the CMDB
Compare counts per record type and per state, CI counts per class, and relationship counts per type. Produce one report acceptable to both the CAB and your auditor.
Migration Validation Tool Reconcile BMC Helix ITSM and ServiceNow record-for-record -
Re-verify CMDB relationships and impact analysis
Re-run impact analysis on a sample of critical CIs and compare with the pre-migration result. This is the CMDB equivalent of a field-completeness check and it is routinely skipped.
Data Profiler Prove field completeness held up through the load -
Tie SLA and service reporting to baseline
Rebuild SLA compliance, MTTR, first-time-fix and volume reporting, and compare to pre-migration figures for the same period. Explain every variance in terms of a specific mapping decision.
Business-calendar differences between tools will shift MTTR and compliance even when the underlying data is identical.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Test the full workflow layer
Fire every escalation, approval chain, notification, catalogue fulfilment workflow and automation with live records. Workflow is rebuilt from scratch, so nothing is proven until it has been observed running.
-
Confirm compliance evidence and audit archive
Re-scan for PII and secrets in loaded records, confirm retention configuration in ServiceNow, and formally retain the BMC Helix ITSM archive that satisfies your immutable audit-trail requirement.
-
Close the change and sign off
Close the migration change record with actual outcomes, get written acceptance against the Discovery criteria, and schedule decommission after the agreed read-only retention period.
Don't move on until
- Reconciliation complete across all record types and CIs
- SLA and service reporting tie to pre-migration baselines
- Audit archive retained and acceptance signed
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Remedy Form Table
| BMC Helix ITSM field | ServiceNow field | Notes |
|---|---|---|
| HPD:HelpDesk (HPD:Help Desk) | incident | Primary incident tracking form. ITIL versions use HPD:IncidentInterface_Create for creation and HPD:IncidentInterface for updates. |
| PBM:Problem Investigation | problem | Problem records and known errors. Integration paths use PBM:ProblemInterface_Create and PBM:ProblemInterface. |
| CHG:Infrastructure Change | change_request | Standard, normal, and emergency changes. Integration uses CHG:ChangeInterface_Create and CHG:ChangeInterface. |
| SRM:Request | sc_request / sc_req_item | Service requests and catalog items |
| TMS:Task | sc_task | Task records under requests |
| HPD:WorkLog | sys_journal_field | Work notes and comments (journal entries in ServiceNow) |
| CHG:WorkLog | sys_journal_field | Change work notes — separate extraction from incident work logs |
| KM:Knowledge Article | kb_knowledge | Knowledge base articles |
| AST:Asset | alm_asset | Hardware and software assets |
| NTE:Notification | No direct equivalent | Email notifications — must be rebuilt as ServiceNow Notifications (see below) |
Remedy SLA Component Equivalent
| BMC Helix ITSM field | ServiceNow field | Notes |
|---|---|---|
| SLM:SLA (definition) | contract_sla | Rebuild — trigger conditions, pause conditions, and schedule references differ structurally |
| SLM:Measurement (active timer) | task_sla | Active measurements must be recalculated based on ServiceNow's clock |
| SLM:ServiceTarget | contract_sla conditions | ServiceNow combines target and definition into one record |
| Business schedules (CFG:Schedule) | cmn_schedule | Rebuild schedules; Remedy and ServiceNow calculate business hours differently |
Reporting Need Tool
| BMC Helix ITSM field | ServiceNow field | Notes |
|---|---|---|
| Operational dashboards | Reports + Dashboards | Built-in, no additional licensing. Create from table data using point-and-click. |
| Trend analysis, benchmarking | Performance Analytics | Requires separate licensing. Stores historical indicator snapshots. |
| Complex/cross-table queries | Reporting with Data Sources or Integration with external BI tools (Tableau, Power BI via ODBC) | For reports that joined multiple Remedy T-tables via custom SQL. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Incidents | medium | HPD:HelpDesk maps to the incident table, but status/status_reason combinations require explicit enum mapping to ServiceNow's state, close_code, and on_hold_reason fields to avoid misclassification. |
| Problems | medium | PBM:Problem Investigation maps to the problem table, but integration interface forms (PBM:ProblemInterface_Create) must also be inventoried to capture all fields used during record creation. |
| Change Requests | medium | CHG:Infrastructure Change maps to change_request, but Remedy's change types and approval workflow chains must be carefully re-mapped to ServiceNow's standard, normal, and emergency change models. |
| Work Logs / Journal History | high | Without autoSysFields(false) in transform scripts, all work log entries are stamped with the migration user and current timestamp, permanently destroying the original chronological audit trail. |
| CMDB Configuration Items | high | BMC's ~7 base CDM classes must be decomposed into 50-60+ ServiceNow CSDM classes with identification rules pre-defined; without this, bulk imports create massive duplicate CI records. |
| Custom Fields | high | Remedy fields identified by numeric IDs with data types like diary fields, selection enums, and >4000-character strings require individual type conversion rules, and missing interface form fields will cause silent data loss. |
| Service Requests / Catalog Items | medium | SRM:Request and TMS:Task map to sc_request, sc_req_item, and sc_task, but the service catalog structure and fulfillment workflows must be rebuilt in ServiceNow's Service Catalog framework. |
| Knowledge Articles | low | KM:Knowledge Article maps to kb_knowledge with relatively straightforward content migration, though embedded attachments and article categorization may require additional handling. |
| Assets | medium | AST:Asset maps to alm_asset, but Remedy's asset-CI relationship model may not align with ServiceNow's asset-to-CI linking conventions, requiring relationship reconciliation. |
| Notifications / Email Rules | medium | Remedy's NTE:Notification has no direct ServiceNow equivalent and all notification logic must be manually rebuilt as ServiceNow Notification records with appropriate triggers and conditions. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
No Native Migration Path
ServiceNow provides no out-of-the-box plugin or connector to extract data from BMC Remedy, requiring a fully custom ETL pipeline built with tools like Talend, Informatica, or custom Python scripts.
Incompatible Data Models
Remedy's form-based AR System architecture with numeric Field IDs, proprietary T/H/B-table schemas, and enumerated integer fields must be translated to ServiceNow's normalized relational tables with human-readable column names, choice fields, and glide_date_time types.
CMDB Class Explosion
BMC's Common Data Model uses approximately 7 base CI classes like BMC_ComputerSystem, which must be redistributed across 50–60+ granular ServiceNow CSDM classes such as cmdb_ci_win_server and cmdb_ci_linux_server based on CI attributes.
Workflow Logic Rebuild
Remedy's Active Links, Filters, and Escalations are tightly coupled to forms and cannot transfer automatically, requiring each workflow chain to be analyzed and rebuilt using ServiceNow's Business Rules, Flow Designer, and UI Policies.
Work Log History Preservation
Remedy stores work logs in separate forms (HPD:WorkLog, CHG:WorkLog) and migrating them to ServiceNow's sys_journal_field without using autoSysFields(false) overwrites original authors and timestamps, destroying the audit trail.
On-Prem Extraction Complexity
Extraction capabilities vary significantly across Remedy versions—7.x offers no REST API and requires direct SQL, while 9.x and Helix provide REST APIs with pagination limits—making data extraction a standalone engineering workstream.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can you automatically migrate BMC Remedy Active Links and Filters to ServiceNow?
No. Remedy's Active Links, Filters, and Escalations have no automated migration path to ServiceNow. Each must be inventoried, classified as keep/redesign/retire, and rebuilt using ServiceNow's Client Scripts, Business Rules, Flow Designer, or UI Policies. Some tools like Precision Bridge can migrate service request definitions, but core workflow logic requires manual rebuild.
How long does a BMC Remedy to ServiceNow migration take?
For a midsized enterprise with moderate customizations and under 2M records, plan for 8–16 weeks end-to-end. Highly customized environments with 5M+ records and complex CMDB structures can take 20–30 weeks. The biggest timeline drivers are custom workflow rebuild, CMDB class mapping, and Foundation data cleanup.
How do you map BMC Remedy CMDB to ServiceNow CMDB?
BMC's CMDB uses the Common Data Model with as few as 7 base CI classes. ServiceNow uses the CSDM-aligned model with 50–60+ granular classes. You must build conditional routing logic that reads Remedy's Category, Type, and Item attributes and routes each CI to the correct ServiceNow class, mapping BMC_Relationship records to ServiceNow's cmdb_rel_ci table.
Do we need to migrate all historical Remedy data to ServiceNow?
No. Best practice is to migrate open/active tickets in full, closed tickets from the last 12–24 months for operational reference, and archive older records to a data warehouse or cold storage. This reduces migration time, keeps ServiceNow performant, and avoids storing data no one actively accesses.
What happens to custom Remedy forms and fields during migration?
Custom forms do not transfer to ServiceNow. Each custom field must be mapped to a ServiceNow field — either an existing OOB field or a new custom field. Remedy's numeric Field IDs need translation to ServiceNow's named column format, and data types often require conversion. Some custom forms map to existing ServiceNow tables; others need new custom tables extending from task.