We've updated the ServiceNow Community Code of Conduct, adding guidelines around AI usage, professionalism, and content violations. Read more

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

RohitJ432388693
Tera Contributor

3 weeks ago - last edited 3 weeks ago

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!

0 Helpfuls
  • 198 Views
1 REPLY 1

Itallo Brandão
Tera Guru

3 weeks ago

Hi @RohitJ432388693 ,

Your intuition is spot on. As a CMDB Business Analyst, you are advocating for the Gold Standard of release management.

Here is the technical breakdown to support your proposal against the pushback you are receiving.

1. Is a PROD-Refreshed Pre-Prod Best Practice?

Yes, absolutely. Especially for Service Mapping and Dynamic CI Groups.

  • Why: These features are heavily data-dependent. A Dynamic CI Group query (e.g., "All Windows Servers in Location X") relies on the existence of those specific CIs and their relationships.

  • The Risk: DEV and QA environments usually contain "dummy data" or stale CIs with different sys_ids than Production. If you test your Update Sets in QA, they might pass technically, but functionally fail in PROD because the underlying data (CIs) doesn't match the query logic or Entry Points.

  • The Solution: A recent clone ensures that the sys_ids of the infrastructure CIs in Pre-Prod are identical to PROD. This is the only way to guarantee a valid "Dry Run".

2. The "CSDM Plugin" Objection

This objection likely comes from a misunderstanding of how cloning works:

  • Cloning behavior: A full instance clone (PROD -> Pre-Prod) copies everything, including active plugins. If CSDM is active in PROD, it will be active in Pre-Prod immediately after the clone.

  • Activation effort: Even if, for some rare reason, you are not cloning and just using a fresh instance, the com.snc.cmdb.csdm.activation plugin is indeed low-impact and takes minutes to activate. It creates the standard tables/fields but does not delete data. It is not a valid technical blocker.

3. De-Risking Strategy (The "Data" Trap)

One crucial tip for your go-live: Service Mapping is a hybrid of Configuration (Update Sets) and Data (XML).

  • Update Sets: Capture the Service definition, Metadata, and Tag Categories.

  • Data (XML): Often, actual Entry Points, Tag Values, or specific CI Relationships are considered "Data" by ServiceNow and are not captured in Update Sets.

  • Recommendation: Your "Dry Run" in Pre-Prod is essential to identify exactly which parts strictly require XML migration (Export/Import) versus Update Sets. Without this dry run, you will likely discover missing Entry Points during the PROD window.

Recommended Community Resources

To help you build your business case and convince your technical team, here are some discussions and articles from the community that validate your strategy:

  1. Using a Cloning Plan to Ensure Successful Clones

    • Why read this: It explicitly states that failing to clone frequently leads to "configurations that test successfully in lower environments failing in production" due to data mismatches.

  2. Implementation of Discovery/CMDB over an existing environment

    • Why read this: Experienced architects discuss why a "Prod Clone" is the only safe place to evaluate CMDB impacts to avoid duplicates and reconciliation issues.

  3. Strengthening CSDM Data Foundations

    • Why read this: A recent guide (Jan 2025) on CSDM. It reinforces that CSDM is a standard framework and activating/aligning it is a standard maturity step, not a technical blocker.

Verdict: Push for the PROD-refreshed environment. It is the only way to catch sys_id mismatches and dependency failures before they impact the business.

If this analysis helps you justify the environment strategy to your team, please mark it as Accepted Solution.

Best regards,
Brandão.

0 Helpfuls