Please note that the below is a high level plan on how to plan for the on-premise/self-hosted cloning of production to the lower environment. Please work with your ServiceNow support team for the detailed steps.
I have been working with a customer and involved in the setup of the self hosted environment,.
Unlike ServiceNow SaaS, where cloning is handled smoothly by ServiceNow’s cloning procedures automation, in self-hosted environments the responsibility falls squarely on the customer’s platform and database teams. It is always seen as an lot of operational overhead and needs lot of planning in advance..
In this blog, I’ll walk you through a structured cloning procedure, my own hard-learned lessons. The flow below is based on a standard three-tier setup (Production, Test, and Dev) with MariaDB as the underlying database.
Step 1 – Prepare the Source (Production)
- Backup the Production Database: The cloning process always begins with a fresh backup of the production database. This backup serves as the “golden copy” that will be restored into Test or Dev.
- Validate Backup Integrity: A corrupted backup is worse than no backup. Always run a quick integrity check before proceeding. We have seen multiple times where the backup file has been corrupted when restoring to the lower instances. One of the few quick checks is doing the CHKSUM of the files on the source and the target servers.
- Connectivity: We also have to ensure that the FTP connectivity exists between the production and the lower environment. As the file size is very high, you may observe the issues in copying the huge files.
Responsibility: Database Team
Step 2 – Safeguard the Target Environment (Test/Dev)
- Backup Target Database: Take a backup of the Test or Dev instance before you overwrite it. This gives you a rollback option if something goes wrong.
- Shutdown App Nodes: Stop all application nodes connected to the target environment to avoid conflicts during the restore.
- Shutdown Target Database: Bring the Test/Dev database offline gradually before beginning the restore.
- Backup the following tables:
- Certificates
- Service/Integration/MID Server accounts from the user table.
- System properties
- REST Messages and methods
- MID Servers
- Sys_http_connections
- Sys_oauth_credential and sys_oauth_application
- Scheduled Jobs
- Email Accounts
Responsibility: Platform Team + Database Team
Step 3 – Restore from Production
- Restore the Prod Backup into Test/Dev: Using MariaDB commands (I am not highlighting the commands as the different customers may use the MariaDB tools as well to restore the database), restore the production backup into the Test or Dev environment. Ensure that the database schema, collation, and instance/DB version match to avoid restore errors.
- Restore the backed up tables in Step 2
- Restart the Target Database: Once restored, start up the Test/Dev database and perform quick sanity checks (table counts, log validation).
Responsibility: Database Team
Step 4 – Bring the Environment Online
- Re-start the Application Nodes: With the Test/Dev database refreshed, bring the application nodes back online.
- Application-Level Validations: Check logs for any startup issues, verify connectivity, and run smoke tests.
Responsibility: Platform Team
Step 5 – Cleanse Sensitive Data
- Mask Sensitive Production Data: This is where many teams fall short. Cloning brings in everything from Prod—including sensitive information (employee details, financial records, PII).
- Implement scripts/routines to anonymize or clean this data post-clone. For example:
- Delete the HRSD application data.
- Delete the VIP tickets data.
Responsibility: Joint (DB + Platform Team)
Step 6 – Sanity Checks and Reconfigurations
- Validate Core Services: Run sanity checks on critical ITSM, HRSD, or other modules to ensure they’re functional.
- Reconfigure Integrations: Disable or redirect integrations that should not point to Production endpoints (e.g., HR systems, ERP, or external APIs).
- Verify Email/Notification Settings: Make sure cloned environments do not send “real” emails to end users. Always point them to a test SMTP relay.
Responsibility: Platform Team
