Our application is currently running on Pega 24.1.3 in an OpenShift + Oracle on-prem environment. We are planning to upgrade to 26.1.1 using the zero-downtime upgrade approach, where the cluster remains available during the upgrade process except for the small window of new image deployment.
As part of the upgrade, the process will update the new rule schema and the temporary data schema. Once the upgrade is completed, we will switch to the new rule schema and deploy the 26.1.1 application image.
We would like to confirm the recommended rollback strategy. If needed, is it sufficient to point back to the old rule schema and deploy the 24.1.3 image? Would this be a viable and recommended approach, especially since the business does not want to lose any transaction data created in the data schema?
Since we intend to continue using the old data schema, could someone please confirm whether this rollback approach is supported?
Great question! ZDT rollback is something worth planning carefully. Based on Pega’s design, rollback/switching back is generally safe, as ZDT maintains bidirectional compatibility during the upgrade window.
Recommended approach before full rollout:
Rather than going straight to full production rollback if issues emerge, I’d suggest this validation pattern:
Smoke test on isolated node: Spin up a single node on the new version (26.x) outside your load balancer. Run your critical business scenarios against it (case creation, decision flows, API calls, integrations). This lets you catch environment-specific issues without risking the cluster (assuming that you have done proper regression testing in lower environments already).
If issues found: You can safely roll that node back to 24.1.3 without cluster impact, then investigate before proceeding.
If smoke test passes: Proceed with staged rollout (one node at a time in your LB).
Key things to validate during smoke test:
Custom rules and plugins load correctly
Database connectivity and queries execute
Any external system integrations work as expected
Log levels and monitoring are reporting normally
This staged approach gives you confidence without putting the full cluster at risk.
Thanks for the response and insight. I’m clear on the rollout/rollback strategy, and I was looking for confirmation on the recommended rollback approach if the ZDT upgrade does not go as planned. Since our business goal is to preserve transaction data created/updated during the upgrade, can we treat switching back to the old 24.1.3 rule schema and redeploying the 24.1.3 image as a viable backup rollback plan?
In practice though I would still prefer to test this approach beforehands. There are many moving parts in pega and especially with on-prem deployments where you are responsible for so many different components, configs and connections to work seamlessly together - I wouldn’t leave it for chance.