A BMC Remedy to ServiceNow migration changes more than the ticketing system. Data structures, workflows, the CMDB, integrations, permissions, and knowledge all need to be reviewed before they move.
For enterprises with years of Remedy customization, decide what should be migrated, rebuilt, retired, or archived. Copying every legacy process into ServiceNow carries old complexity into the new platform.
This guide focuses on what changes during migration and what teams should decide before cutover. If you are still comparing the two platforms, start with BMC Remedy vs ServiceNow: Which ITSM Platform Is Better for Your Enterprise? If cost is the main concern, see BMC Remedy vs ServiceNow: Cost, Licensing & Total Cost of Ownership.
BMC Remedy to ServiceNow Migration: What Changes at a Glance
| Migration area | What changes | Main decision |
|---|---|---|
| Data model | Remedy records must map to ServiceNow tables and fields | What needs to move? |
| CMDB | CI classes, relationships, ownership, and data sources need review | What should map to the ServiceNow CMDB and CSDM? |
| Workflows | Remedy logic does not move one-to-one | What should be rebuilt using ServiceNow workflows? |
| Customizations | Old forms, scripts, and exceptions need rationalization | Keep, replace, redesign, or retire? |
| Service catalog | Request items and approvals need remapping | Which services still matter? |
| Knowledge | Articles, ownership, and metadata need cleanup | Migrate all content or only useful content? |
| SLAs | Rules, calendars, priorities, and pause conditions must be recreated | Which commitments must remain identical? |
| Integrations | Endpoints, authentication, mappings, and error handling change | Rebuild, replace, or remove? |
| Roles and access | Remedy permissions must be translated into ServiceNow roles and groups | Who needs access to what? |
| Reporting | Existing Remedy reports may rely on different fields and logic | Which reports need to be recreated? |
| Historical data | Years of closed records can increase migration effort | Migrate, archive, or leave accessible separately? |
1. The Data Model Changes
BMC Remedy data migration starts with field mapping, but the real work is deciding how Remedy records fit ServiceNow’s tables.
Incidents, changes, users, groups, knowledge, service requests, and configuration items can all have custom fields or local naming conventions. A direct field-for-field copy can create confusing data in the target system.
ServiceNow import sets provide a staging area for imported records. Transform maps define how source fields map to target tables and fields, and ServiceNow requires at least one transform map for every import to a production table. Its documentation also warns against extremely large import sets because they can create delays or outages.
Before migration, classify fields into three groups:
- Required: needed for current processes, reporting, compliance, or open work.
- Transform: still useful but needs a different format or destination in ServiceNow.
- Retire: old fields with no current business use.
This is where BMC to ServiceNow migration starts becoming a cleanup project rather than a data-copy exercise.
2. CMDB Migration Requires More Than Moving CIs
CMDB migration is one of the highest-risk parts of an ITSM migration because poor configuration data affects incident, change, and service-impact decisions.
ServiceNow’s Common Service Data Model, or CSDM, provides a standard structure for organizing configuration items and relationships across ServiceNow products. ServiceNow also uses the Identification and Reconciliation Engine to identify CIs, reduce duplicates, and control which data sources can update attributes.
That means a ServiceNow CMDB migration should review:
- which CI classes still matter;
- how relationships should be represented;
- which discovery or integration source is authoritative;
- duplicate and stale CIs;
- service ownership and naming.
Do not assume every Remedy class should have a matching ServiceNow class. The target CMDB should support the way the business wants to manage services after migration.
3. Workflows and Customizations Need to Be Rebuilt Selectively
Workflow migration is where many Remedy programs become expensive.
A mature Remedy environment can contain years of custom approvals, escalations, scripts, forms, routing rules, notifications, and exceptions. Those rules reflect past business needs. Some are still valuable. Others survive only because nobody has removed them.
For each workflow, ask:
Does the business still need this behavior?
If yes, decide whether standard ServiceNow capability already covers it. Rebuild custom logic only when there is a clear requirement.
A useful rule is:
- Migrate when the information must move.
- Rebuild when the process is still required but should use ServiceNow-native design.
- Retire when the process no longer serves a purpose.
- Archive when records must remain accessible but do not need to live in the active platform.
This approach keeps ITSM modernization from becoming a recreation of the old Remedy environment.
4. Service Catalog Items and Request Flows Change
Service catalog migration needs its own review.
Catalog items often contain forms, approvals, fulfillment tasks, and integrations. Duplicate or rarely used requests may also have accumulated over time.
Start with usage and business relevance.
Keep the services employees still need. Combine duplicate requests. Remove obsolete catalog items. Then rebuild the approval and fulfillment flow in ServiceNow.
This also creates an opportunity to simplify the user experience. A cleaner catalog can reduce unnecessary choices and make self-service easier after launch.
5. Knowledge Migration Should Include Cleanup
Knowledge migration is another area where moving everything can create problems.
Old Remedy knowledge bases can contain duplicates, expired instructions, broken links, and content with unclear ownership.
Before moving content, check:
- whether the article is still accurate;
- whether someone owns it;
- whether the metadata is useful;
- whether attachments and links still work.
ServiceNow knowledge should start with trusted content. Historical material that still needs to be retained can be archived outside the active knowledge base.
6. SLAs Must Be Recreated and Tested
SLA migration affects business commitments directly.
Remedy and ServiceNow can represent priorities, calendars, pause conditions, and escalation logic differently. A rule that looks equivalent on paper can behave differently after migration.
Document the current SLA logic before configuration starts. Then recreate the required commitments and test them using real scenarios.
Pay particular attention to:
- start and stop conditions
- business calendars
- priority changes
- pause rules
- escalation behavior
The objective is continuity for commitments that still matter, not a literal copy of every old rule.
7. Integrations Usually Need Redesign
Most enterprise Remedy environments connect to other systems.
Common examples include monitoring, identity, HR, ERP, DevOps, and discovery tools. Each integration needs a fresh technical review.
The ServiceNow side may use APIs, IntegrationHub, import sets, or IntegrationHub ETL depending on the target. ServiceNow documents IntegrationHub ETL specifically for bringing third-party data into the CMDB or supported non-CMDB tables while preserving data integrity.
For every integration, decide:
- Is it still required?
- Is there a ServiceNow-supported connector or better integration pattern?
- What authentication and security changes are needed?
- Who owns monitoring and failures after launch?
This is a good place to remove point-to-point integrations that no longer add value.
8. Roles, Permissions, and Support Groups Need Mapping
Remedy roles should not be copied blindly into ServiceNow.
Map users based on what they need to do after migration. Review administrators, fulfillers, support groups, approvers, and service owners separately.
This is also the right time to remove dormant accounts and excessive permissions.
Security testing should confirm that users can see the records and actions they need without inheriting unnecessary access from the legacy platform.
9. Reports and Dashboards Need to Be Recreated
Existing Remedy reports may depend on custom fields, old status values, or reporting logic that does not exist in ServiceNow.
Start by asking which reports people still use for decisions.
Rebuild those reports against the ServiceNow data model. Retire reports that exist only because they have always existed.
This also avoids carrying old reporting logic into a platform where the underlying process has changed.
10. Decide How Much Historical Data to Move
Historical data can become one of the biggest scope drivers in a BMC Remedy to ServiceNow migration.
Enterprises may have years of closed incidents, changes, attachments, audit records, and knowledge.
Not all of it needs to sit in the active ServiceNow instance.
A practical split is:
- Open and active records: migrate.
- Recent history needed for operations or reporting: migrate selectively.
- Older records required only for audit or reference: archive with controlled access.
- Obsolete data: retire according to retention policy.
The exact cutoff depends on legal, reporting, support, and compliance requirements.
11. Cutover Changes How Work Moves Between Systems
Cutover needs more than a final data load.
The team needs a clear point when Remedy stops accepting normal work and ServiceNow becomes the system of record.
Typical cutover work includes:
- final delta migration
- open-ticket validation
- integration switchovers
- user and role checks
- service-desk communication
- rollback planning
Run cutover rehearsals before production launch so fewer decisions are left for the final transition window.
What Should Be Preserved During Migration?
The strongest Remedy migrations preserve business value, not legacy complexity.
Preserve:
- accurate data that supports current work
- proven service processes
- critical integrations
- compliance records
- knowledge employees still use
Challenge everything else.
If a customization, workflow, report, or catalog item cannot be tied to a current requirement, migration is a good time to remove it.
BMC Remedy to ServiceNow Migration Checklist
Before cutover, confirm that the program has completed these checks:
- Current Remedy environment inventoried
- Data mapped and cleansed
- CMDB classes and relationships reviewed
- CSDM approach defined where relevant
- Customizations classified as migrate, rebuild, retire, or archive
- Service catalog and approvals rebuilt
- Knowledge content reviewed
- SLA logic tested
- Integrations validated
- Roles and permissions tested
- Required reports recreated
- Historical-data scope agreed
- Cutover rehearsal completed
- Rollback plan documented
- Users and support teams prepared
Final Takeaway: Use Migration to Simplify the ITSM Environment
A BMC Remedy to ServiceNow migration is a chance to clean up years of accumulated process and data complexity.
The most important decisions happen before records move. Teams need to decide what data belongs in ServiceNow, which workflows are still useful, how the CMDB should be structured, and which integrations should survive.
That keeps the project focused on a cleaner ServiceNow environment instead of reproducing every legacy Remedy decision.
Intelegencia supports BMC Remedy migration to ServiceNow across current-state assessment, data and workflow mapping, CMDB planning, integration review, implementation, testing, and cutover. The first step is a migration assessment that separates what the business still needs from what can be left behind.
FAQs
Frequently Asked Questions
Typical scope can include incidents, changes, users, knowledge, configuration items, catalog data, and selected history. Final scope depends on business need, retention requirements, and the target ServiceNow design.
