Question
Wipro
CA
Last activity: 3 Oct 2025 18:04 EDT
Can the Ruleset Maintenance wizard be used in Prod environment?
Background
In a multi team dev environment, we are stuck in a situation where we have run out of ruleset patch version. We are thinking of copy and then delete the following RSV into a higher RSV and then delete it from lower RSV. this will make room for preceding RSV to grow. For example;
T1 Enhancement: 02-10-01 to 02-10-50
T2 Enhancement: 02-10-51 to 02-10-99
Both the enhancements are in Prod but T2 Enhancement is toggled off. Now T1 Enhancement needs more RSVs but there is no room. Our plan is to copy T2 Enhancement from 02-10-51 - 02-10-99 to 02-11-01 - 02-11-49 and delete 02-10-51 to 02-10-99 giving T1 Enhancement more RSVs. This will be initially done in lower environments. Since T1 Enhancement is already in Prod, the wizard will also be used in Prod environment.
Question
In situation like these, is there any option other than using the Ruleset Maintenance wizard to copy the ruleset in higher versions in Prod or there is any other way? Does Pega recommend to use the Ruleset Maintenance wizard in Prod environment?
Any help and response will be greatly appreciated. Thanks in advance.
HCA Healthcare
US
@NadeemM8116
don’t use Ruleset Maintenance wizard in Prod unless there’s no other choice. The clean, Pega-recommended path is to avoid “making room” in a patch range and instead move to a new minor version for T1 (e.g., 02-11-01+) and continue patches there. If T2 is feature-toggled off, keep it as-is or move it to its own ruleset/minor via a skim in lower envs, then deploy through a standard Product/Deployment Manager pipeline—don’t delete already-released patch versions in Prod because you’ll lose rollback history and risk rules resolution surprises. Major/minor skim + new minor versioning is the supported way to consolidate and reset patch counters. If you absolutely must copy rules in Prod, do it during a maintenance window with backups, locked versions, and change control, and validate the application stack after. But best practice: create a new minor for T1, refactor T2 if needed, and leave old patch versions untouched.