BMC Remedy to ServiceNow Migration: The CTO's Technical Guide

A BMC Remedy to ServiceNow migration is not a standard platform swap. It is a legacy-to-cloud architectural shift that requires translating a decade-plus of AR System customizations — forms, Active Links, Filters, Escalations, and a sprawling on-prem CMDB — into ServiceNow's table-driven, CSDM-aligned data model. There is no "lift and shift." Every data structure must be mapped, every workflow object analyzed and rebuilt, and the on-prem extraction itself treated as a data engineering project.

If you want the short version: map the ticket model first, rebuild workflow second, move CMDB with identification rules already defined, and plan on-prem extraction as its own workstream. Teams that reduce this to a flat CSV export/import exercise pay for it later in duplicate CIs, missing history, or broken approvals.

What Makes a BMC Remedy to ServiceNow Migration Unique?

BMC Remedy is built on the Action Request (AR) System, a form-driven, on-premises platform where data, logic, and UI are tightly coupled. ServiceNow is a cloud-native platform with a normalized relational data model, a strict table hierarchy, and workflow logic separated into Business Rules, Flow Designer, and UI Policies.

The core challenge: Remedy's architecture lets administrators create custom forms that blend data storage with display logic. Over 10–15 years, most Remedy instances accumulate hundreds of customized forms, custom fields identified by numeric IDs rather than readable names, and deeply nested workflow chains. None of this transfers automatically.

Underneath, Remedy uses a unique database schema. Data is stored in T-tables (transaction data), H-tables (status history), and B-tables (attachments) — all abstracted behind the ARS layer. ServiceNow operates on a standard relational cloud database where tables extend from base classes like task. Migrating between these two paradigms requires strict field-level translation and a custom ETL pipeline.

Version-Specific Considerations

The extraction approach and available APIs differ materially across Remedy versions:

If you are migrating from Remedy 7.x, plan for SQL-only extraction with no API fallback option. For 8.x environments, test the REST API's pagination limits and timeout behavior before committing to it for any workstream.

How Do You Map the Remedy Data Model to ServiceNow?

Remedy's ITSM data model is form-based. Each ITSM module stores data in specific AR System forms that must be mapped to ServiceNow's normalized table structure. (docs.bmc.com)

Core ITSM Form-to-Table Mapping

On the ServiceNow side, use Import Sets and Transform Maps as the staging layer, not direct writes to production tables. Import sets stage data before transform, and ServiceNow processes imports in batches — avoid extremely large chunks (keep batch sizes under 5,000–10,000 rows per import set run for stable performance). One non-obvious constraint: imports run as System and cannot add data to encrypted fields. If your target design uses encrypted custom fields, plan that path separately. (servicenow.com)

Handling Custom Fields and Status Mapping

Remedy identifies fields by numeric Field IDs (e.g., 1000000215 for "Reported Source" on HPD:HelpDesk). ServiceNow uses human-readable column names (e.g., u_custom_field). Your migration mapping document must translate every custom Remedy field ID to the corresponding ServiceNow column, including data type conversions.

Common type mismatches:

• 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

Status fields are a frequent source of errors. Remedy's Status and Status_Reason fields do not align 1:1 with ServiceNow's state and close_code. For example, Remedy might use a "Pending" status with a reason of "Awaiting Vendor." In ServiceNow, this translates to a state of "On Hold" and an on_hold_reason of "Awaiting Vendor." Every status combination needs explicit mapping.

Extended field mapping template — your mapping sheet should cover at minimum the following fields for each ITSM module. This example covers the incident form:

