CMDB Go-Live Risk Mitigation: Using a PROD-Refreshed Pre-Prod for Update Set Dry Runs

[RohitJ432388693]

Hi everyone,

I’m working as a CMDB Business Analyst on a CMDB go-live with multiple environments (DEV → QA → PROD).

Developers build in DEV, migrate to QA for UAT, and then we’re preparing for PROD. Some of the work includes Service Mapping and Dynamic CI Groups, which we know can be sensitive when captured via update sets.

Based on past go-lives, I’ve seen scenarios where update sets technically migrate but still result in:

1. broken functionality
2. missing dependencies
3. rework required directly in PROD

To reduce risk, I proposed setting up a pre-prod environment refreshed from PROD on a regular basis, where all update sets could be migrated as a dry run before the actual PROD deployment.

One concern raised was that CSDM is not installed on the pre-prod instance. However, in my experience (and testing in a PDI), enabling the CSDM activation plugin (com.snc.cmdb.csdm.activation) is quick and low-impact.

My questions to the community:

1. Is a PROD-refreshed pre-prod environment considered a best practice for CMDB go-lives involving Service Mapping and Dynamic CI Group?
2. Are there any legitimate technical reasons why lack of CSDM activation should block such an approach?
3. How do others de-risk update set migrations for CMDB changes before PROD?

Appreciate any guidance or real-world experience.

Thanks!