ServiceNow-to-ServiceNow Move – Full Instance Clone vs Data Migration

Mansor2
Tera Contributor

 

Hello experts,

 

We are assessing the best approach for moving an existing ServiceNow production instance to a newly provisioned, empty ServiceNow instance.

The requirement is largely like-for-like, driven by a commercial/licensing change rather than platform redesign or technical-debt removal.

Current context:

  • Source and target are ServiceNow cloud instances
  • Source and target can be aligned on the same release (Zurich) for the transition
  • Target is newly provisioned and empty
  • Approximately 7 million records are in scope, including attachments
  • Requirement is to retain existing sys_ids, historical data, audit history, work notes/comments, attachments, custom tables/fields, CMDB relationships, active tickets, configurations, and customisations as far as technically supported
  • Existing integrations are expected to continue
  • Upgrade to the next release would be handled separately after cutover and stabilisation

We are currently considering:

  1. Full instance clone from the existing production instance to the new target instance
  2. Full data migration into the new target instance (Specialized tool)

Given that the objective is near like-for-like preservation rather than transformation, I would appreciate views from anyone who has handled a similar scenario:

  • Is a full instance clone a practical and supported approach for this type of production-to-new-production transition?
  • For an instance with approximately 7 million records, what factors most influence clone duration, and what indicative execution windows have you experienced?
  • For a production-to-new-production clone, is there typically any ServiceNow professional services, platform, or operational charge associated with executing or supporting the clone? If so, what indicative cost range have others experienced?
  • Does the clone preserve the ServiceNow-side integration configuration and customisations, with post-clone work primarily limited to validation and environment-specific items such as credentials, OAuth, certificates, MID Servers, endpoints, webhooks, and allowlists?
  • What key clone exclusions or post-clone remediation areas should we plan for, particularly around audit history, attachments, active Workflow/Flow Designer contexts, scheduled jobs, email, and integration runtime state?
  • Are there specific reasons you would still favour a full data migration over a clone for a largely like-for-like requirement?

Interested in practical experience, indicative timelines/costs, and lessons learned from similar ServiceNow-to-ServiceNow transitions using the clone method. I do have the migration timeline and costs associated. 

 

Thanks in advance.

Mansor

 
 
 
 
 
 
 
 
 
 
0 REPLIES 0