object,source_form,source_field_id,source_field_label,source_type,target_table,target_field,target_type,transform_rule,null_default
incident,HPD:Help Desk,1000000161,Incident Number,char,incident,u_legacy_ticket_id,string,preserve,required
incident,HPD:Help Desk,7,Status,enum,incident,state,integer,map_enum,1
incident,HPD:Help Desk,1000000881,Status_Reason,enum,incident,close_code,string,map_enum,null
incident,HPD:Help Desk,1000000217,Reported Date,timestamp,incident,opened_at,glide_date_time,convert_utc,required
incident,HPD:Help Desk,4,Assignee,char,incident,assigned_to,reference,lookup_sys_user_by_email,null
incident,HPD:Help Desk,1000000217,Assigned Group,char,incident,assignment_group,reference,lookup_sys_user_group,null
incident,HPD:Help Desk,1000000163,Description,char,incident,description,string,preserve,null
incident,HPD:Help Desk,1000000000,Categorization Tier 1,char,incident,category,string,map_enum,null
incident,HPD:Help Desk,1000000001,Categorization Tier 2,char,incident,subcategory,string,map_enum,null
incident,HPD:Help Desk,1000000164,Priority,enum,incident,priority,integer,map_enum,4
incident,HPD:Help Desk,1000000215,Reported Source,enum,incident,contact_type,string,map_enum,null
problem,PBM:Problem Investigation,1000000232,Problem Investigation ID,char,problem,u_legacy_problem_id,string,preserve,required
change,CHG:Infrastructure Change,1000000182,Infrastructure Change ID,char,change_request,u_legacy_change_id,string,preserve,required

Preserving Work Log History

Remedy uses separate forms like HPD:WorkLog and CHG:WorkLog to track ticket updates. These must be extracted, mapped to the parent ticket via the Incident Number or equivalent key, and inserted into ServiceNow's sys_journal_field to populate the activity stream. Treat journal history as a separate data stream, not an afterthought after tickets load.

var gr = new GlideRecord('sys_journal_field');
gr.autoSysFields(false);
gr.setValue('element', 'work_notes');
gr.setValue('element_id', target_sys_id);
gr.setValue('value', source_work_note_text);
gr.setValue('sys_created_on', source_submit_date); // Original timestamp
gr.setValue('sys_created_by', source_submitter);    // Original author
gr.insert();

How Do You Migrate BMC CMDB CIs to ServiceNow?

This is where migrations stop being a ticket project and become a platform project. BMC's CMDB uses the Common Data Model (CDM), built around BMC_BaseElement and BMC_BaseRelationship subclasses. ServiceNow uses the Common Service Data Model (CSDM) — and the two are structurally different. (docs.bmc.com)

The Class Explosion Problem

A typical Remedy CMDB may have as few as 7 base CI classes (e.g., BMC_ComputerSystem, BMC_Application, BMC_Network). In ServiceNow, these must be distributed across 50–60+ granular classes like cmdb_ci_server, cmdb_ci_win_server, cmdb_ci_linux_server, cmdb_ci_app_server, and so on — based on the Remedy CI's Category, Type, and Item attributes.

This is not a one-to-one map. You must build conditional routing logic in your Transform Maps that reads Remedy's classification fields and routes each CI to the correct ServiceNow class. Example routing logic:

Relationship Migration

Remedy stores CI relationships in the BMC_Relationship form. ServiceNow stores them in cmdb_rel_ci. The mapping requires:

1. Extracting parent/child CI pairs from Remedy's BMC_Relationship records
2. Resolving both sides of the relationship to their new sys_id values in ServiceNow
3. Mapping the Remedy relationship type (e.g., HostedSystemComponents, Dependency) to an equivalent ServiceNow relationship type in cmdb_rel_type (e.g., Contains::Contained by, Depends on::Used by)

Load order matters: independent CIs first (servers, network devices), then dependent CIs (applications, databases), then relationships last. If you load a relationship before both CIs exist in ServiceNow, the relationship record will fail silently or create orphaned references.

Using the Identification and Reconciliation Engine (IRE)

Never push raw CI data directly into ServiceNow's base CMDB tables. Always route migrated data through ServiceNow's Identification and Reconciliation Engine (IRE). The IRE uses identification rules to ensure that if a server already exists in ServiceNow (discovered by Service Graph Connectors or Discovery), the Remedy migration updates the existing record rather than creating a duplicate. (servicenow.com)

Define unique keys — serial number, hostname, FQDN — before loading any data. ServiceNow's IntegrationHub ETL is built to integrate third-party data into the CMDB without compromising integrity and works with IRE-backed targets, making it a better fit for CMDB loads than ad hoc scripts that bypass identification logic. (servicenow.com)

CSDM Alignment

