Seeking Best Practices for Migrating an Existing ServiceNow Instance into a Brand-New MSP instance

[MiaoZhan]

I’m working with a customer who plans to migrate their current ServiceNow production instance into a brand-new MSP (Managed Service Provider)-hosted instance.

Specific Questions:

• What is the recommended high-level approach? (e.g., Cloning? UpdateSets move?)
• If Cloning is Yes, may i know the Cloning best practices specific for instance migration?
• How do you identify and isolate "must-migrate" vs. "leave behind" customizations in a legacy instance?
• How have others handled integration reconfiguration (e.g., SSO, email, REST APIs) when endpoint
• URLs/credentials change in the new environment?
• Are there common pitfalls to avoid when migrating into an MSP-managed topology ?

We’re aiming for a clean, maintainable foundation—not just replicating technical debt. Any templates, checklists, or lessons learned from similar MSP onboarding/migration projects would be greatly appreciated!

[Tanushree Maiti]

Cloning is technically feasible to clone a non-domain separated ServiceNow instance (source) to a domain-separated instance (target). However, doing so is highly complex, risky, and generally discouraged because it can break the domain structure of the target instance. 

So first ensure your non-domain SN instance (From) and domain separated instance (To) are having same version ( if possible match the patch version as well)

 - First finalize your scope document with identified components which you wants to migrate to Domain separated instance.

- Migrate identified foundation data using xml export ensuring the sys_domain field is mapped to specific domain. 

-Handling Update Sets:

• Visibility: Update sets, even when created in specific domains, often appear under the Global domain during the import process.
• Commit Procedure: To avoid visibility issues during migration, ensure your user session is in the Global domain when importing and committing update sets.
• Adjusting Domain: After committing, move customizations from Global to the specific child domains as required. 

- Then start migrate customization using update set on different module like incident , problem ,change and incident task , problem task, change task etc.

- Integration connection, credential - try to update manually . In integration space , lots of integration testing, regression testing is required for each and every integration. For Lots of integration where your instance was pulling data , 3rd party needs to update/replace endpoint at their end.

- SLA configuration ( We did it manually where customer provided the data in Excel) - you can do it using update set with related schedule.

- SSO/email notification ,event -  you can migrate using  update set.