Article : ServiceNow Clone Made Easy – A Practical Step-by-Step Guide

Shashank_Jain
Kilo Sage

Hello All,
This is Shashank Jain. I have performed cloning for 3–4 different projects in my organization, and based on that experience, I decided to share an article to help others better understand the cloning process in ServiceNow.

 

In this post, we will cover:

 

  • What is Cloning in ServiceNow and Basic process overview

  • Key Points to Note While Cloning

  • Roles, Applications, and Modules for Cloning

  • Step-by-Step Cloning Process, Important Terms (Clone Profiles, Target Instance, Clone Request, Exclusions, Preservers, Clean Up Scripts, etc.), Which Tables to Preserve and Exclude.

  • Managing the Clone – modifying clone schedules, viewing clone status, reviewing clone history, and rolling back a clone

I have noticed that the complete cloning process is rarely explained in one place. In this article, we will go through the entire flow from a practical project perspective.

 

 

1. What is Cloning in Servicenow :

 

What is Clone - Cloning is typically used to copy a production instance to a pre-production instance (Dev, AQ) to test changes. 

System Clone Application - We use the system clone application to copy everything in a database from one instance to another.

 

A. Clone Process flow :

 

Screenshot (20).png

 

 

 

(Note: We will discuss each point in detail further.) 

 

1. Create a Target Instance - Define the instance that will receive the cloned data (e.g., Development, Test, or UAT).

2. Create a Clone Profile - In the clone profile, specify the target instance where you want to copy the data. Add the tables that need to be preserved and excluded. (We will explain what “preserve” and “exclude” mean in the next sections.)

3. Create a Clone Request - Once the clone profile is ready, use the related link “Create Clone Request.” Here, you select the profile, define the target instance, set the scheduled start time, and specify the users who will receive email notifications upon clone completion.

4. Finalize the Setup - After this step, your clone is fully configured in ServiceNow. The best part is that the same clone profile can be reused in the future. If you want to perform another clone on the same target instance, you only need to create a new clone request.

 

 

2.  Key Points to Note While Cloning :

 

A. Which Instances Work as Target Instances While Cloning ?

 

In ServiceNow, the production instance serves as the source instance, while sub-production instances (such as Development, Test, or QA) act as the target instances that are cloned.

There is a system property called glide.db.clone.allow_clone_target 

- This property determines whether an instance can be used as a clone target.

- Setting it to false prevents the instance from being cloned to, adding an extra safeguard to protect production.

- By default, the value is false for production instances and true for sub-production instances (Dev, QA, etc.).

 

B. Clone to a instance of a different version ?

 

The System Clone application in ServiceNow can target an instance running a different version than the source. A central web service manages the cloning process and automatically upgrades or downgrades the target instance version to match the source instance version.

This version-matching process begins up to eight hours before the time specified in the Date and Time field on the System Clone form. The web service also verifies that the target instance has sufficient disk space for the clone to proceed.

 

C. What to keep as backup while cloning ?

 

It is always recommended to take a backup of any in-progress work in the target instance before initiating a clone. This primarily refers to in-progress update sets, which should be exported and safely stored. Once the clone is completed, you can import them back into the target instance.

Note: This is important because in-progress update sets are not moved to production. After cloning, the target instance only contains production data, which means any ongoing work or update sets will be cleared. To avoid losing progress, always back them up and re-import after the clone is finished.

 

 

3. Roles, Applications, and Modules for Cloning :

 

A. Roles for performing clone in servicenow :

 

System Administrators can perform cloning tasks, whether it is creating a clone profile or creating a clone request.

 

In addition, ServiceNow provides specific out-of-the-box (OOB) roles to control access to the Clone application and its modules:

- clone_admin – Can read, write, and configure all elements of the Instance Clone application.

- clone_profile_admin – Can read, write, and configure Clone Profiles.

 

B. Application and modules for cloning in servicenow :

(Refer below images)

 

Untitled-2025-08-15-1812.png

 

Untitled-2025-08-15-18122.png

 

 

4. Step-by-Step Cloning Process :

 

Now, let’s go through the complete guide for the clone process — from setting up the clone profile, defining the target instance, and creating the clone request.

For this walkthrough, we will take a scenario of cloning from the Production (PROD) instance to the Development (DEV) instance.

 

STEP -1  Create a target instance (Clone Target) :

 

A Clone Target record specifies the instance URL and credentials that will be used for cloning.

- Navigate to: All > System Clone > Clone Targets

- Click New

 

- Enter the URL for the receiving instance (target)

Note :

1.The system validates that the target instance allows cloning and that High Availability Cloning is active.

Production instances will fail this validation.

2.Verify the target instance system property: glide.db.clone.allow_clone_targetMust be set to True.

By default, this is enabled on instances ending in Dev, Test, Stage, UAT, or QA.

 

- Enter the basic authentication credentials of a user account with the admin role on the target instance. The system validates that the credentials have admin access.

