Best Practice for Migrating Legacy Custom Parent-Child Data to CSM Case and Case Task

[Sachin Gavhane]

Best Practice for Migrating Legacy Custom Parent-Child Data to CSM Case and Case Task

Hi Community,

We are currently planning a data migration from an existing legacy Guest Relations application into a new ServiceNow Customer Service Management (CSM) implementation.

Current legacy data model

In the old Production instance, we have two custom tables:

• Guest Relation – parent table
• Issue Camp – child table

The relationship is:

Guest Relation
      |
      | 1:N
      v
Issue Camp

A Guest Relation can therefore have multiple Issue Camp records.

New target data model

In the new DEV instance, these legacy tables do not exist. Instead, we are using the OOTB CSM data model:

• Guest Relation → Customer Service Case (sn_customerservice_case)
• Issue Camp → Case Task (sn_customerservice_task)

The expected relationship is:

Customer Service Case
        |
        | Parent Case
        v
Case Task

So the requirement is to transform the legacy parent-child data model into the CSM Case / Case Task model while preserving the historical relationship between the records.

Main concern

The biggest challenge is maintaining the relationship between the migrated Issue Camp records and their corresponding newly created Cases.

For example:

Legacy:

Guest Relation GR001
   ├── Issue Camp IC001
   ├── Issue Camp IC002
   └── Issue Camp IC003

should become:

New CSM:

Case CS000123
   ├── Case Task CT000001
   ├── Case Task CT000002
   └── Case Task CT000003

where all three Case Tasks have the migrated Case as their Parent Case.

Questions

1. What would be the recommended ServiceNow best-practice approach for this type of legacy-to-CSM data migration?
2. Would you recommend using:
   • Import Set + Transform Map for Guest Relation → Case
   • Import Set + Transform Map for Issue Camp → Case Task
   • A temporary legacy-ID/mapping field or mapping table to establish the Case → Case Task relationship?
3. What is the recommended way to preserve the relationship between the old Guest Relation sys_id and the newly created Case sys_id?
4. Should we maintain a temporary legacy_sys_id field on the Case during migration, or is there a better ServiceNow-supported approach for maintaining this mapping?
5. Are there any concerns with directly transforming legacy records into the OOTB CSM Case and Case Task tables, particularly around Business Rules, Flows, Notifications, SLAs, ACLs, or other CSM automation being triggered during migration?
6. Would you recommend temporarily disabling applicable automation during migration, or using migration-specific logic/flags to prevent unwanted downstream processing?
7. Are there any specific considerations for migrating:
   • State/status
   • Account/Contact/Consumer references
   • Assigned groups/users
   • Work notes/comments
   • Attachments
   • Created/Updated dates
   • Historical/audit information
   • Reference fields and choice values?
8. Would you recommend migrating all historical Guest Relations and Issue Camps into the OOTB CSM tables, or keeping some historical data in a separate legacy/archive table depending on volume and business requirements?
9. What validation strategy would you recommend to ensure that the parent-child relationships and record counts are preserved after migration?

Expected result

Our objective is to use the OOTB CSM data model rather than recreating the legacy Guest Relation and Issue Camp tables in the new instance, while preserving the historical data and the relationship between Guest Relations and their respective Issue Camps.

Any recommendations, lessons learned, or reference architecture for similar CSM legacy-data migrations would be greatly appreciated.

Thanks!