Using a Cloning Plan to Ensure Successful Clones in ServiceNow

[Rob Greeley]

Cloning a ServiceNow production environment to replicate its state across lower environments is a critical operation that ensures your testing, development, and training environments are as close to production as possible. This process, when managed thoughtfully, can significantly improve testing accuracy, application performance, and overall ServiceNow platform integrity.

All platform owners, however, will eventually run into problems caused by cloning. If you do not clone frequently enough, configurations that test successfully in lower environments will fail in production.  Improper clones can lead to issues such as developers losing access or work in progress, mismatches between environments, or exposure of sensitive data in the development environment. Creating and following a cloning plan can help ensure successful clones and avoid common pitfalls.

Step 1:  Have a Plan

There is not a formal template or structure for a cloning plan, but there are some components I would strongly recommend including:

Clone Frequency and Scope:

Define the frequency of clones and the types of clones required. For example:

• Monthly  full clones to the test environment (including full data)
• Quarterly partial clones to the development environment (limited data)
• Full clones to development prior to upgrade testing.

The defined frequency allows your developers and admins to get used to the schedule and plan ahead.

For each type of clone, document the scope:

1. Data only vs. full clone: Decide if you need just the data (e.g., incident and change records) or full configuration and application data.
2. Applications and modules: Consider whether to exclude specific applications or data sets that do not need to be in the target lower environment.

Which data to avoid copying: To maintain security and comply with data protection regulations, the clone scope should specify data exclusions for any sensitive data. Examples include tables that include personally identifiable information (PII), financial data, or company confidential information.

Timing

Schedule clones for periods of low activity. Avoid working hours or peak times to minimize performance issues for users and minimize developer downtime. Establishing a standard cloning schedule avoids the need to determine appropriate times for each clone and allows developers to adapt to a consistent timeline.

Communications Plan

Ensure that team members and stakeholders are informed about each clone so they can prepare.

1. Developers: They may need to back up any work in progress.
2. QA and testing teams: They will need to halt testing and document any work that needs redoing post-clone.
3. System administrators: They will need to prepare for potential system downtime.

The communications plan should document:

• Who is sending out the communications,
• When the communications are being sent out, and to whom,
• Include email templates to save time and prevent the admin team from drafting each communication from scratch.

Pre-Clone Checklist

A documented pre-clone checklist enables administrators to share tasks while ensuring a consistent process. Your pre-clone checklist may include the following items:

1. Back up lower environments: Make a backup of the current state of your lower environment in case something goes wrong during the cloning process.
2. Disable scheduled jobs and integrations: Turn off any integrations or scheduled jobs in the lower environment to avoid unintended data processing or API calls during the clone.
3. Extract a backup of any remaining in-progress update sets.
4. Verify that a backup of production has taken place since the last deployment to production. Use a scheduled backup if needed.

Clone Configurations

Document each step of your cloning process, including settings, customized exclusions, data preservers, or cleanup scripts. This documentation allows admins to understand how the clone should be working and is the basis for any improvements that need to be made.

Specify which clone profile to use for each type of planned clone.

Post Clone Checklist

Similar to the pre-clone checklist, the post-clone checklist will be organization-specific; however, common items may include:

1. Conduct post-clone validation to verify that key data has been cloned as expected.
   • Data integrity: Confirm that important records (like Incidents, Problems, and Change Requests) have populated correctly and align with production.
   • Sensitive Data:  Confirm that excluded sensitive data has not been inadvertently copied.
   • Configurations and scripts: Check that customizations, scripts, and configurations needed for testing are intact.
   • System properties and integrations: Ensure system properties are appropriate for lower environments, especially if they differ from production. Re-enable integrations and scheduled jobs as needed.
2. If required, disable email notifications on the target environment.
3. Restore Notifications and Scheduled Jobs
4. Restore developer roles.
5. Perform a Final Functional Test.

Once post-clone actions are stable, automate those steps that can be automated using cleanup scripts

Step 2:  Improve the Plan

Update the plan as circumstances change. Periodically review it, especially after any clone-related issue, to identify necessary improvements.

• Are there steps that need to be added to prevent future errors?
• Are there instructions or steps which need to be clarified?
• Are process steps that are no longer relevant?
• Can you develop more detailed checklists for the post-clone validation?

Post-clone reviews and updates to the cloning plan support continuous improvement in this critical operational process.