Note - User credentials for the target instance:

1. Must be a user with the admin role.

2. Use a local account, not an LDAP or SSO account.

3. The user must exist in the User [sys_user] table or through an LDAP integration.

4. Clone requests cannot redirect authentication to an SSO identity provider.

 

- Click submit , Target instance is ready.

 

Untitled-2025-08-15-18123.png

 

STEP -2  Create a clone profile : 

 

In clone profile we define the target instance and tables to exclude, preserve with cleanup scripts.

- Navigate to System Clone > Clone Profiles

- Click new 

Untitled-2025-08-15-181245.png

 

 

- Click submit.

- After submitting the clone profile, now we have to define tables to preserve and exclude.

 

What is preserve and exclude :

Preserve :  These are tables whose data you want to retain in the target instance after cloning.

If a table is marked as Preserve, the target instance data remains unchanged for that table.

 

Exclude : These are tables whose data you want to exclude from being copied during the clone.

No data from the source instance is copied to the target for these tables. The target instance will either keep its existing data or remain empty for those tables.

 

How to preserve table : 

- Navigate to System Clone > Clone Definition > Preserve Data.

- Click New to create a preservation rule.

- Provide a Name, select the Table, and (if required) add a Condition to specify which records should be preserved.

- Save the record.

- In the Related List, click Edit and add it to your Clone Profile.

 

Screenshot (30).png

 

 

 

How to exclude table :

- Navigate to System Clone > Clone Definition > Exclude Tables.

- Click New to create an exclusion rule.

- Enter the Table Name to be excluded (e.g., sys_test) and click Save.

- In the Related List, click Edit and add it to your Clone Profile.

 

Screenshot (29).png

 

 

 

Good Practices for Preserve and Exclude Tables in ServiceNow Cloning :

 

Category                                 Table(s)                                         Action Reason                  Best Practice
Identity & Accesssys_user, sys_user_role, sys_user_has_role, sys_user_group, sys_user_grmemberPreserveKeeps target instance users, roles, and group memberships intact (so test/dev roles aren’t overwritten).
Instance Configurationsys_properties (selective), SSO/LDAP integration tablesPreserveRetain instance-specific configs (e.g., URLs, credentials, SSO settings) so target connects properly.
IntegrationsConnector configs (Workday, AD, custom integration tables)PreservePrevents breaking external integrations in lower instances.
Audit & Logssys_audit, syslogExcludeVery large and not useful in dev/test; saves space and improves performance.
Attachmentssys_attachment, sys_attachment_docExcludeAttachments consume huge disk space; typically not needed in lower instances. (Special handling exists; check KB)
Emailsys_email, sys_email_logExcludePrevents unwanted or accidental email delivery in dev/test; avoids clutter.
Analytics & Metricsusageanalytics_*, metric*, event/notification logsExcludeNot relevant for testing; speeds up cloning and reduces noise.
Historical / Large DataArchived incidents, history tables (e.g., ar_*)ExcludeReduces clone time and storage usage when old data isn’t required.

 

 

Preserve vs Exclude and what actually happens in different scenarios :

1000155248.jpg

 

What is cleanup script :

Clean Up Scripts = automatic “post-processing” for clones, to strip out junk or sensitive data and prepare the target instance for safe use.

- Runs only with cloning – Unlike Scheduled Jobs, clean up scripts are tied specifically to the clone workflow.
- Timing – Can execute at different stages:
Pre-clone → tasks before clone begins (e.g., disable business rules).
Mid-clone → actions during cloning (rarely used).
Post-clone → cleanup after clone finishes (most common).

Example :Deleting records from sys_email so test instances don’t send production emails, Clearing syslog or sys_audit data to reduce size, Resetting integration endpoints to dev/test values.

 

Note - There are OOB clean up scripts that are enough unless and until you have specific reason to create one.

 

Note - Now that we have created the target instance and clone profile, the next step is to create a clone request.

 

STEP -3 Create a clone request now : 

 

- In the Clone Profile, click on the Related Link > Create Clone Request.

- On the Clone Request form, specify the Clone Profile, Target Instance, and the Email IDs of users who should be notified upon completion.

- Click Submit to finalize the request.

 

Untitled-2025-08-15-181266.png

You will be able to see the clone request in active clones module.

 

 

5. Managing the clone : 

 

Please go through these links -

A. Cancel clone - https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...

B. Modifying clone schedules - https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...

C. Rollback a clone - https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...

D. View clone status - https://www.servicenow.com/docs/bundle/zurich-platform-administration/page/administer/managing-data/...

 

 

Hope this article helps you in setting up a clone profile and scheduling a clone.
If you have any questions related to cloning, please feel free to ask.

If you found this article helpful, please mark it as Helpful.

 

 

If this works, please mark it as helpful/accepted — it keeps me motivated and helps others find solutions.
Shashank Jain – Software Engineer | Turning issues into insights
0 REPLIES 0