System Cloning

[potter0100]

What is system cloning? 

[nityabans27]

Hi @potter0100 ,

🔍 What Is System Cloning?

System cloning in ServiceNow is the process of copying all data and configuration from one ServiceNow instance (the source) to another (the target).
It’s typically used to refresh sub-production instances (like dev, test, or UAT) with production data for realistic testing or troubleshooting.

---

⚙️ What Actually Gets Cloned

By default, everything in the database from the source is copied over to the target — including:

• Application files

• System properties

• Configuration tables

• Customizations

• User data and transactions (incidents, changes, etc.)

Essentially, the target becomes a bit-for-bit replica of the source.

---

🧩 What Doesn’t Get Cloned (Automatically)

Certain items are excluded or can be excluded manually:

• Instance-specific data like:

  • MID Server configurations

  • LDAP / SSO settings

  • Email configurations

  • Integration credentials

  • IP filters, ACL whitelist, etc.

• Clone-excluded tables (defined in clone_exclude_list)

👉 You can also add or remove exclusions under System Clone > Clone Definition > Exclude Tables.

---

🔑 Roles Required

You need:

• clone_admin role (to schedule or manage clone)

• admin or security_admin for post-clone tasks

---

🧠 Pre-Clone Steps (Before You Clone)

1. Review Integrations

   • Disable or exclude integration configurations (MID, LDAP, email).

2. Update Exclusion List

   • Add tables that should not be cloned (e.g., sys_user, sys_email, ecc_queue).

3. Backup Important Data

   • If target has sandbox data you want to keep, export it — clone will overwrite it.

4. Notify Users

   • Because target will be unavailable during clone.

---

🚀 Clone Execution (The Actual Process)

1. Navigate to:
   System Clone > Request Clone

2. Select:

   • Source instance (e.g., production)

   • Target instance (the current one)

3. Optionally define:

   • Exclusion rules

   • Clone schedule (immediate or scheduled)

4. Submit the clone request — ServiceNow Cloud Ops handles it automatically.

5. Clone progress can be tracked under System Clone > Clone History.

---

🧹 Post-Clone Steps (Critical Cleanup)

After the clone is complete:

🔐 1. Reconfigure Instance-Specific Settings

• Re-enable integrations, connections, and SSO (repoint URLs).

• Update MID Server, Email, OAuth, and REST credentials.

⚙️ 2. Reset Properties

• Update glide.url.home (point to correct instance)

• Reset any system properties changed during clone.

📡 3. Verify Connectivity

• Test outbound REST/SOAP integrations, notifications, and email sending.

👥 4. Restore Developer Accounts

• Clone overwrites users; re-import developer users or test accounts.

🧾 5. Run Post-Clone Scripts (optional)

• You can define Clone Post-Processing scripts under System Clone > Clone Definition > Post Clone Scripts to automate cleanup.

---

📄 Example Post-Clone Script

(function() {
    gs.info("Running post-clone cleanup script...");

    // Disable email sending
    gs.setProperty('glide.email.read.active', false);
    gs.setProperty('glide.email.smtp.active', false);
    
    // Reset system property to target instance URL
    gs.setProperty('glide.servlet.uri', 'https://dev12345.service-now.com/');
    
    gs.info("Post-clone script completed successfully.");
})();

---

🧭 Real-World Best Practices

Goal Recommendation

Protect prod credentials	Exclude sys_user and sys_user_has_role
Maintain integrations	Exclude sys_properties and reapply manually
Clean data faster	Use clone targets with sanitization rules
Automate setup	Use post-clone scripts to re-enable or disable features
Stay compliant	Scrub PII or sensitive data using Data Anonymization

---

🧰 Key Modules

• System Clone > Request Clone

• System Clone > Clone History

• System Clone > Exclude Tables

• System Clone > Post Clone Scripts

[aruncr0122]

Hi @potter0100 ,

System cloning in ServiceNow means creating an exact copy of one instance (like production) into another (like development, test, or UAT).

In the context of an upgrade, cloning is often done before or after upgrading to:

Before upgrade – clone production → sub-prod instance to test the upgrade with real data and find issues early.
After upgrade – clone production → sub-prod again to refresh lower environments so they match the upgraded production setup.

In short, cloning helps ensure all environments are aligned and that upgrades can be tested safely without affecting live data.

[dgarad]

Hi @potter0100 

please refer below link.

https://www.servicenow.com/community/developer-articles/system-clone-explained/ta-p/2305561