Clone (legacy UI) - Product Documentation: Zurich

Clone (legacy UI)

Exploring Instance Clone Exploring Instance Clone

Explore how to use the Instance Clone application to copy everything in a database from one instance to another.

Clone terminology Table 1. Clone terms Field Description Source Instance The original database where data is copied from. Target Instance The new location where the data is copied to. Data Preservers Specified data from the target instance that is retained on the target instance during the clone. Preservers are defined on the source instance. Table Exclusions Data that is not cloned to your target instance. Cleanup Scripts Automated steps that run after cloning, such as changing data or settings. Clone Profiles Reusable template for clone settings, exclusions, preservers, and scripts. Clone Admin Console The Clone Admin Console is the default user interface that enables you to manage and track the cloning process. On-Demand Backup With on-demand backup enabled, clone takes a fresh on-demand differential backup at the specified clone start time. Clone uses this backup during the restore phase of the clone. Clone Chaining You can divide your clone operation into two steps. Cloning from production to your test (non-production) environment. Cloning from 'test' to all your other environments. You can save time if you're dealing with multiple instances and experience long clone durations. Using this strategy, you perform lengthy operations such as post-clone cleanup scripts or excluding Task data older than 90 days only once. The clones in step 2 have a lighter footprint and complete faster.

Instance Clone workflow Figure 1. Instance Clone workflow diagram

Clone build configuration: The clone prepares the basic definitions, configurations, and profile options. The clone checks what to include, exclude, or preserve.

Preflight checks: The clone checks the source and target instances to ensure that they are in a healthy state before proceeding with the clone. Backup: Uses the latest daily backup. If there were major recent changes, a new backup is created. Users can also trigger a new backup manually by selecting the On-demand backup via the Clone Admin Console.

Pre Clone: Prepares space for the new database before restoring it.

Provision database interface (DBI): A new target instance is set up to receive the restored data.

Restore: The backup data is restored to the new target instance.

Exclusions: Tables marked for exclusion are deleted.

Preservers: Data is preserved from the old target (pre-clone instance) and is copied to the new target instance.

Node repoint: The system switches from the old target to the new clone without user disruption. Scheduling scripts: Cleanup scripts and custom scripts are scheduled to run. Note: Scripts with the same priority may run at the same time. Post Clone: Cleanup scripts run. Note: Verify that custom scripts have proper error handling to avoid issues. Without proper error handling, failing customized scripts can help prevent subsequent scripts from executing.

Clone Admin Console

The Clone Admin Console is the user interface where administrators can manage, request, and monitor their instance clones. The Clone Admin Console makes it easier to track clones between instances.

Clone Admin Console benefits All your exclusions, preservers, and scripts can be found under Definitions. Your existing settings like profiles and registered instances can be found under Configurations. The Clone Admin Console provides guidance on the clone request page, an on-demand backup option, and enables more visibility into clone progress. You can also duplicate clone profiles.

Cloning Clone copies data and metadata from one ServiceNow instance (source instance) to another ServiceNow instance (target instance). Cloning is useful to copy the data and metadata from a production instance to a non-production instance to test changes. Clone data comes from the most recent daily backup. To learn more about cloning, see Clone (legacy UI) .

Notes regarding the Clone Admin Console Legacy clones and clones requested in the Clone Admin Console are stored separately. Clone Admin Console requests are stored on a new table and are only displayed within the new console. Legacy clones requested on the legacy Request Clone page are stored in the legacy Clone History table. Legacy clones don't display in the console. Since they’re stored separately, request numbers in the console and legacy systems might overlap. Your existing clone instances, clone profiles, exclusions, preservers, and cleanup scripts are available within both the Clone Admin Console and the original lists and forms. To place a request using the Clone Admin Console, you need:

The clone_admin role on the source instance.

The clone_admin and the soap role on the target instance.

Clone Admin Console uses the same clone engine as the legacy clone. The clone behavior is the same with a better interface.

Overview of the Clone Admin Console

Home Note: The clone home page displays clones requested through the Clone Admin Console . You can't view clones requested through the legacy request page (clone_instance.do) in the dashboard. Clones are displayed in either a grid or list view.

The home page displays the current clones in your instance. Use the search bar to locate your clone.

Filter options are available to identify the clones you want to view with the filter drop-down button. You can apply the following conditions to display on the dashboard: Canceled Completed Error Requested Rollback failure Rollback requested Rolled back Rolling back Running

Configurations The Overview tab displays the current number of Clone instances and Clone profiles in your instance.

On the Clone instances tab, you can view all currently available clone instances. You can use instances added to this list as a clone source or clone target for your clones. To add your non-production instance to your clone instances list, select New .

