ServiceNow Go-Live Data Cloning Strategy

[Manish Shetty]

Hello All,

I am currently working on a ServiceNow greenfield implementation, which includes three instances: Development, Test, and Production.

I would like to understand the best approach for go-live in terms of data cloning. Once we decide to go live, should we clone the Production instance to both Test and Development before the go-live date? Or should cloning be done only in the Test instance, leaving Development as it is?

Additionally, I would appreciate any guidance on the checklist of changes or checks that need to be performed post-cloning in the sub-production instances.

Thank you,

Manish

[Dr Atul G- LNG]

Hi @Manish Shetty 

I would like to understand the best approach for go-live in terms of data cloning. Once we decide to go live, should we clone the Production instance to both Test and Development before the go-live date? Or should cloning be done only in the Test instance, leaving Development as it is?

Atul: 

As per my understanding, cloning is typically done when planning to upgrade the instance, not at the time of go-live. In this case, there’s no need to clone Dev or Test from Prod. Since you're following a greenfield approach—going live for the first time—your Prod instance is already clean, and Dev/Test contain the stories that will be moved to Prod.

So, cloning isn't required at this stage. Once you go live and later decide to upgrade, that’s when I’d recommend going for cloning, mate.

"The cloning sequence is from Prod to Dev and Test. When we perform cloning, the entire instance is cloned, including configurations and data."

Additionally, I would appreciate any guidance on the checklist of changes or checks that need to be performed post-cloning in the sub-production instances.

Atul: I want to understand your usecase / Business need of cloning. Cloning and go-live are two different things

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0547597

[tiagomacul]

My recommendation is to clone Production down to both Test and Development instances before or after the go-live date, but not shortly before the GoLive.

However, for your first Go-Live, it's wiser to prevent potential issues by considering the Development instance as a recovery point.

back to the first thinking...

Test Instance : Cloning Production to Test ensures that your final round of user acceptance testing (UAT), performance testing, and integration testing is performed on data that is as close as possible to the live environment. This significantly reduces the risk of encountering unexpected issues in Production post-go-live due to data discrepancies.

Development Instance for Immediate Post-Go-Live Support: Cloning Production to Development provides a stable and data-rich environment for developers to investigate and resolve any critical issues that might arise immediately after go-live. Having production-like data in Development helps in replicating and diagnosing problems more effectively.

Freshness of Data: Cloning close to go-live minimizes the data drift between your sub-production environments and Production.

Why not clone only to Test?

While cloning only to Test is an option, it can create challenges for immediate post-go-live support. If a critical issue arises, developers might have to try and replicate it on potentially older or less representative data in the Development instance, slowing down the resolution process.

Timeline Consideration:

Plan the clone operation carefully, considering the size of your Production instance and the time it takes to complete the clone and subsequent post-cloning activities. You'll want to schedule this in a window that minimizes disruption and allows sufficient time for testing in Test.

Important Considerations:

• Clone Exclusions: Carefully plan your clone exclusions to reduce the size and duration of the clone. Exclude non-essential tables like logs, audit history, and large temporary tables.

• The Preserve Data functionality in ServiceNow allows you to protect specific data on your target (sub-production) instance from being overwritten during a clone from a source instance (typically Production).  

• Communication: Keep all stakeholders informed about the cloning schedule and the expected downtime.
• Backup: Ensure you have a recent backup of your Production instance before initiating the clone.
• Documentation: Document your cloning process and the post-cloning checklist for future reference.

• https://macul.medium.com/como-solicitar-clone-de-ambiente-c0a17af60c77
• https://www.servicenow.com/community/brazil-snug/como-solicitar-clone-de-ambiente/td-p/222157
•  

[jack5253]

Hello,

In a ServiceNow greenfield implementation involving Development, Test, and Production instances, the best practice for go-live data cloning typically involves cloning Production to Test only, not to Development. The rationale is that the Test instance should mirror Production as closely as possible to validate post-go-live behavior, conduct final testing, and support any immediate post-go-live fixes. Development, on the other hand, should retain its current state to preserve in-progress configurations and future enhancements.

Post-cloning, ensure the following key checks are performed in the Test instance:

• Re-establish any MID server configurations

• Reconfigure integration credentials and endpoints (these are wiped during cloning)

• Validate email configurations to avoid accidental email triggers

• Disable any scheduled jobs that should not run in Test

• Restore any custom system properties or update sets

• Confirm user roles and access settings are appropriate for a sub-prod environment

Keeping Development untouched ensures continued configuration work without risk of overwriting ongoing development efforts. Samsara Island 

[VikMach]

Hi @manish,

Attached ServiceNow's best practices slides PPT. Go through the PPT to understand System Clone Management - Overview and Practical Guidance.

Additional basic guide is mentioned in - https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1214608 

Let me know if it helped!

Regards,
Vikas K