ServiceNow-to-ServiceNow Move – Full Instance Clone vs Data Migration
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
2 hours ago
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:
- Full instance clone from the existing production instance to the new target instance
- 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