On-premises Pega upgrade

An on-premises Pega system runs on servers and a database that your own organisation owns and operates, as opposed to Pega Cloud where Pega runs it for you. Upgrading such a system is a project, not a button. This article gives you the outline that most on-premises upgrades follow, and the questions to answer before you start.

Phase 1: Plan

Read the target version's release notes and the platform support matrix. Confirm that your database, Java version and application server are supported.
Decide between an in-place or out-of-place upgrade.
List every application, ruleset and integration that will be affected, and agree the downtime window.
Take a full backup of the database and the current installation, and confirm you can restore it.

Phase 2: Prepare a non-production copy

Restore a copy of production into a test environment.
Run the upgrade there first, using the same scripts and settings you plan to use in production.
Time each step. The timings tell you whether the production window is long enough.

Phase 3: Upgrade

Stop the application servers.
Run the database upgrade scripts or the installer's upgrade option, as the guide for your version describes.
Deploy the new Pega software to the application servers and update the configuration files, such as the data source settings.
Start the servers and let the system rebuild its caches.

Phase 4: Post-upgrade

Run the upgrade utilities and revalidate your rules. See our walkthrough of the post-upgrade fixing process.
Clear out deprecated rules and warnings.
Regression test the main flows and integrations, and run a performance test.
Monitor the logs closely for the first days.

A worked example

A bank running Pega on its own servers plans a Saturday night upgrade. In the two weeks before, the team upgrades a copy of production twice, finds that one custom Java library fails, and fixes it. On the night they stop the servers at 22:00, finish the database upgrade by 01:30, start the new servers at 02:00, and pass the smoke tests by 04:00. Because the timings from the rehearsal were recorded, the window was long enough with room to spare.

Risks to manage

Custom code, such as Java or JavaScript, may not work on the new version.
Third-party libraries and JDBC drivers may need updating.
Integrations may need retesting if the partner's API or your connector settings changed.

Interview tip

Talk through plan, rehearse, upgrade, verify, and mention that you always take a backup you have proven you can restore. Read more in the Upgrade label.