On-premises upgrade process for Pega Infinity release 8.4.2 and later for Tomcat and PostgreSQL
Pega continuously makes new features available to you so that you can incrementally and rapidly deliver value to your customers using the latest capabilities, feature enhancements, performance improvements, and security fixes.
This article applies to on-premises upgrades from Pega Infinity release 8.4.2 to Pega Infinity 8.5.1 or later for Tomcat and PostgreSQL.
To accelerate the time-to-value and pave the path to your digital transformation, the latest upgrade process enhancements include rolling upgrades and procedures that maintain high availability and improved monitoring to prevent issues. Using this process, you experience near-zero-downtime and have the opportunity to perform a go/no-go decision of your live system (production) environment upgrade.
To get started right away with a checklist of your responsibilities to complete an upgrade, see On-premises upgrade checklist for Pega Infinity release 8.4.2 and later for Tomcat and PostgreSQL.
For more information about the upgrade process, see the following articles:
- For details about the latest Pega Infinity changes with which you can maximize your Pega software investment, see What's New in Pega Technology.
- For general details about how Pega keeps you current, see Stay current with Pega.
The information provided in this document is for planning purposes and is subject to change at the discretion of Pega.
Planning considerations for upgrading Pega Infinity software
Pega collaborates with you and helps you plan and structure your upgrade approach. Pega encourages you to assess and decide on when you adopt new features and functionality available in the next version of Pega Infinity. Pega is committed to the highest software upgrade quality so that you can experience an automated, near zero-downtime upgrade. With upgrades from Pega Infinity release 8.4.2 or later to Pega Infinity release 8.5.1 or later on Tomcat and PostgreSQL, Pega uses the following feature development standards to ensure that Pega Platform seamlessly integrates with your applications that are guardrail compliant:
- Backwards compatibility for Pega Platform and Pega industry application software changes, which ensures trouble-free software upgrades.
- Elimination of required post-upgrade steps in most industry applications. The upgrade process includes a post-upgrade, feature adoption phase for completing optional post-upgrade steps, recommended configuration changes, verification steps, or for adopting new features in your application.
- Identification of new features or performance improvements with a potential for upgrade impact. To see the changes with known upgrade impact, see Pega Platform changes with upgrade impact.
- Development of analytical tools with which you can assess the upgrade impact on your application to ensure that it is ready for an upgrade. Examples include the following tools:
- Pre-Upgrade Check for Pega Marketing and Pega Customer Decision Hub
- Pega Customer Service Upgrade Checker
- Pega Sales Automation Upgrade Checker
For Pega Platform, Pega provides a pre-upgrade tool that identifies the rules that you have customized in your application to understand the impact of the upgrade; your are expected to 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.
This phased approach requires that you maintain a standard, consistent DevOps approach so that they can assess the effect of the latest Pega Platform and Pega industry application capabilities and plan your new feature adoption strategy across your environments by following your Pega Infinity upgrade. This standardization includes the following structure:
- Basic upgrade
- During a Basic upgrade, you upgrade Pega Infinity rules to the latest version, with minimum disruption. Typically, the Basic upgrade phase take you about two weeks to complete. In this phase, you make any necessary application changes to ensure functional correctness and upgrade compliance. You can adopt the latest performance and security improvements and test existing functionality using your current testing processes. This phase excludes adopting features of the new version of the Pega Infinity to ensure a near zero-downtime upgrade of the production environment.
- Feature adoption
- After the Basic upgrade is complete, you use this phase to take advantage of the latest Pega Infinity and industry application features using your standard DevOps process.
This phased approach requires that you maintain a standard, consistent DevOps approach so that you can assess the effect of the latest Pega Platform and Pega industry applications capabilities and plan your new feature adoption strategy across your environments following your Pega Infinity upgrade. This standardization includes the following structure:
- You configure your staging environment similar to, but not necessarily the same as, your production environment. This approach requires that:
- The rules and data schema Data Definition Language (DDL) are the same as the production rules and data schema DDL.
- The rules content is identical except for configurations specific to the production environment.
- The staging environment contains the appropriate data; copying production data is not allowed.
- You must use a 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. If you upgrade on premises or Client-managed Cloud, Pega Cloud, you are encouraged to use Deployment Manager for your standard deployment pipeline, although Pega supports the use of third-party automation services for your application change adoption pipeline. For details, see Using Deployment Manager for model-driven DevOps.
On-premises, near zero-downtime upgrade experience
You clone the database of your staging environment according to your database vendor's tooling. On this cloned environment, you test by using your existing test suites, which minimizes efforts and shortens the upgrade life cycle environments.
During the environment upgrades, both you and your your can continue to access and use your applications in your environments with minimal disruption. This experience includes the following advantages:
- Application developers can continue to work by creating Pega rules in your environments.
- Application users can create and read cases, perform search, or update your next-best-action configurations.
The following limitations and expected behaviors within your environments apply but are not limited to your upgrade experience when upgrading from Pega Infinity release 8.4.2 or later to Pega Infinity release 8.5.1 or later for Tomcat and PostgreSQL:
- User sessions are not persisted; active users might be logged off during the environment restart.
- Background processes are paused automatically; typically, the pause is only several minutes. The upgrade process waits up to 30 minutes for an activity that runs in the background to finish its work; if the activity is not finished after 30 minutes, the background process is stopped. You should review these application development best practices to ensure that your background processing takes only several minutes to complete:
- With these automated background processes paused, some Customer Decision Hub functions will be delayed during the upgrade process; after background processing resumes, these Customer Decision Hub functions automatically resume. These functions include, but are not limited to, next-best-action scheduled outbound runs, Output template finalization, and Segment population.
- Pega Chat routing while an upgrade is initiated might wait between 30 minutes to 2 hours for the chat to be connected to a client representative; if a timeout is configured for the chat to get connected, then those timeouts might be reached and the end user might have to retry.
- Existing mashups must be migrated; beginning in Pega Platform 8.5.1, Pega Web Mashups include a channel ID in the mashup code for validation with your mashup server. Create new mashup code on your upgraded, cloned environment running release 8.5.1 or later so the mashup rule form includes a Mashup channelID that is automatically included in your application testing rule in your upgrade pipeline. To create a new mashup, see Creating a mashup. Be sure to update existing website configurations with the new mashup code.
For more information about migrating mashups, see Migrating existing mashups.
- In-flight cases will be upgraded if you open them during the upgrade; you should refer to your application post-upgrade guidance for bulk-upgrade processing of existing cases.
The upgrade process phases are broken into the following discrete steps:
- You clone a staging environment and upgrade this cloned environment to the latest Pega Platform and industry application software. The clone maintains your application and data from the staging environment. Unless you need them for testing, it is not recommended that you clone the following assets:
- Decision data store (DDS) datasets
- Kafka data sets
- Archived data, case attachments, and SFTP data
- In Deployment Manager, you migrate rules from the upgraded, cloned staging environment to the production environment for each application using an upgrade pipeline. The upgrade pipeline includes two product rules that contain any upgrade fixes and confidence testing assets along with all required data instances to test the application. For details, see Configuring upgrade pipelines. If required, you select rules to sync from the production environment to the upgraded, cloned staging environment. For details, see Syncing rules between the production environment and the upgraded, cloned, staging environment in Deployment Manager.
- You perform application compatibility testing and validation on the upgraded, cloned staging environment, during which time you can make any changes or fixes necessary to verify expected application functionality while using the new version of Pega Infinity. You can continue to use standard deployment pipelines in Deployment Manager and should also migrate any changes to the cloned staging environment. Helpful resources include:
- You upgrade your respective production environments during the your defined maintenance window.
- You optionally perform a final confidence check of your applications in production by accessing a temporary production URL that points to a node within your production environment.
- Optional: You make a go/no-go (accept or abandon) decision as a result of the upgrade confidence test of the changes. During this set of steps, you use Deployment Manager to promote the following to the temporary production URL:
- The upgrade fixes identified during step 3. For details, see Migrating upgrade fixes to production.
- The confidence testing assets that you created during step 2.
- After the go decision, you perform the following actions:
- Delete the temporary production URL.
- Initiate a rolling restart of your live system (production) environment.
After the rolling upgrade of the production environment is complete, for each application, if you identified data changes in step 3, you promote them to the production environment by using Deployment Manager.
- You upgrade all non-production environments during your defined maintenance window after completing the upgrade on the production environment.
- You import any upgrade fixes discovered as part of step 3 to all non-production environments. It is recommended to use Deployment Manager to promote these changes. To promote these changes by using Deployment Manager, review Migrating application upgrade changes to non-production environments.
- You remove the outdated rule schema in each upgraded environment.
- You delete the upgraded, cloned staging environment after completing all of the live environment upgrades.
At this point, the Basic upgrade phase is complete and the Feature Adoption phase begins. You use the second phase for completing optional post-upgrade steps, recommended configuration changes, verification steps, or adopting new features in your application using your standard DevOps process.