ServiceNow's CSDM framework organizes CIs into domains: Foundation, Design, Build, Manage, and Sell/Consume. If you are migrating from Remedy, this is an opportunity to restructure your CMDB properly — not just replicate the old model. ServiceNow products increasingly depend on CSDM-aligned data for features like Service Mapping, AIOps, and Now Assist.

A safer CMDB migration sequence:

1. Pick the authoritative BMC dataset(s) before you export anything
2. Define ServiceNow identification rules before the first CI load
3. Map independent classes first, then dependent classes, then relationships
4. Preserve the Remedy class name and legacy key in dedicated reference fields for audit and rollback
5. Validate service and application relationships before reports, impact views, or automation depend on them

For a detailed architecture and TCO comparison of the two platforms, see ServiceNow vs BMC Helix: Architecture, TCO & Migration Guide.

Can You Migrate Active Links, Filters, and Escalations to ServiceNow?

Short answer: no — not automatically. Remedy's three workflow object types have no direct migration path to ServiceNow. (docs.bmc.com)

Each Active Link, Filter, and Escalation must be:

1. Inventoried — export all workflow objects from Developer Studio
2. Classified — separate business-critical logic from legacy or redundant rules
3. Redesigned — rebuild in ServiceNow using the appropriate mechanism

This is the most labor-intensive part of any Remedy migration. Enterprises with 10+ years of customizations routinely have hundreds to thousands of Active Links and Filters. Many are redundant, conflicting, or undocumented. The migration is a forced opportunity to clean house.

Do not try to replicate Remedy logic 1:1 in ServiceNow. ServiceNow has native capabilities — Assignment Rules, SLA engine, Approvals framework — that replace entire clusters of Remedy workflow objects. Rebuild for the platform, not from the old one.

Notification and Email Rule Migration

Remedy notification rules (configured per form with filter criteria, email templates, and recipient logic) do not transfer to ServiceNow. ServiceNow's notification system uses different trigger mechanisms (Business Rule-based events vs. Remedy's form-level notification definitions), different template syntax (Jelly/Angular vs. Remedy's field token syntax like $Field ID$), and a different recipient model (user/group references vs. Remedy's notification groups). Each notification rule must be manually recreated. Audit your Remedy notification volume first — many enterprises have 50–200+ notification rules, with significant overlap and redundancy.

Direct SQL and External Integration Edge Cases

One edge case to flag early: Direct SQL. Some Remedy workflows use Direct SQL actions to write to external databases or modify AR System-owned tables directly. BMC explicitly warns that this can cause data corruption. If legacy workflow depends on external SQL side effects, redesign that boundary before cutover instead of trying to clone it. (docs.bmc.com)

How Do You Migrate SLA Definitions and In-Progress SLA Measurements?

SLA migration is an operational risk that many migration plans underestimate. Remedy's SLA management (SLM:SLA and SLM:Measurement forms) and ServiceNow's SLA engine (contract_sla for definitions, task_sla for active measurements) use fundamentally different clock models.

SLA Definition Migration

The Clock Reset Problem

When you migrate an open ticket with an in-progress SLA from Remedy, the SLA clock in ServiceNow must be initialized correctly. Options:

1. Recalculate from scratch — use the original opened_at timestamp and replay state transitions to calculate elapsed time. Most accurate but requires complete state history.
2. Import elapsed time — carry over Remedy's SLM:Measurement elapsed/remaining values as starting points. Faster but depends on Remedy's calculation accuracy.
3. Reset SLA on cutover — start fresh in ServiceNow from cutover date. Simplest but loses pre-cutover measurement continuity.

Most enterprises choose option 2 for active tickets and option 3 for tickets opened close to cutover. Document the chosen approach in your migration runbook and communicate it to SLA reporting stakeholders before cutover.

How Do You Handle Permission and Role Mapping?

Remedy's permission model and ServiceNow's access control model are architecturally different. Ignoring this creates post-migration access issues ranging from users seeing too much data to users being locked out of their workflows.

Permission Model Comparison

Migration Approach

