Upgrade Risk from Directly Modified PegaCS Rules
A telecom company runs Pega Customer Service 8.8 on Pega Platform 8.8. Over four years, the team customized the interaction portal by saving 380 PegaCS rules into the application ruleset TelcoCS-Work and editing them directly. Examples include the pyCustomerComposite section, the pyDefault data transform for Service cases, and the Work-.Add flow. The application ruleset stack is TelcoCS-Int version 01.01.01 built on PegaCS 8.8. There are 14 hotfixes applied to PegaCS rulesets. The upgrade to Pega Customer Service 23.1 is scheduled in six months. A proof-of-concept upgrade on a copy produced 67 rule-with-same-name-but-different-signature conflicts and 22 rules that no longer exist in the new version. The business cannot freeze enhancements for six months.
1. Assess the upgrade risk and classify the 380 customizations into remediation categories.
Read the worked answer
Treat all 380 overrides as high risk, but not equally. Directly edited PegaCS rules in TelcoCS-Work win rule resolution, so the 23.1 base rule is never used; if 23.1 changes a parameter, property, or inherited flow, the override can fail at runtime or silently skip a fix. The 67 signature conflicts are the immediate blockers; the 22 rules that no longer exist are dead overrides that should be deleted.
Classify: presentation and branding should move to skin or theme or extension sections; defaults and simple logic should move to data transforms, declarative expressions, or circumstancing; flow changes should use documented extension points or a new case type; true gaps should remain as a small, documented override set. Use Where Used, Application Compare between 8.8 and 23.1, and PegaUnit tests to prove each category. Do not start by rewriting all 380; the 67 conflicts and 22 missing rules are the first two weeks.
2. Design a remediation approach that lets enhancements continue during the six months.
Read the worked answer
Freeze only the specific rules being remediated, not the whole application. Create a separate ruleset or branch for new enhancements so delivery continues, and put a rule-level checklist on the 380 overrides. For each override, decide in this order: remove it if 23.1 already provides the behavior; circumstancing if the change is conditional; extension point if Pega CS exposes one; keep as an override only if none apply.
For the composite, prefer dynamic layout visibility and When rules over editing the OOTB section. For pyDefault, put additive logic in an application data transform that runs after the base, where the framework exposes a post-processing point; otherwise keep the override and add a PegaUnit test that asserts both base and custom properties. Run the upgrade proof-of-concept after each batch, not at the end, and track conflict count as the release metric. This lets enhancements continue while reducing the final override surface.
3. What should be done about the 14 hotfixes?
Read the worked answer
Hotfixes are the hidden risk. The 14 hotfixes may change PegaCS rules that your overrides also replace; in that case the hotfix is masked in production today, and the upgrade may expose a behavior change. Use Hotfix Manager and Where Used to list the rules touched by each hotfix, intersect that list with the 380 overrides, and prioritize those overlaps. If a hotfix already fixes the issue, delete the override. If the override is still needed, retest it against 23.1 with the hotfix included.
Do not carry hotfixes forward blindly either; confirm which are included in 23.1. Record the result in the remediation backlog so the upgrade team can see masked fixes. This is also a good time to add a regression suite around the top 20 overrides by business criticality.