Need help with migration approach suggestions for a complex scenario

[Sdas1]

Hello All,

I am involved in a large scale  migration initiative involves consolidating GRC capabilities from a source ServiceNow platform into a target ServiceNow platform while preserving both System IDs (Sys IDs) and business/functional identifiers.

GRC scoped applications will be migrated as as-is along  while required global-scope configurations to determine whether they can be aligned to out-of-the-box platform capabilities.

The challenges we are facing:

• No structured repository, implementation plan, or deployment sequence documentation exists for historical update sets.
• The environment contains over 7000 update sets combining GRC and global scope, creating significant complexity for dependency analysis and deployment sequencing.
• Considerable effort will be required to identify dependencies, eliminate redundant customizations, and define a reliable migration path.
• Foundational, operational, and CMDB data already exists and is actively used in the target environment.
• Preserving referential integrity between migrated records and existing platform data will require a Sys ID re-keying strategy for affected foundational and CMDB records.
• Historical relationships, references, and business identifiers must be maintained to ensure continuity of business processes.

Any suggestions will be really appreciated.

[sachinchaudhary]

@Sdas1 

Hi,

Given the volume of update sets and the requirement to preserve Sys IDs, business identifiers, and historical relationships, I would avoid treating this as a straight update-set migration.

I would recommend a two-track migration approach:

1. Application & configuration migration

• Inventory and classify the 7,000+ update sets by application, scope, dependency, and business relevance.
• Build a dependency matrix for GRC, Global configuration, plugins/features, tables, ACLs, Script Includes, Business Rules, flows, etc.
• Consolidate/remove redundant customizations before migration rather than carrying the entire technical debt forward.
• Migrate in functional waves, starting with foundational dependencies and then GRC capabilities.

1. Data & relationship migration

• Treat existing target data as a separate migration stream.
• Define the Sys ID strategy upfront. Do not re-key records until all references and relationships have been mapped.
• Maintain a source-to-target cross-reference for every migrated record, including Sys ID and business identifier.
• Pay particular attention to CMDB relationships, references, historical records, and any integrations relying on Sys IDs.

For the 7,000+ historical update sets, I would first perform an impact/dependency assessment and create a migration backlog rather than deploying them sequentially in their current state. This will help identify which changes are still required, which are already available OOTB in the target, and which can be retired.

Recommended sequence:
Discovery >> Dependency analysis >> Rationalization >> Target design >> Foundation >> GRC applications/configuration >> Data migration >> Validation >> Cutover

The most important decision here is the Sys ID preservation strategy. I would validate that first in a representative lower environment, because changing Sys IDs later can have a significant impact on references, integrations, CMDB relationships, and historical continuity.