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

Sachin Gavhane
Tera Guru

‎08-14-2026 06:11 AM

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!

Labels:
  • 747 Views
1 REPLY 1

Jon Wu
Tera Contributor

2 hours ago - last edited 2 hours ago

For your Q1-4 , I would explicitly use Correlation ID to the design because it provides a cleaner mechanism for source-to-target traceability than adding a migration-only custom field.

 

Recommended pattern

The important principle is:

The new Case keeps its ServiceNow-generated number , the legacy Guest Relation identifier is retained as correlation/migration identity.

Then migrate the children:

 

Legacy Issue Camp
parent = GR001
│
│ Transform
│
├─ Find Case where:
│ correlation_id = GR001 / GR001_sys_id
│
▼
CSM Case Task
parent/case = CSXXXXXXX

 

This aligns neatly with the two-stage Import Set pattern discussed earlier. ServiceNow's Transform Maps support scripted transformation logic and reference-field mapping, including onBefore processing before the target row is transformed. 

 

Coalesce logic

I would also consider using the parent's Correlation ID as the coalesce key during the parent import, provided the source identifier is unique for the migration population.

Conceptually:

ServiceNow documents that Transform Maps evaluate the coalesce fields to locate the target record before onBefore processing and the subsequent field transformation.

 

For that reason, if Correlation ID is going to participate in coalescing, populate/map it in a way that is available to the coalesce evaluation rather than relying on onBefore to construct it.

 

Child logic is slightly different

I would not coalesce the Case Task using the parent's Guest Relation ID, because multiple Issue Camps can belong to one Guest Relation. Instead give each child its own legacy identity:

 

Parent:
Guest Relation ID / Guest Relation_sys_id
→ Case.correlation_id
 
Child:
Issue Camp sys_id
→ Case Task correlation/migration identifier
 
Issue Camp.parent
→ lookup Case.correlation_id
→ Case.sys_id
→ Case Task parent/reference

 

So:

 

GR001
│
├── IC001
├── IC002
└── IC003
 
becomes
 
Case
correlation_id = GR001 / GR001_sys_id
│
├── Case Task [legacy ID = IC001]
├── Case Task [legacy ID = IC002]
└── Case Task [legacy ID = IC003]

 

That distinction is important:

Correlation/coalesce answers “which target record represents this source record?”

Parent lookup answers “which newly migrated Case should this Case Task reference?”

 

One caution:

ServiceNow specifically warns that reference fields need careful handling during transforms when the referenced target does not exist. Therefore I would make parent migration completion and reconciliation a prerequisite to the child transform. If an Issue Camp's Guest Relation Correlation ID cannot resolve exactly one Case, reject/quarantine that child rather than allowing an orphan or incorrect relationship.

 

This actually makes the proposed migration considerably more OOTB-first:

use Correlation ID for source traceability/coalescing, use the resulting Case sys_id for the real CSM relationship, and avoid creating migration-only fields on Case unless there is a demonstrated gap.

0 Helpfuls