BMC Remedy to ServiceNow migration: what moves, what you redesign, and how to phase it
Short answer
A Remedy to ServiceNow migration is a redesign with a data move attached, not a lift and shift. Your records move well: people, groups, companies and locations map cleanly to ServiceNow's core tables, and incidents, problems, changes, work orders and knowledge map to ServiceNow's task-based tables with predictable field mapping. What does not move is the AR System logic: active links, filters, escalations and years of custom forms have to be redesigned as ServiceNow client scripts, UI policies, business rules and flows, and often a large share of that logic is no longer needed once they adopt ServiceNow's standard processes. The CMDB is the hardest part: Atrium's Common Data Model classes, datasets and reconciliation jobs map conceptually to ServiceNow's CMDB classes and Identification and Reconciliation Engine, but only clean, trusted CI data should cross. Phase it: foundation data first, then incident, request, knowledge and the portal, then change and problem, then the CMDB and integrations, and archive Remedy history you do not need live. ServiceNow and BMC both price by quote, so get comparable quotes rather than estimates.
Contents
- Why teams move from Remedy to ServiceNow, and when they should not
- Concept map: Remedy to ServiceNow at a glance
- Data mapping: Remedy forms to ServiceNow tables
- AR System workflow: redesign, do not translate
- Atrium CMDB to ServiceNow CMDB
- A phased migration plan
- Testing and cut-over
- The team you need
- Cost and licensing: what to expect
- Migration checklist
- Frequently asked questions
Why teams move from Remedy to ServiceNow, and when they should not
BMC Remedy has run enterprise service desks for decades, and its successor product is now sold as BMC Helix ITSM (see the BMC Helix ITSM product page). Many organisations still run heavily customised Remedy or Helix ITSM estates built on the AR System platform. The reasons we hear for moving to ServiceNow are consistent: a wish to consolidate IT, HR and operations workflows on one platform, a talent market where ServiceNow skills are easier to hire, frustration with the cost of maintaining old customisations through upgrades, and a strategic decision made above the IT team.
Be honest about the other side. If your Remedy estate is stable, well-documented and close to out-of-the-box, the case for moving rests on platform strategy rather than pain, and a migration is a large investment to make for strategy alone. If your real problem is a tangle of customisations, you could also clean up and modernise within BMC Helix. Our BMC Helix vs ServiceNow comparison covers that decision. This guide assumes you have decided to go to ServiceNow.
Best for
- Organisations consolidating several service management tools onto one platform.
- Teams whose Remedy customisations have become an upgrade and maintenance burden and who are prepared to adopt standard processes.
- Companies planning to extend service management beyond IT, where a single data model pays off.
Wrong choice when
- The motivation is only that "everyone uses ServiceNow" and the current platform works.
- You intend to rebuild every Remedy customisation in ServiceNow. You will recreate the same maintenance burden on a new platform.
- There is no budget for a platform owner and admin capacity after go-live.
Concept map: Remedy to ServiceNow at a glance
Remedy and ServiceNow solve the same problems with different building blocks. Remedy ITSM applications are sets of AR System forms with workflow attached. ServiceNow applications are tables (most process tables extend the base task table) with business logic, flows and UI configuration attached. The map below is the starting point we use in discovery workshops.
| Remedy / AR System | ServiceNow | Migration approach |
|---|---|---|
| Forms (data structures) | Tables | Map standard forms to standard tables; review every custom form |
| Fields and selection fields | Fields and choice lists | Map and rationalise; retire unused fields |
| Active links (client-side workflow) | Client scripts, UI policies, UI actions | Redesign; many become UI policies or are unnecessary |
| Filters (server-side workflow) | Business rules, Flow Designer flows | Redesign; prefer flows and configuration over script |
| Escalations (time-based workflow) | Scheduled jobs, flows with timers, SLA definitions | Redesign around SLA and flow features |
| Approval Server processes | Approval rules, flow approvals | Rebuild approval logic; simplify chains |
| Assignment (support group routing) | Assignment rules, assignment data lookup | Rebuild from your support group model |
| Email engine notifications and inbound mail | Notifications, inbound email actions | Rebuild; review content and recipients |
| Remedy Mid Tier, Smart IT | Service Operations Workspace, platform UI | New agent experience; train agents |
| Self-service (Digital Workplace, Request Entry) | Service Portal, Employee Center | Redesign catalog and portal |
| Atrium CMDB / Helix CMDB (Common Data Model) | CMDB (cmdb_ci hierarchy, cmdb_rel_ci) | Map classes; migrate only trusted CIs |
| Reconciliation Engine, datasets | Identification and Reconciliation Engine (IRE), data sources | Redesign identification and precedence rules |
| Normalization Engine, Product Catalog | Product models, software normalization | Redesign; align with asset management scope |
Data mapping: Remedy forms to ServiceNow tables
Record data is the most predictable part of the project. The table below covers the standard Remedy ITSM forms we see in almost every estate. Your instance will have custom forms and fields on top; inventory them early.
| Remedy form | What it holds | ServiceNow table | Notes |
|---|---|---|---|
| CTM:People | People (users and support staff) | sys_user | Usually loaded from your identity source, not migrated from Remedy |
| CTM:Support Group | Support groups | sys_user_group | Good moment to rationalise groups |
| COM:Company | Companies / organisations | core_company | Map Remedy multi-tenancy carefully |
| SIT:Site | Sites / locations | cmn_location | Clean up duplicates before loading |
| HPD:Help Desk | Incidents | incident | Map status, priority, categorisation; decide history scope |
| PBM:Problem Investigation | Problems | problem | Link to related incidents after both load |
| PBM:Known Error | Known errors | problem (known error) and kb_knowledge | ServiceNow handles known errors through problem records and knowledge |
| CHG:Infrastructure Change | Changes | change_request | Map change classes to change models / types |
| TMS:Task | Tasks under changes, incidents and others | change_task, incident_task, sc_task | Split by parent type |
| WOI:WorkOrder | Work orders | sc_task or sc_req_item, or a custom table | Decide whether work orders become catalog requests |
| SRM:Request and service request definitions | Requests and request catalog | sc_request, sc_req_item, catalog items | Redesign the catalog; migrate open requests only |
| Knowledge Management (RKM) forms | Knowledge articles | kb_knowledge | Review and retire stale articles before moving |
| SLM service targets | SLA definitions and measurements | contract_sla (definitions), task_sla (measurements) | Rebuild definitions; do not migrate historical SLA measurements as live records |
Categorisation
Remedy's operational and product categorisation tiers drive routing, reporting and SLAs in many estates. ServiceNow typically uses category and subcategory plus the affected configuration item and service. Do not replicate three tiers of operational and three tiers of product categorisation by default. Decide what you actually report on and route by, design a smaller model, and build a mapping table from old combinations to the new model for the data load.
How much history to move
Migrating every closed incident since the first Remedy go-live is expensive, slows the load and rarely gets used. Common choices are: open records plus a defined recent window of closed records for reporting continuity, with everything else archived in a read-only store that auditors and analysts can query. Agree the window with the people who actually use history (problem managers, auditors, service owners) before you design the load.
AR System workflow: redesign, do not translate
The biggest mistake in Remedy migrations is treating active links, filters and escalations as a code-conversion exercise. AR System workflow often encodes years of local decisions: special handling for one department, fields that were added for a report nobody runs, notifications to people who left. Translate it line by line and you carry all of that into ServiceNow, in a form that is harder to maintain.
Step 1: Inventory and classify
Export the workflow objects attached to every form in scope. For each, record what it does in business terms ("assign VIP incidents to the priority group", "block closure without a resolution code"), not just its qualification and actions.
Step 2: Sort into four buckets
Native: ServiceNow does this out of the box (SLA timers, standard state models, assignment by group). Configure: a UI policy, assignment rule, notification or flow can do it without code. Build: it is a genuine business requirement that needs a business rule or script. Retire: nobody can explain why it exists, or the process it supports has gone.
Step 3: Design against standard processes
Start from ServiceNow's baseline incident, problem, change and request processes and adjust them. Every deviation should have an owner and a reason. ServiceNow's upgrade path is easier the closer you stay to baseline.
Step 4: Build, test and document
Build in a development instance, promote through test with update sets or application repository, and document each piece of logic against the business rule it implements. This documentation is what Remedy estates usually lack.
Watch for: logic hidden in integrations
Remedy estates often have workflow living outside the forms: web services, plug-ins, scheduled data loads and email-based integrations. Inventory these separately; they are often discovered late, during testing.
Atrium CMDB to ServiceNow CMDB
The CMDB is where Remedy migrations go wrong most often, because the data looks portable. Atrium (now BMC Helix CMDB) uses the BMC Common Data Model, with classes such as BMC_ComputerSystem and relationships held in relationship classes, organised into datasets (for example, a discovery dataset and a production asset dataset) that the Reconciliation Engine merges. ServiceNow uses a class hierarchy under cmdb_ci, relationships in cmdb_rel_ci, and the Identification and Reconciliation Engine to decide whether incoming data matches an existing CI and which source is authoritative for which attributes.
| Atrium concept | ServiceNow equivalent | What to decide |
|---|---|---|
| Common Data Model classes | CMDB class hierarchy (cmdb_ci and extensions) | Class mapping for every class you actually use |
| Relationship classes | cmdb_rel_ci with relationship types | Which relationship types matter for impact analysis |
| Datasets (discovery, import, golden) | Data sources feeding one CMDB through IRE | Which sources are authoritative for which attributes |
| Reconciliation identification and precedence rules | IRE identification rules and reconciliation rules | Rebuild rules; do not assume Remedy rules still fit |
| Normalization and Product Catalog | Product models and normalization | Scope with software and hardware asset management |
| BMC Discovery as data source | ServiceNow Discovery or an import from your existing discovery tool | Whether to replace discovery at the same time |
Our recommendation: do not bulk-copy the Remedy CMDB. Decide which CI classes support real processes (incident impact, change risk, asset tracking), migrate only CIs that pass a data-quality check, and let discovery or authoritative sources repopulate the rest. A smaller trusted CMDB is worth more than a large one nobody believes. If you also replace BMC Discovery, treat that as its own workstream; running both changes at once makes reconciliation problems hard to diagnose.
A phased migration plan
We plan Remedy to ServiceNow migrations as phases with exit criteria, not fixed dates. The right duration depends on your scope, the number of customisations and how much CMDB you bring. What matters is the order.
Phase 0: Discovery and design decisions
Inventory forms, fields, workflow objects, integrations, reports, CMDB classes and data volumes. Classify workflow into native, configure, build and retire. Agree the history window, the categorisation model and the CMDB scope. Exit criteria: signed-off design decisions and a migration specification per form.
Phase 1: Foundation
Instance set-up, identity integration (users from your directory), companies, locations, support groups, roles and the minimum CMDB classes needed for incident (typically business services and key applications). Exit criteria: agents can log in with correct roles and groups; reference data reconciled against Remedy.
Phase 2: Incident, request, knowledge and portal
Configure incident and request fulfilment, redesign the service catalog, migrate knowledge after review, launch the portal, and migrate open incidents and requests. Run the cut-over over a quiet period with a short freeze in Remedy. Exit criteria: agents working in ServiceNow, requesters using the portal, Remedy read-only for these processes.
Phase 3: Change and problem
Change models, approvals, change calendar and CAB process; problem management and known errors. Migrate open changes and problems, or close them out in Remedy if the volume is small. Exit criteria: all new changes and problems raised in ServiceNow.
Phase 4: CMDB, discovery and integrations
Expand CMDB classes, set up IRE rules and data sources, connect discovery and monitoring, and move remaining integrations. Exit criteria: CMDB health targets agreed and met for in-scope classes.
Phase 5: Decommission and archive
Export remaining history to the archive, validate it with auditors and service owners, switch Remedy to read-only or retire it, and end its licences and infrastructure. Exit criteria: Remedy off, archive accessible, licences ended.
Phases 2 to 4 can overlap if you have the team, but keep each cut-over separate. Running incident and change cut-overs on the same weekend doubles the risk for little gain.
Testing and cut-over
- Trial loads: run at least two full trial migrations into a non-production instance and reconcile record counts, key fields and attachments against Remedy.
- Business process tests: test end-to-end scenarios (raise, assign, escalate, resolve, close, reopen) using the redesigned processes, not the Remedy ones.
- Integration tests: monitoring alerts, email, identity, HR feeds and any outbound integrations.
- Agent training: short, role-based sessions close to go-live, with a quick-reference guide that maps old Remedy actions to new ones.
- Cut-over runbook: freeze, final delta load, validation, switch email routing and portal links, go/no-go decision, and a rollback position.
- Hypercare: a defined period with extra support, daily triage of defects and a clear end.
The team you need
| Role | Why it matters in a Remedy migration |
|---|---|
| Platform owner | Makes design decisions, arbitrates "we have always done it this way" requests and owns the backlog after go-live |
| Process owners (incident, request, change, problem, CMDB) | Sign off redesigned processes and the history and data-quality rules for their area |
| Remedy subject-matter expert | Explains what existing forms and workflow actually do; often the only source of truth for undocumented logic |
| ServiceNow architect and developers | Design tables, flows, IRE rules and integrations; keep the build close to baseline |
| Data migration lead | Owns extraction, transformation, trial loads and reconciliation |
| Change and training lead | Prepares agents and requesters for new screens, portal and processes |
The Remedy subject-matter expert is the role teams most often forget to secure. If that person leaves mid-project, discovery stalls. Budget their time explicitly, and capture what they know in the workflow inventory as you go.
Common pitfalls
- Rebuilding Remedy in ServiceNow. Copying custom forms and workflow recreates the upgrade burden you were trying to escape.
- Loading the CMDB first and fastest. A large untrusted CMDB undermines incident impact and change risk from day one.
- Underestimating attachments. Attachment volumes in long-running Remedy estates can dominate load times; test them in trial loads.
- Ignoring reports. Users judge the new platform by whether their reports still exist. Inventory the reports people actually open and rebuild those.
- No owner after go-live. ServiceNow needs ongoing administration; plan the run team before cut-over.
Cost and licensing: what to expect
Both ServiceNow and BMC price by quote. ServiceNow's ServiceNow ITSM pricing page lists ITSM Foundation, ITSM Advanced and ITSM Prime packages but no prices. BMC Helix routes pricing through a request form. We do not publish estimates for either, because quotes depend heavily on fulfiller counts, packages, term and negotiation.
What you can control is the scope you ask them to price. For the ServiceNow side, specify fulfiller counts by role, the package you need, any add-ons (for example, discovery or asset management) and the term. For the project, the main cost drivers are the number of forms and workflow objects in scope, how many you redesign versus retire, the CMDB scope, integrations, and how much history you migrate. Also plan for overlap: you will usually pay for both platforms for part of the project, so negotiate Remedy or Helix renewal terms that match your phase plan.
Migration checklist
Remedy to ServiceNow
- Inventory of forms, fields, workflow objects, integrations and reports
- Workflow classified: native, configure, build, retire
- Categorisation model redesigned and mapped
- History window agreed with problem managers, auditors and service owners
- CMDB classes in scope and data-quality rules defined
- IRE identification and reconciliation rules designed
- Foundation data (users, groups, companies, locations) reconciled
- Two trial loads reconciled
- Agent training and quick-reference guide ready
- Cut-over runbook with rollback position
- Archive validated before Remedy is retired
- Remedy or Helix renewal aligned with the phase plan
Frequently asked questions
Can we migrate Remedy workflow directly into ServiceNow?
Not directly. Active links, filters and escalations have no automatic conversion to ServiceNow. Inventory them, describe each in business terms, and redesign them as ServiceNow configuration, flows or business rules. Many can be retired.
Which ServiceNow table does HPD:Help Desk map to?
Remedy incidents in HPD:Help Desk map to the ServiceNow incident table. Problems (PBM:Problem Investigation) map to problem, and changes (CHG:Infrastructure Change) map to change_request.
Should we migrate the Atrium CMDB as is?
No. Map the Common Data Model classes you actually use to ServiceNow CMDB classes, migrate only CIs that pass a data-quality check, and let discovery or authoritative sources repopulate the rest through the Identification and Reconciliation Engine.
How long does a Remedy to ServiceNow migration take?
It depends on scope, customisation and CMDB ambition, so we plan by phases with exit criteria rather than quoting a generic duration. Foundation and incident, request and knowledge usually come first; change, problem and the CMDB follow.
How much does ServiceNow cost compared with BMC Helix?
Both are quote-only, so there is no published comparison. Ask both vendors to price the same scope: fulfiller counts, processes, CMDB and discovery needs, and contract term.
Do we have to move all historical tickets?
No. Most teams move open records and a recent window of closed records, and archive the rest in a searchable read-only store. Agree the window with the people who use history before designing the load.
Planning a move off Remedy?
We map your Remedy forms, workflow and CMDB to ServiceNow, decide with you what to redesign and what to retire, and run the migration in phases so the service desk never stops.