1. Map Remedy groups to ServiceNow groups (sys_user_group) — preserve group structure but review membership
2. Map Remedy application roles to ServiceNow roles — Remedy's Incident Master typically maps to itil + assignment to the correct group; Remedy's CMDB Admin maps to cmdb_admin
3. Rebuild form-level permissions as ACLs — Remedy's per-form group restrictions become ServiceNow ACL rules with role and condition requirements
4. Test with representative users from each role before cutover — permission gaps surface in UAT, not architecture diagrams

How Do You Migrate Reporting?

Remedy reporting commonly uses Crystal Reports, BMC Smart Reporting (BIRT-based), or custom SQL queries against the underlying database. None of these transfer to ServiceNow.

ServiceNow offers three reporting paths:

Migration Approach

1. Inventory existing Remedy reports — catalog by owner, frequency of use, and data source (form/table)
2. Classify — active/used vs. stale (many Remedy instances have 100+ reports that no one runs)
3. Rebuild priority reports in ServiceNow — start with the 10–20 reports leadership and operations actually use
4. Archive Crystal Reports outputs (PDFs) for historical compliance reference

Do not attempt to replicate every Remedy report. Use migration as an opportunity to rationalize the reporting portfolio.

How Do You Handle Millions of Historical Records and On-Prem Infrastructure?

Remedy deployments at large enterprises commonly hold 2–10 million+ incident records, plus corresponding work logs, attachments, and audit trails. The on-prem infrastructure adds complexity that cloud-to-cloud migrations don't face.

Extraction Decision Tree

Use this decision tree to select your extraction method:

1. Is the Remedy version 9.x or Helix?

   • Yes → API extraction is viable for datasets under ~100K records per form. For larger volumes, proceed to SQL.
   • No (7.x or 8.x) → SQL extraction is your only practical option for bulk data.

2. Do you need to extract more than 500K records from any single form?

   • Yes → Use direct database extraction (SQL). API pagination and rate limits make bulk extraction impractical at this scale.
   • No → API extraction is viable. Implement pagination handling and retry logic.

3. Does the Remedy database run on Oracle or MSSQL?

   • Oracle → Use UTL_FILE or external tables for large BLOB exports. Oracle's CLOB handling requires explicit conversion for diary fields.
   • MSSQL → Use BCP (Bulk Copy Program) for high-speed extraction. BLOB extraction uses OPENROWSET or application-level reads.

4. Are attachments in scope?

   • Yes → Always use SQL for attachment extraction. API extraction of Base64-encoded attachments at scale causes timeouts and memory issues. Plan for BLOB decompression (Remedy compresses B-table data using proprietary compression).

Direct Database Extraction (SQL)

Query the underlying Oracle or MSSQL database directly. This is the fastest approach for large volumes. BMC supports read-only SQL access to AR System data for third-party applications. You need to understand Remedy's schema — forms map to tables with names like T955, B955, H955, not human-readable names. (docs.bmc.com)

For enterprise volumes (1M+ records), the recommended approach:

1. Staging: Extract the T-tables, H-tables, and B-tables directly into a secure, intermediate staging database
2. Transformation: Run SQL scripts in the staging environment to join HPD:HelpDesk with HPD:WorkLog and decode the B-table attachments
3. Loading: Push the transformed data into ServiceNow using Import Sets or the Table API, in controlled batches (5,000–10,000 records per batch)

This method guarantees zero impact on your production Remedy instance and gives you a controlled environment for data transformations.

Remedy REST API

BMC Remedy 9.x supports REST API access to forms like HPD:IncidentInterface. This works for smaller datasets or incremental syncs but is significantly slower for bulk extraction. The API is subject to pagination limits (default chunk size of 500 entries), and extracting large Base64-encoded attachments frequently causes timeout errors.

The practical approach for most enterprises: use read-only DB extraction for the large historical backfill, then reserve APIs for delta syncs where application-level workflow matters.

What to Migrate vs. What to Archive

Not all historical data belongs in ServiceNow:

• Migrate open/active tickets in full (incidents, problems, changes with status ≠ Closed)
• Migrate closed tickets from the last 12–24 months for operational reference
• Archive older closed tickets to a read-only data warehouse or cold storage (AWS S3, Azure Blob, compressed SQL export) with lookup IDs preserved in ServiceNow's u_legacy_ticket_id field for cross-reference
• Consider ServiceNow storage costs — ServiceNow charges for database and attachment storage beyond included allocations. Migrating 10M closed tickets with attachments can add significant annual subscription cost.

