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.

[fknell]

@Tanushree Maiti I doubt the MSP would allow what you are suggesting. Furthermore some of the recommendations are not doable (e.g. moving workflow / customization from top to domain scope) or not recommended, because you will create technical dept. for the MSP team, who has to manage the domain separated instance. 

[Vishal36]

Hi @MiaoZhan, 

Moving a ServiceNow production instance into an MSP-managed tenancy is a big opportunity to reset and standardize.

A few things I’d encourage you to think through upfront:

• Approach choice: Cloning can be efficient, but only if you first clean up unnecessary configs; UpdateSets work best for controlled, selective moves.
• Cloning best practices: If you do clone, trim out deprecated apps, unused tables, and old integrations first, then snapshot and validate in a staging MSP instance.
• Must-migrate vs leave behind: Do an inventory of customizations vs usage — gauge business value + frequency of use; archive or refactor low-value customizations.
• Integrations & endpoints: Plan to reconfigure SSO, email, API endpoints post-migration; version control and automated environment configs help.
• Common pitfalls: Carrying technical debt forward, missing dependencies, and skipping thorough pre- and post-migration validation.

In your case, you may want to explore OpsHub Migration Manager (OMM). It supports phased or full instance migrations, ensures no downtime or disruption, and preserves historical fidelity-including comments, attachments, relationships, and field mappings. As a ServiceNow Partner, we’ve helped teams transition cleanly while avoiding replication of legacy issues.

All the best!

[fknell]

Hi @MiaoZhan,

would you please clarify what you mean by MSP hosted instance? A self-hosted instance from a MSP or a domain separated instance of a MSP?

One option is a green field, the other is adjusting to an already defined framework from the MSP, and you can slightly (<20%) adapt / overwrite existing skeleton workflow.