What is your approach to a complex ServiceNow migration?

[ravivsnow]

What is your approach to a complex ServiceNow migration?

I’d like to hear from architects and practitioners who have worked on large ServiceNow migrations.

Suppose an organization is migrating from one ServiceNow instance to another with:

> Large CMDB
> Multiple integrations
> Custom applications
> Discovery and Service Mapping
> Complex CI relationships and dependencies
> Significant historical data

How would you approach the migration?

> Would you migrate everything or selectively migrate data?
> Would you clean the CMDB before migration or after?
> Would you migrate foundation data first?
> How would you preserve CI relationships and references?
> What approach or tools would you use for large-volume data migration?
>How would you validate source vs. target data?
> How would you handle integrations during cutover?
> What would your rollback strategy look like?

Most importantly, what is one migration mistake you would never repeat?

I’m particularly interested in real project experiences and lessons learned, rather than only the theoretical approach.

[sachinvic]

HI @ravivsnow

For this scenario, I would recommend a selective, dependency-driven migration rather than a full lift-and-shift.
A practical approach would be:

1. Assess & rationalize: Inventory applications, customizations, integrations, CMDB, relationships, and historical data. Classify each as Migrate, Remediate, Replace with OOB, or Retire.

2. Foundation data first: Establish users, groups, companies, locations, services, and other reference data before migrating dependent records.

3. CMDB: Since the target already contains CMDB data, reconcile source vs. target rather than blindly migrating it. Use IRE/identification rules to match existing CIs and avoid duplicates.

4. Sys IDs & references: Don't use the source Sys ID as the business identifier. Maintain a source-to-target mapping and preserve business/functional identifiers. Remap references to the corresponding target records.

5. Relationships: Migrate CIs first, followed by CI relationships and dependent data. Validate relationship integrity as part of each migration wave.

6. Customizations: Review customizations before migration and replace them with OOB capabilities where possible. Avoid carrying unnecessary technical debt into the target.

7. Integrations: Revalidate endpoints, credentials, MID Servers, flows, and integration dependencies in the target. Handle integration cutover separately.

8. Validation: Reconcile record counts, key identifiers, references, relationships, and business functionality between source and target.

9. Cutover: Perform the final delta migration, freeze source changes, validate the target, then enable integrations and business processes. Maintain a rollback/read-only strategy until business sign-off.

Migration approach:
Assess >> Rationalize >> Foundation >> CMDB >> Applications/Data >> Relationships >> Integrations >> Validation >> Cutover

The biggest mistake you should avoid is starting the migration before defining the source-to-target mapping and dependency model. With existing CMDB and complex relationships, this is critical to avoid duplicates, broken references, and inconsistent data.

[Mathieu Lepoutr]

Dear  

Been through a few of these (ServiceNow-to-ServiceNow, and Jira-to-Jira which has the same CMDB/relationship headaches). Here's what's actually worked:

Migrate selectively, not everything. A full lift-and-shift just carries your mess into the new instance. Migrate active/referenced data and whatever compliance requires you to keep; archive the rest and make it retrievable but not part of the live CMDB.

Clean the CMDB before, not after. Cleaning up stale CIs, duplicate records, and orphaned relationships is hard enough on its own. Doing it at the same time as debugging a new instance's quirks is how projects stall for months.

Foundation data first, then CI classes/CMDB structure, then transactional/historical data. Trying to do it in any other order means you're constantly going back to fix references.

Preserving CI relationships is the part that bites people. Keep a mapping table between old and new sys_ids so you can rebuild relationships after CIs land in target, don't rely on them surviving import as-is. Discovery and Service Mapping data is usually better rerun in the new instance than migrated, since a lot of it is derived and instance-specific anyway.

Tooling: straightforward tables can go through Import Sets/Transform Maps. Once you're dealing with CMDB relationships at volume, plain CSV import falls apart, most teams end up scripting against the mapping table or using dedicated migration tooling built for this.

Validation: row counts are the easy part. What actually breaks silently is relationship integrity, so spend your validation time there, not on counting records.

Cutover/integrations: if you can't do a hard cutover, you're running two systems live simultaneously for some period, which means two sources of truth for anything still active.

Rollback: freeze the old instance read-only, decide your rollback triggers before go-live, and don't decommission until target has proven itself in production for a real stretch of time, not just a few days.

Mistake I'd never repeat: migrating CI relationships without validating referential integrity in the target before go-live. Broken or duplicated relationships are far more painful to chase down once people are working in the new instance.

On Exalate, since I work there and want to be upfront about that: it can also be used for migrations, not just live two-way sync. The approach is entity-by-entity: you trigger sync on records matching a condition (a JQL-style query on the Jira side, similar filtering on ServiceNow), it carries over the record plus relationships and custom fields, and you run it in batches rather than one big dump. There's also a relink/bulk-connect function for mapping records that already exist on both sides via CSV, useful if you're partway through a migration done some other way and need Exalate to pick up sync from there.

Where it fits your scenario specifically: migrating active CIs, incidents, and changes with their relationships intact, in batches, while keeping old and new instances in sync during cutover so you're not forced into a hard switchover. Where it doesn't fit: bulk historical data at the database/table level, or Discovery-derived CMDB data, that's not what it's built for, and I wouldn't try to force it there. For the parts of this migration that are really about live parallel operation and controlled cutover, it's worth a look alongside dedicated migration tooling for the raw data volume.

Kind regards,

Mathieu Lepoutre