Is it a good practise to exclude the tables for cloning
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tuesday
We are cloning prod to QA for upgrading to Zurich version.
Is it a good practice to exclude the below tables for cloning?
sys_properties,
sys_alias (Connection + Connection Alias),
discovery_credentials
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Tuesday
Hi my Friend
Its good practice to exclude those tables when cloning Production to QA for a Zurich upgrade.
The table sys_properties holds instance level settings such as integration URLs, MID Server names, and feature flags. If it is there, QA will inherit the production endpoints which can lead to emails and API calls being sent from QA into the real production systems after the Zurich upgrade.
The tables sys_alias / connection alias contain connection and Integration Hub routing definitions. I have seen cloning them make QA use the production connection records instead of QA versions which breaks environment isolation needed for the Zurich upgrade testing.
The discovery_credentials table stores passwords and keys. Copying it into QA releases sensitive information to a wider audience and risks QA Discovery authenticating against production infrastructure during Zurich validation.
For those reasons, excluding sys_properties, sys_alias connections, and discovery_credentials is more aligned with ServiceNow security and cloning best practice for upgrade. QA should maintain its own non-production integrations and credentials while you test the Zurich release upgrade safely.
@AnuragK71448466 - Please mark Accepted Solution and Thumbs Up if you found Helpful!!
