On-premises upgrade checklist for Pega Infinity release 8.4.2 and later for Tomcat and PostgreSQL
Version:
This checklist details the minor upgrade requirements and actions that are needed during an upgrade of all of your on-premises environments with Pega Infinity release 8.4.2 and later to Pega Infinity release 8.5.1 or later for Tomcat and PostgreSQL. Use this checklist to plan and complete your upgrade process steps and stages.
Prepare for the upgrade
During the Pega Infinity upgrade process, you perform and manage all the upgrade tasks as described in the following checklist:
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | To familiarize yourself with the process, review On-premises upgrade process for Pega Infinity release 8.4.2 and later for Tomcat and PostgreSQL. |
|
| ⬜ | To learn about the benefits of keeping current with Pega, read about the latest features, and learn about any features or processes that Pega has identified with upgrade impact, explore the following topics: | |
| ⬜ | If applicable, run the Pega-provided pre-upgrade checker on your applications to ensure that Pega Infinity seamlessly integrates with your applications. Examples of pre-upgrade checkers include:
For Pega Platform, Pega provides a pre-upgrade checker that identifies the rules that you have customized in your application, to help you understand the impact of the upgrade. You should then use the results to retrofit these rules after the upgrade. As a best practice, do not overwrite or customize Pega rules. For more information, see Pega Upgrade Tools. |
|
| ⬜ | Maintain a standard, consistent DevOps approach so that you can assess the effect of the latest Pega Platform and industry application capabilities and plan your new feature adoption strategy across your environments after you upgrade to Pega Infinity. This standardization includes the following structure:
|
|
| ⬜ | Review these application development best practices to ensure that your background processing takes only several minutes to complete: |
|
| ⬜ | Plan for your upgrade journey in an upcoming sprint. During the sprint, do not promote any new application changes to the production environment. |
|
The Basic upgrade process enables you to upgrade your Pega industry applications to the latest Pega Infinity version with minimum disruption.
In this phase, you clone the database of your staging environment based on your database vendor's tooling. You prepare this environment for upgrade testing using test data, test cases, and any operators as needed.
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | If necessary, plan maintenance communication with your application users around your schedule for the upgrade. | |
| ⬜ | Clone the database of your staging environment according to your database vendor's tooling. | |
| ⬜ | Perform pre-upgrade tasks on your cloned, staging environment. For more information about Pega Platform, see Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. For more information about industry applications, see the appropriate application upgrade guide. | |
| ⬜ | Upgrade your cloned, staging environment. For more information, see Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. | |
| ⬜ | If you have existing web mashups, create new mashup code on the upgraded, cloned staging environment. For more information about migrating mashups, see Migrating existing mashups. |
Validate the Basic upgrade using application testing
In this stage, you test all applications in your upgraded, cloned staging environment. You should also plan to make any critical changes, if any were recommended as part of the upgrade impact assessment that you complete in the Prepare for the upgrade stage.
This phase does not include adopting features of the new version of Pega Infinity that are done later, during the Feature Adoption phase of the upgrade process.
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | For each application, import the following applicable testing assets into the upgraded, cloned staging environment:
The clone maintains your application and data from the staging environment. Unless you want to use the following assets for testing, you do not have to clone them:
While you must ensure that appropriate test data exists in the staging environment, copying production data is not recommended. | |
| ⬜ | For each application, sync selected rules from the production environment to the upgraded, cloned staging environment. For more information, see Syncing rules between the production environment and the upgraded, cloned, staging environment in Deployment Manager. | |
| ⬜ | If applicable, run the Pega-provided Customer Service post-upgrade checker on your applications to ensure seamless integration. For more information, see Pega Customer Service Upgrade Checker and "Checking for rule overrides in Pega Customer Service" in Pega Customer Service and Pega Sales Automation Upgrade Guide. | |
| ⬜ | For each application, perform application compatibility testing and validation on the cloned, upgraded staging environment. Ensure you have test coverage for the following Pega artifacts:
Helpful resources include: | |
| ⬜ | For each application, make required changes to address issues identified during the testing. The required rules and data changes include addressing critical security-related enhancements, as well as problematic configurations identified by the pre-upgrade assessment tools during the Prepare for the upgrade stage. In later stages of the upgrade process, you promote these changes accordingly, depending on the stage. | |
| ⬜ | Create an upgrade pipeline in Deployment Manager to migrate rules from the upgraded cloned, staging environment to the production environment for each application. The upgrade pipeline includes two product rules that contain any upgrade fixes, as well as confidence testing assets and all data instances required to test the application. For more information about configuring upgrade pipelines, see Configuring upgrade pipelines. | |
| ⬜ | Optionally, if you are migrating existing mashups and want to access them during the upgrade, create a product rule that contains the mashup and promote it to the production environment. For details, see Migrating existing mashups. | |
| ⬜ | If you are migrating existing web mashups, add them to the product rule in the upgrade pipeline and promote the product rule to production. For details, see Migrating existing mashups. |
Perform a Basic upgrade of your production environment
In this phase, you upgrade your production environment.
Optionally, before the rolling restart of Pega Platform, you can promote any necessary changes from the upgraded staging clone to a temporary production URL for testing. You can then complete your confidence testing and communicate a go/no-go (accept or abandon) decision; you should only upgrade your production environment following a go decision.
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | Upgrade your production environment. For more information, see Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. For more information about upgrading industry applications, see the appropriate upgrade guide. | |
| ⬜ | Optionally, before the rolling restart of Pega Platform, you can promote any necessary changes from the upgraded staging clone to a temporary production URL for testing. You can then complete your confidence testing and communicate a go/no-go (accept or abandon) decision; you should only upgrade your production environment following a go decision. For more information about bringing up a temporary URL, see the Optional: accessing a temporary URL to perform go/no-go testing of your production environment section in Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. | |
| ⬜ | Update the DMReleaseAdmin auth profile and the DMAppAdmin operator passwords to interact with Deployment Manager and complete your go/no-go confidence testing. If required, you may have to re-create the profile and operator. | |
| ⬜ | For each application, use Deployment Manager to start a new deployment to promote the following instances from the cloned staging environment to the temporary production environment:
| |
| ⬜ | On the temporary production URL, enable the operators that are needed for confidence testing. | |
| ⬜ | Perform the application confidence testing on the temporary production URL. For details, see Understanding confidence testing. | |
| ⬜ | Indicate approval for the upgrade on production and perform a rolling restart. For more information, see Performing a rolling restart in Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. | |
| ⬜ | After your go approval, delete the temporary production URL and upgrade your production environment to the latest version of Pega Infinity. | |
| ⬜ | After the rolling upgrade of the production environment is complete, for each application, you use Deployment Manager to promote the upgrade fixes that you identified during the Validate the Basic upgrade using application testing stage to the production environment. This is a required step to re-import any data instance or schema changes. For details, see Migrating upgrade fixes to production. | |
| ⬜ | Verify that your application is working as expected. | |
| ⬜ | Remove the outdated rule schema in your production environment after the upgrade. |
Perform a Basic upgrade of non-production environments
During this stage, you upgrade all non-production environments during your defined maintenance window, after completing the upgrade on the production environment.
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | Upgrade non-production environments. For more information about upgrading Pega Platform, see Near-zero downtime Upgrade Guide for Pega Platform version 8.4.2 and later for Apache Tomcat and PostgreSQL. For more information about upgrading industry applications, see the appropriate upgrade guide. | |
| ⬜ | After every non-production environment upgrade, for each application, import any required rules and data changes discovered during the Validate the Basic upgrade using application testing stage, during application compatibility testing and validation from your upgraded, cloned staging environment. To promote these changes by using Deployment Manager, review Migrating application upgrade changes to non-production environments. | |
| ⬜ | Log in to each upgraded, non-production environment and verify that your application is working as expected. | |
| ⬜ | Remove the outdated rule schema in your non-production environment after completing all of the non-production environment upgrades. | |
| ⬜ | Delete the upgraded, cloned staging environment. |
Maintain Feature Adoption in your environments
At this point, the Basic upgrade phase is complete and the Feature Adoption phase begins. Use this phase as part of your standard application development life-cycle with which you complete optional post-upgrade steps, recommended configuration changes, verification steps, or adopt new features in your application using the standard DevOps process.
| Stakeholder | Required actions with each stage | Date completed |
|---|---|---|
| ⬜ | Complete post-upgrade tasks for Pega Platform and your industry applications. |
|
| ⬜ | In your development environment, enable and integrate the new features of the latest release that you identified during the Prepare for the upgrade stage of the upgrade process into each of your relevant applications. Use your existing deployment pipeline with a minimum number of development, staging, and production environments and use the pipeline to promote the latest application functionality to your production environments. For details, see one of the following:
|
|