What cloning does not include — important gaps

A standard ServiceNow clone copies almost everything, but several things are excluded or require attention post-clone. Email notifications are typically disabled on clones by default — the clone configuration prevents the sub-production instance from sending emails to real users during testing. Scheduled Jobs may be disabled post-clone to prevent duplicate processing. MID Server credentials need to be reconfigured if the sub-production instance uses different MID Servers than production. Integration credentials stored in Connection and Credential Aliases may need to be updated to point to test endpoints rather than production external systems — cloning a credential that authenticates to your production HR system and then testing integrations against it is a real risk if not addressed.

Clone requests and scheduling

Navigate to System Clone > Request Clone to initiate a clone request. Specify the source instance (production) and the target instance (your sub-production). The clone runs during a ServiceNow-managed maintenance window — typically overnight. Plan clone requests 24-48 hours before you need the refreshed instance. Large instances (many records, large attachments) take longer to clone — check with your ServiceNow account team on expected clone duration for your instance size. During the clone window, the target instance is unavailable. Schedule clone requests to avoid interfering with testing cycles or go-live dates.

Related: Update Sets · Instance Scan · MID Server · Pre-upgrade testing

Planning the Clone: What to Preserve and What to Exclude

A successful clone starts with deliberate decisions about data exclusion. The default clone copies all application data, which in a production instance can mean hundreds of gigabytes of historical records that are irrelevant for development or testing purposes. ServiceNow's Clone Excludes feature lets you specify tables whose data should not be copied — standard candidates include syslog, syslog_transaction, audit tables, email records, and integration staging tables. Define your exclusion list before the first clone and store it in a Clone Profile so it is applied consistently. A clone without a well-considered exclusion list often takes 4-6 hours longer than necessary and leaves the target instance full of noise that makes test data management difficult. The Update Sets guide covers what configuration artifacts are preserved independently of the clone.

Preserving Target Instance Data

Clone data preservers address the most operationally painful aspect of cloning: target instance data that you need to keep. Integration credentials, test user accounts, and environment-specific system properties are the primary candidates for preservation. Without preservers, every clone requires manually reconfiguring credentials and properties in the target instance — a process that is easy to forget and often causes integration failures that take hours to diagnose. The standard preservers to configure before your first clone are: sys_properties records for environment URLs and feature flags, sys_user records for test accounts, and credential records in discovery_credentials and oauth_entity. The Credential Aliases guide covers the credential model that preservers need to target.

The Clone Request and Monitoring Process

Clones are initiated through System Clone → Request Clone in the source instance. The request specifies the target instance, the data excludes profile, and the preservers list. Once submitted, the clone enters a queue managed by Anthropic — it does not start immediately and cannot be cancelled after the target instance begins being overwritten. Monitoring is through the Clone Request record, which updates its status through stages: Queued, Cleaning Target, Copying Data, Running Scripts, and Complete. For large instances, the Copying Data stage is the longest. Plan clones for weekends or off-hours, as the target instance is unavailable for the entire duration and a failed clone mid-process can leave the target in an inconsistent state requiring a support ticket to resolve.

Post-Clone Configuration Steps

Even with well-configured preservers, post-clone steps are always required. Email configuration needs to be set to "off" or redirected to a test mailbox — otherwise test instances send real emails to real users if triggered by workflow testing. Outbound integrations need credential verification; even if credentials were preserved, endpoint URLs often differ between environments. Scheduled Jobs should be reviewed and paused in non-production environments to prevent automated processes from running against real external systems. For instances integrated with Active Directory or LDAP, the LDAP connection needs to be pointed at a test directory or disabled. Document these post-clone steps as a checklist and assign them to specific people — they are easy to forget in the relief of a successful clone completing.

Clone Cleanup Scripts

ServiceNow allows you to define Clone Cleanup Scripts that run automatically on the target instance after the clone completes. These scripts execute in the target instance context and are ideal for automating the post-clone configuration steps described above. A well-maintained cleanup script can set email mode to disabled, update environment-specific properties, pause scheduled jobs by category, and send a Slack or email notification confirming the clone completed with a summary of what was configured. Investing in thorough cleanup scripts pays dividends across every future clone. Store cleanup scripts in a dedicated scoped application so they are version-controlled and deployable independently of application code.

Clone Impact on Integrations

A clone always disrupts integrations in the target environment unless explicitly managed. Outbound integrations in the cloned instance will attempt to call the same external endpoints as production — which may be real external systems, not test environments. Inbound integrations that external systems call will stop working if the target instance URL changed or if inbound credentials were overwritten by the clone. The clone checklist should include: (1) disable all outbound integrations immediately after clone completes; (2) reconfigure endpoint URLs to point to test external systems; (3) verify inbound credential preservers worked correctly; (4) send test messages through each integration before declaring the environment ready. Skipping any of these steps risks sending production-like traffic to real external systems or missing the window to catch broken integrations before business users start testing.

Clone Scheduling and Communication

A clone is disruptive to anyone using the target environment during the process. Establish a regular clone schedule that development and testing teams can plan around — monthly is common for large organisations, quarterly for those with stable production environments. Communicate clone dates at least two weeks in advance through whatever channels your team monitors (email, Slack, Jira tickets). Include in the communication: when the clone window starts, estimated duration, what will be preserved (credentials, test user accounts), and what teams need to do post-clone (repoint integrations, verify their test scenarios still work). A standard post-clone communication confirming completion with a checklist of what was verified reduces the support burden after the clone. Assign one person as the clone coordinator responsible for initiating the request, monitoring progress, completing the post-clone checklist, and sending the completion notification.