This approach reduces migration time, keeps your ServiceNow instance lean, and avoids paying to store data no one actively accesses. For a deeper framework on what data to migrate versus leave behind, see our Help Desk Data Migration Playbook.

Attachments

Attachments need their own workstream. Remedy stores attachments in B-tables as compressed binaries. If you extract these via SQL without properly decompressing and encoding them into standard Base64 format, they arrive in ServiceNow as corrupted, unopenable files.

On the ServiceNow side, the Attachment API handles one file per request and respects system attachment limits (default max file size: 25 MB per attachment). Bulk attachment migration needs retry logic, checksum validation (compare source MD5 to target MD5), and MIME-type verification. Always validate a sample of migrated attachments (PDFs, images, .msg files) post-migration — test at least 50–100 files across different MIME types. (servicenow.com)

Keeping the Lights On During Migration

Your Remedy instance must stay operational until ServiceNow is fully validated. This means running both systems in parallel during cutover. The key is a delta sync — after the initial bulk load, continuously capture new and modified records from Remedy and push them to ServiceNow until the final switchover.

Delta sync approaches:

• Timestamp-based polling: Query Remedy for records modified since the last sync timestamp. Simple but may miss records if clocks drift.
• Remedy audit trail: Use H-table entries to identify changed records since last extraction.
• Remedy workflow triggers: Add a Filter to key forms that pushes change notifications to a message queue (if infrastructure supports it).

For strategies on managing this parallel-run period, see Zero-Downtime Help Desk Data Migration.

How Do You Plan Rollback If Migration Fails?

Every migration plan needs a defined rollback strategy. Remedy-to-ServiceNow migrations involve a period of parallel operation that provides a natural rollback window, but this must be explicitly planned.

Rollback Strategy Options

Key rollback prerequisite: Do not decommission Remedy infrastructure until ServiceNow has been in production for a minimum of 30 days with no critical issues. Budget for 30–90 days of parallel infrastructure costs.

What Does Pre-Migration Preparation Look Like?

Prep work on a Remedy migration is heavier than most ITSM migrations because of the platform's age and customization depth. Plan for 4–8 weeks of preparation before any data moves. Do not start with export scripts. Start with archaeology.

Remedy-Specific Prep Checklist

1. Audit all AR System forms — export a full list of forms, fields, and field IDs from Developer Studio. Identify custom vs. out-of-the-box forms. Pull the inventory from the AR System data dictionary. (docs.bmc.com)
2. Inventory workflow objects — catalog every Active Link, Filter, Escalation, and Notification. Tag each as "migrate," "redesign," or "retire." Record the execution order — Remedy's execution order numbering affects behavior and reveals dependencies.
3. Profile data volumes — query record counts on all major forms. Identify the top 10 tables by row count. Measure attachment volumes separately — Remedy stores these as BLOBs, and total size directly affects extraction time.
4. Clean Foundation data — users, groups, locations, companies, departments. In Remedy, user data lives in CTM:People. In ServiceNow, it lives in sys_user. If you migrate an incident and the Assignee does not exist in sys_user, the ticket will be orphaned. Ensure your Active Directory or Okta integration is active in ServiceNow and that the Email Address or User ID matches exactly. (docs.bmc.com)
5. Document integrations — list every external system that pushes data to or pulls data from Remedy (monitoring tools, email gateways, LDAP/AD sync, asset discovery). For each, document: protocol (API, DB link, file), direction (inbound/outbound/bidirectional), frequency, and data volume.
6. Map CMDB classes — create a mapping spreadsheet for every Remedy CI class + Category/Type/Item combination to the target ServiceNow CMDB class.
7. Inventory SLA definitions — document all active SLA definitions, associated schedules, and any in-progress measurements on open tickets.
8. Inventory reports — catalog Crystal Reports, Smart Reporting dashboards, and any custom SQL reports. Note which are actively used.
9. Map permissions — document group-based access restrictions, application roles, and any row-level security on forms.
10. Freeze new customizations — once mapping is approved, stop adding Remedy customizations or you will chase a moving target.

