Cloning

ServiceNow cloning is a foundational concept for anyone working with multiple instances (Prod, Test, Dev, etc.). This document explains what cloning is, why it is used, and what risks and considerations come with it—especially for teams new to the ServiceNow platform.

Definitions⚓︎

Before diving deeper, it is helpful to define some common cloning-related terms:

Cloning: The process of copying data and most configuration from one ServiceNow instance to another. The target instance is largely overwritten with data from the source instance.
Source Instance: The instance you are cloning from. This is most commonly the Production (Prod) instance, as it contains the most complete and accurate data.
Target Instance: The instance you are cloning to, such as Development (Dev), Test, or QA. This instance will be overwritten during the clone.
Preservers: Rules that prevent specific tables or fields on the target instance from being overwritten during the clone. Preservers are typically used to protect environment-specific data such as credentials, URLs, or local configuration.
Post-Clone Activities: Scripts or manual steps performed after a clone completes to reconfigure the target instance. These tasks ensure the instance is safe and usable after being refreshed.

What Happens During a Clone⚓︎

When a clone runs, the majority of data and configuration from the source instance replaces what exists on the target instance. This includes records such as incidents, changes, users, groups, and configuration records. Customizations (like business rules, Script Includes, and workflows) are also copied over.

Warning

It is important to understand that *cloning is destructive to the target instance. Anything not preserved will be lost. For this reason, cloning should be planned carefully and coordinated with development and testing activities.

Why Clone?⚓︎

Cloning is most often used to keep non-production environments aligned with Production data. Having realistic data in Dev or Test allows teams to:

Reproduce and troubleshoot Production issues
Test changes against real-world datasets
Validate upgrades and patches
Train users in a realistic environment

Without cloning, non-prod instances can drift significantly from Prod, making testing less reliable and increasing the risk of surprises during deployments.

Considerations for Cloning⚓︎

Cloning is powerful, and it requires deliberate preparation each time it is performed. Because a clone overwrites most data and configuration on the target instance, teams must account for environment-specific settings and operational safeguards.

One of the most important preparation steps is configuring Preservers. Preservers protect data on the target instance that should remain unique and should not be replaced with values from the source instance. Common examples include: - Integration credentials and API keys
- System properties with environment-specific values (eg Dev ServiceNow is connected to Dev SalesForce) - Authentication provider configuration

In addition to preservers, teams should plan and document post-clone activities. These are actions taken after the clone completes to ensure the instance is safe and usable. Typical post-clone tasks include: - Disabling or redirecting outbound integrations - Turning off scheduled jobs and email notifications - Re-configuring MID Servers and integration endpoints - Restoring developer access, test users, or non-prod-only roles

Failing to account for these considerations can leave the target instance unstable, insecure, or unintentionally connected to production systems.

Considerations Before Your First Clone⚓︎

Before performing a company’s first ServiceNow clone, cloning should be treated as a program-level milestone, not just a routine platform task. The first clone often exposes gaps in governance, development practices, and environment management that were previously hidden.

A key area to assess is organizational readiness. Teams must clearly understand that cloning is destructive to the target instance and that any work not properly tracked (for example, changes made outside update sets or application repositories) may be lost. Many organizations discover during their first clone that they need stronger development standards, clearer promotion paths, or better documentation.

It is also important to establish security and access expectations before the first clone. Since users, roles, and group memberships are copied from Production, organizations should define what access is appropriate in non-production environments and document how that access will be restored or adjusted after a clone. For example, it's common for users in Dev to have more rights and access than they might in Prod. One example would be letting users create Flows in Dev but not Prod.

Finally, ownership and communication should be formalized early. Decide who is responsible for requesting, approving, executing, and validating a clone. Stakeholders across development, testing, integration, and business teams should know when cloning will happen and what impact to expect. A well-defined checklist and runbook created for the first clone often becomes the standard for all future clones.

Questions to Ask Before the First Clone⚓︎

What data or configuration must be protected on the target instance?
Which tables or fields require preservers?
How will user access and roles be handled post-clone?
Who owns post-clone validation and sign-off?
How will stakeholders be notified before and after the clone?
What evidence will confirm the clone was successful?
How will lessons learned from the first clone be captured and reused?

Addressing these questions early helps ensure the first clone is controlled, predictable, and repeatable. It also lays the groundwork for mature and sustainable ServiceNow environment management.

Risks of Cloning⚓︎

One of the biggest risks of cloning is unintentionally impacting external systems. If integrations are not preserved or disabled, a cloned Dev instance might send test data to real vendors or downstream systems. Another major risk is credential exposure, where Production service accounts or passwords become accessible in non-production environments.

Cloning can also cause confusion for users. User access, group membership, and roles are copied from Prod, which may give users access in Dev that they do not normally need, or that they should not have at all.

Why Dev Should Not Be Exactly Like Prod⚓︎

Although cloning makes instances look identical at first glance, Dev and Prod serve very different purposes. Development instances often require: - Elevated admin access for developers - Mock or sandbox API endpoints - Test credentials instead of real ones - Relaxed security controls for troubleshooting - Different API endpoints (Dev ServiceNow to Dev Workday or Dev SalesForce)

Production, on the other hand, prioritizes stability, security, and auditability. Allowing Dev to remain exactly like Prod undermines safe development practices and increases security risk. Cloning should be seen as a starting point—not the final desired state—for non-production environments.

Summary⚓︎

ServiceNow cloning is a critical tool for maintaining healthy non-production environments, but it must be handled with care. Understanding key concepts like source instances, preservers, and post-clone activities helps prevent common issues. When done thoughtfully, cloning provides realistic data for development and testing while still respecting the unique needs of each environment.