Pega Upgrade from 7.1.9 to Infinity 24.1
Hello Everyone,
We're planning a major out-of-place upgrade from 7.1.9 to 24.1.
Infra -- Azure Cloud (client-managed), Linux Red Hat (OS), Java 17, MSSQL Server 2022
There's no FW in the application.
I have some questions about the approach and best practices, and I'd like expert advice.
1) For the lower environments (Dev, QA, UAT) upgrade, is the recommendation to use Rules schema from Stage (because it's a stable code base) and use Data schema from the respective environments? Or both schemas should be from same lower env only?
2) Skimming should be done before executing the upgrade script on Rules schema?
3) Can we skip executing "migrate.sh" script if we restore DB schemas to a new server and directly run upgrade script? Will it make any difference?
4) When should we execute this script during upgrade process?
-
generateddl.sh script generates a DDL file of schema changes.
5) Does cleanup.sh script removes unused rules or DB tables or both? What's the criteria to flag a rules as old or unused?
cleanup.sh script generates a DML file from which you can subsequently remove old or unused rules after you complete your update
Accepted Solution
Updated: 6 May 2025 16:00 EDT
HCA Healthcare
US
Since you're now moving forward with an in-place upgrade, here's how things change. Yes, you can copy both Rules and Data schemas to a new DB server and run the upgrade.sh script there; in this case, you can skip migrate.sh because schema movement is already handled manually. Running generateddl.sh is not mandatory but highly recommended it lets DBAs review and apply schema changes manually, giving you more control and ensuring nothing breaks due to permissions or structure mismatches; however, if skipped, upgrade.sh will apply schema changes internally, just without your review. Regarding extra DB tables created during upgrade: they are not removed automatically. You’ll need to use cleanup.sh post-upgrade, which generates a DML file identifying old/unused rules review it carefully before executing. It doesn’t remove unused tables directly, so manual cleanup may be needed for truly obsolete custom tables.
Here’s a basic in-place upgrade checklist:
-
Backup Rules and Data schemas.
-
Skim rules before upgrade (if needed).
-
Copy schemas to new DB server (if infrastructure is changing).
-
Run
generateddl.sh(optional but recommended). -
Run
upgrade.shon the target schemas. -
Validate upgrade with logs and Pega UI.
-
Run
cleanup.shpost-upgrade to generate cleanup DML.
Since you're now moving forward with an in-place upgrade, here's how things change. Yes, you can copy both Rules and Data schemas to a new DB server and run the upgrade.sh script there; in this case, you can skip migrate.sh because schema movement is already handled manually. Running generateddl.sh is not mandatory but highly recommended it lets DBAs review and apply schema changes manually, giving you more control and ensuring nothing breaks due to permissions or structure mismatches; however, if skipped, upgrade.sh will apply schema changes internally, just without your review. Regarding extra DB tables created during upgrade: they are not removed automatically. You’ll need to use cleanup.sh post-upgrade, which generates a DML file identifying old/unused rules review it carefully before executing. It doesn’t remove unused tables directly, so manual cleanup may be needed for truly obsolete custom tables.
Here’s a basic in-place upgrade checklist:
-
Backup Rules and Data schemas.
-
Skim rules before upgrade (if needed).
-
Copy schemas to new DB server (if infrastructure is changing).
-
Run
generateddl.sh(optional but recommended). -
Run
upgrade.shon the target schemas. -
Validate upgrade with logs and Pega UI.
-
Run
cleanup.shpost-upgrade to generate cleanup DML. -
Test thoroughly in Dev/QA before moving to higher environments.
HCA Healthcare
US
For an out-of-place upgrade from Pega 7.1.9 to Infinity 24.1 on Azure, it's best to use the Rules schema from a stable environment like Stage and pair it with the Data schema from each lower environment (Dev, QA, UAT) to retain their environment-specific data. Skimming should be done before running the upgrade script to reduce rule count and improve performance. You can skip the migrate.sh script if you're restoring the DB to a new server, but ensure schema names and access groups are correctly configured; skipping it won't impact upgrade directly but might skip validations. The generateddl.sh script should be run before the upgrade to generate the DDLs for manual schema changes, especially if DBAs want to review them before applying. The cleanup.sh script helps identify (not delete directly) old or unused rules by generating a DML script, which you can review and use post-upgrade; it doesn’t remove DB tables, only rules, and the criteria for “unused” includes rules not referenced in recent rule resolutions or deprecated ones from older versions.
Would you like a checklist format for this upgrade process?
Tata Consultancy Services
CA
Thanks @Sairohith for your response!!
Today we had a meeting with all architects, and after brainstorming all the application/business aspects now we're leaning towards the in-place upgrade. So request you to alter your response considering the changed approach, if required.
As per my understanding, now with in-place we can copy both the schemas to new DB server and just run the upgrade script and skip migrate.sh, right?
Is executing generateddl.sh DDLs for manual schema changes is a prerequisite/mandatory step before we run upgrade.sh or it gets done internally as well as part of upgrade.sh but without any explicit control? What is recommended?
I have heard that many extra DB tables also get created during upgrade, does those gets removed automatically or it has to be done manually? If it needs to be handled by us then what's the best way to do it?
It would be great if you can share the checklist please.
Appreciate all your help!!
Accepted Solution
Updated: 6 May 2025 16:00 EDT
HCA Healthcare
US
Since you're now moving forward with an in-place upgrade, here's how things change. Yes, you can copy both Rules and Data schemas to a new DB server and run the upgrade.sh script there; in this case, you can skip migrate.sh because schema movement is already handled manually. Running generateddl.sh is not mandatory but highly recommended it lets DBAs review and apply schema changes manually, giving you more control and ensuring nothing breaks due to permissions or structure mismatches; however, if skipped, upgrade.sh will apply schema changes internally, just without your review. Regarding extra DB tables created during upgrade: they are not removed automatically. You’ll need to use cleanup.sh post-upgrade, which generates a DML file identifying old/unused rules review it carefully before executing. It doesn’t remove unused tables directly, so manual cleanup may be needed for truly obsolete custom tables.
Here’s a basic in-place upgrade checklist:
-
Backup Rules and Data schemas.
-
Skim rules before upgrade (if needed).
-
Copy schemas to new DB server (if infrastructure is changing).
-
Run
generateddl.sh(optional but recommended). -
Run
upgrade.shon the target schemas. -
Validate upgrade with logs and Pega UI.
-
Run
cleanup.shpost-upgrade to generate cleanup DML.
Since you're now moving forward with an in-place upgrade, here's how things change. Yes, you can copy both Rules and Data schemas to a new DB server and run the upgrade.sh script there; in this case, you can skip migrate.sh because schema movement is already handled manually. Running generateddl.sh is not mandatory but highly recommended it lets DBAs review and apply schema changes manually, giving you more control and ensuring nothing breaks due to permissions or structure mismatches; however, if skipped, upgrade.sh will apply schema changes internally, just without your review. Regarding extra DB tables created during upgrade: they are not removed automatically. You’ll need to use cleanup.sh post-upgrade, which generates a DML file identifying old/unused rules review it carefully before executing. It doesn’t remove unused tables directly, so manual cleanup may be needed for truly obsolete custom tables.
Here’s a basic in-place upgrade checklist:
-
Backup Rules and Data schemas.
-
Skim rules before upgrade (if needed).
-
Copy schemas to new DB server (if infrastructure is changing).
-
Run
generateddl.sh(optional but recommended). -
Run
upgrade.shon the target schemas. -
Validate upgrade with logs and Pega UI.
-
Run
cleanup.shpost-upgrade to generate cleanup DML. -
Test thoroughly in Dev/QA before moving to higher environments.
Tata Consultancy Services
CA
@Sairohith Thanks for sharing the steps.
By any chance do you have list of pre-upgrade steps too? Is there any useful pre-upgrade checker tool available? I've heard of this "Pega Upgrade Tool" but it's compatible with 8.1 and beyond.
HCA Healthcare
US
@PKDNDA01 Take full backups of both Rules and Data schemas and save your config files like prconfig.xml.
Review your application for any deprecated features, custom agents, or integrations that might break in the newer version, and disable any background jobs or listeners before starting.
Clear broken queues and any stale cache items, and export your rulesets as a backup just in case.
I think you won’t be able to use the Pega Upgrade Tool (which only works for versions 8.1 and above) and better ask Pega by opening a support request and see if they might suggest any tool. thanks
Tata Consultancy Services
CA
Thank you. Appreciate all your inputs @Sairohith!!
Updated: 6 May 2025 15:59 EDT
Pegasystems Inc.
US
@PKDNDA01Glad to hear that @Sairoh was able to provide helpful input! Could you please mark the reply that solved this for you or share a new reply with the solution if you are all set?
Thank you!