The Clone profiles tab displays all of your available Clone profiles . Clone profiles are customizable templates for clones and can be saved and reused to achieve consistent outcomes with each of your clones. To learn more about Clone Profiles see Clone profiles for clone requests .

Note: The profile System Profile is available out-of-the-box and can't be modified. Custom profiles use the default Exclusions, Preservers, and Scripts from the System Profile .

Note: When creating a custom profile, all existing custom exclusions and preservers are automatically added.

You can create as many custom clone profiles as you'd like and edit them as needed. To change the definitions of a clone profile, such as exclusions, preservers or cleanup scripts, select the number under the definition and select the Edit button on the page. Note: Some out-of-the-box system items can't be removed from the exclusions, preservers, or scripts list.

You can add external email addresses to receive clone notifications.

Request clone The app features a clone request page, with guidance and explanations for how the various clone settings affect your clone. The new request page also features a new scheduling calendar to help to prevent timing conflicts with ServiceNow maintenance windows.

To learn more about how to request a clone see Request a clone .

Clone (legacy UI)

Clone to an instance on a different version, from a backup, or over a production instance with instance clone.

Clone to an instance on a different version

Clone to an instance on a different version You can clone between instances that are on different family release versions. During a clone, the source version will replace the target version. Example: If you clone from Source (Zurich) to Target (Yokohama) the target will match the source after the clone and be on Zurich release.

.

Clone from a backup The clone uses data from the most recent, daily backup of the source instance when cloning. Backups that are used for cloning are a maximum of 36 hours old. Instance clone begins the initial preparation, including selecting the latest backup to use, only at the date and time processing is scheduled to start.

If the source and target instances are on different versions of the ServiceNow AI Platform , the target instance is modified to match the source instance version during this time.

When starting a clone from a backup, the date and time the backup was taken, as well as periodic progress messages, appear in the Clone Log related list.

Figure 2. Instance clone backup log

Clone over production instances As long as the system property glide.db.clone.allow_clone_target is TRUE, an instance can serve as a clone.

Deprecated Clone Options The clone option check box Preserve users and related tables has been removed from Clone Options in the Utah release. In some cases, past customizations to the clone request page or related to clone, may cause this field to remain on your form. Important: Checking this deprecated field doesn't effect the user, role, or related tables during your clone. .

Clone exclusions preservers and cleanup scripts

You can use clone definitions such as exclusions, preservers, and cleanup scripts in your clone.

Definitions The Definitions page displays an overview for Exclusions Preservers Cleanup Scripts .

The Exclusions tab lists the tables that aren’t copied during an instance clone. When excluding a table, the clone automation truncates the entire table including its child tables. The clone process excludes (or removes) data from both the parent and the child tables. The child tables, however, aren't individually added to the list of excluded tables. Only the parent table is listed. By default, the system excludes tables for logging, auditing, notifications, workflow contexts, and license usage. Select New to configure additional Exclusions .

The Preservers tab displays a list of available data preservers that protect data on the target instance from being overwritten.

Preservers work differently compared to exclusions. When preserving a table, the clone automation doesn’t automatically preserve the child tables. Therefore, the child tables must be individually added to the preserver list. Preservers are defined on the source instance. To create a preserver see Create a new clone preserver .

To view child tables of a table, you can go to the following link and input their table: [instance].service-now.com/now/nav/ui/classic/params/target/generic_hierarchy_erd.do .

During a clone, data from the source instances replaces data from the target instance. Therefore, any in-progress development work on the target instance is overwritten. For example: work-in-progress update sets, scoped apps that only exist on the target instance but not on the source instance. If you have in-progress update sets, you must export them before the clone and reimport them after the clone is finished. Custom applications that aren't yet deployed to the source instance must be re-installed after the clone is completed. To learn more about clone and app development tips, see Whitepaper here .

The Cleanup scripts tab displays a list of all of your available scripts. You can write cleanup scripts to automate post-clone steps. To create a cleanup script see Create cleanup scripts .

Clarifying exclusions and preservers combinations Clone exclusions and preservers are both useful for managing your data. The graphics help to identify the expected outcome of the following combinations of preservers and exclusion combinations. For more information, see https://www.servicenow.com/community/servicenow-ai-platform-blog/platform-fundamentals-academy-february-20th-2025-clone-admin/ba-p/3170929

Scenario 1: Preserving and excluding a table. You want the records on your target instance to remain the same. Scenario 2: Preserving and not excluding a table. You want records on your target Instance to remain the same and records for your source instance to be copied over. Scenario 3: Not preserving and excluding a table. You want records from your source instance not to be copied over and records on your target instance to be removed: The table is empty but usable after the clone. Scenario 4: Not preserving and not excluding a table. You want records from your source instance to replace records on your target instance.