What Affects the Migration Timeline?

A midsized enterprise (500K–2M records, moderate customization) should plan for 8–16 weeks end-to-end, including prep, build, testing, and cutover. Highly customized environments with 5M+ records and dozens of integrations can run 20–30 weeks.

For reference, a published high-volume example: Precision Bridge described an Ernst & Young project that moved 1.5 million incidents and 2 million change requests from Remedy 6.3 to ServiceNow in five weeks, using their automated migration tool for data transfer (workflow was rebuilt separately). Treat that as a tool-accelerated, data-focused reference point — it does not include workflow rebuild, CMDB restructuring, or integration re-platforming time. (precisionbridge.net)

What Does the Validation and UAT Framework Look Like?

Migration validation is not optional — it is a defined workstream. Without structured testing, you discover data loss, broken references, and permission gaps in production.

Validation Checklist

UAT Execution

1. Run full validation against a non-production ServiceNow instance after each test migration load
2. Maintain a defect log with severity classification: Critical (blocks cutover), High (must fix before cutover), Medium (fix within 2 weeks post-cutover), Low (backlog)
3. Require zero Critical defects and zero High defects before approving production cutover
4. Perform a final dress rehearsal migration 1–2 weeks before cutover using production-volume data

Common Pitfalls in Remedy Migrations

Migrations from legacy on-prem systems fail in predictable ways. These are the specific failure modes to watch for:

1. Losing Work Log History

Remedy's HPD:WorkLog stores work notes with timestamps and submitter info. If you don't map the Submit Date and Submitter fields correctly and set autoSysFields(false), every journal entry gets stamped with the migration user's name and the import timestamp. The chronological audit trail is gone.

2. Attachment Corruption

Remedy stores attachments as compressed binaries in B-tables. Extracting via SQL without proper decompression and encoding produces corrupted files in ServiceNow. Extracting via API introduces different encoding issues with binary files. Direct database extraction with proper BLOB handling is more reliable. Always validate a sample post-migration.

3. Trying to Make ServiceNow Look Like Remedy

The most common and most damaging mistake. Teams attempt to replicate Remedy's exact form layouts, field names, and workflow behavior in ServiceNow. The result is a heavily customized ServiceNow instance that is hard to upgrade, hard to maintain, and defeats the purpose of migrating to a modern platform.

4. Ignoring Foundation Data Dependencies

If you load incidents before loading users and groups, every assigned_to, opened_by, and assignment_group reference will fail. Foundation data must be migrated first, validated, and de-duplicated before any ITSM records are imported.

5. Underestimating CMDB Mapping Complexity

Remedy's flat CMDB class structure looks simple, but routing CIs to ServiceNow's granular class hierarchy requires conditional logic based on multiple attributes. Plan for significant time on CMDB mapping and validation — it is rarely a straight export/import.

6. Knowledge Base Template Mismatches

Remedy Knowledge Management (RKM) forces articles into specific templates (How To, Known Error, Problem Solution). ServiceNow's kb_knowledge table is more flexible but requires strict HTML formatting. Migrating RKM articles often results in broken CSS and missing inline images if the HTML payload is not parsed and rewritten during the transform phase. Inline images stored as Remedy attachments must be re-hosted as ServiceNow attachments with updated src URLs in the HTML body.

7. The "Migrate Everything" Trap

Many IT managers demand that 15 years of closed incidents be migrated. This bloats the new platform and increases ServiceNow storage costs. Migrate 1–2 years of closed tickets for operational continuity, and archive the rest into cold storage for compliance.

8. SLA Measurement Discontinuity

If you do not explicitly handle in-progress SLA measurements during cutover, SLA clocks reset to zero in ServiceNow. This creates false SLA compliance data in the weeks following migration. Plan the SLA clock transfer approach (elapsed time import vs. recalculation) before cutover.

9. Permission Gaps Post-Cutover

Remedy's group-based form permissions do not automatically translate to ServiceNow ACLs. If you skip permission mapping, users may see data they should not (over-provisioned) or lose access to workflows they need (under-provisioned). Test with representative users from each role group before cutover.

Why Do Enterprises Choose ServiceNow Over BMC Helix?

BMC Helix is BMC's cloud-native successor to Remedy. It is PinkVERIFY-certified across ITIL practices, supports cloud, on-prem, and hybrid deployments, and positions itself as the natural upgrade path for existing Remedy customers. (docs.bmc.com)

Despite this, many enterprises choose the heavier lift of migrating to ServiceNow. The decision typically comes down to measurable differences:

BMC Helix may be the right choice if: (a) your organization requires on-premises ITSM deployment (ServiceNow does not support this), (b) you have deep investments in BMC's ITOM/AIOps stack that would be costly to replace, or (c) budget constraints favor an in-family upgrade over a full re-platform.

How ClonePartner Executes Remedy-to-ServiceNow Migrations

ClonePartner's approach is built for complex, legacy-to-cloud migrations. With 1,500+ completed migrations and 500+ integrations, our team handles the full pipeline:

• Direct database extraction from on-prem Remedy SQL databases, bypassing API rate limits and handling multi-million-record volumes
• Custom field-level mapping of Remedy AR System forms (HPD:HelpDesk, PBM:Problem Investigation, CHG:Infrastructure Change) to ServiceNow target tables, including data type conversions and enum translations
• 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

Each migration is assigned a dedicated migration engineer who understands both Remedy's AR System architecture and ServiceNow's data model. For a detailed look at our methodology, see How We Run Migrations at ClonePartner.

Frequently Asked Questions

Can we automatically migrate 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 (keep, redesign, or retire), and rebuilt using ServiceNow's native tools — Client Scripts, Business Rules, Flow Designer, or UI Policies. Some tools like Precision Bridge can migrate service request definitions (SRDs and PDTs), but core workflow logic requires manual rebuild. The same applies to Remedy notification rules, which must be recreated as ServiceNow Notifications with new trigger conditions and template syntax.

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, Foundation data cleanup, and SLA/permission migration — not the raw data transfer.

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, then map BMC_Relationship records to ServiceNow's cmdb_rel_ci table with proper identification rules to prevent duplicates. Always route through the IRE (Identification and Reconciliation Engine) — never write directly to CMDB base tables.

Do we need to migrate all historical Remedy data to ServiceNow?

No — and you probably should not. Migrate open tickets in full, closed tickets from the last 12–24 months for reference, and archive the rest to a data warehouse or cold storage. This reduces migration time, keeps your ServiceNow instance performant, and avoids paying for excess ServiceNow storage. Preserve legacy ticket IDs in a reference field (u_legacy_ticket_id) so archived records can be looked up if needed.

What happens to our custom Remedy forms and fields?

Custom forms do not transfer to ServiceNow. Each custom field must be mapped to a ServiceNow field — either an existing out-of-the-box field or a new custom field on the target table. Remedy's numeric Field IDs need translation to ServiceNow's named column format, and data types often require conversion. Some custom forms may map to existing ServiceNow tables; others may need entirely new custom tables extending from task.

What happens to our Remedy SLAs?

SLA definitions must be rebuilt in ServiceNow as contract_sla records. Remedy's SLA schedules (CFG:Schedule) must be recreated as ServiceNow schedules (cmn_schedule). For open tickets with in-progress SLA measurements, you must decide whether to import elapsed time values, recalculate from state history, or reset clocks at cutover. Document and communicate this decision to stakeholders before cutover.

How do we handle permissions and roles?

Remedy's group-based form permissions must be mapped to ServiceNow ACLs and roles. Application roles like Incident Master map to ServiceNow roles like itil with group assignment. Row-level restrictions require ACL conditions or Before Query Business Rules. Test with representative users from each role group during UAT.

What tools can help with the migration?

Common tooling options: Precision Bridge (specialized Remedy-to-ServiceNow migration tool for SRDs, data, and some workflow), Perspectium (ServiceNow data integration), Talend/Informatica (general-purpose ETL for extraction and transformation), ServiceNow IntegrationHub ETL (for CMDB loads), and custom Python/PowerShell scripts (for extraction from Remedy's database and API). Most enterprise migrations use a combination of these rather than a single tool.