Guidelines for upgrading or rebuilding your application
The power of the Pega 7 Platform, and in particular, its improved application development efficiency, means that in certain circumstances rebuilding your applications on a new Pega 7 Platform base might be faster and more cost efficient than trying to retrofit an old, non-standard application onto a new platform.
The first step in moving to the Pega 7 Platform is to register your project with the Upgrade Center. From the PDN Upgrade Center, click Click to Begin my Upgrade Project to open the welcome form. Trained upgrade experts from Pegasystems can advise you about your options and give you additional information about harnessing the power of the new Pega 7 Platform.
When trying to decide whether to rebuild or upgrade your existing application, consider both the amount of custom code and the version of PRPC on which the application was originally built:
The amount of custom code in your application is the most significant factor in determining whether to upgrade or rebuild. Use the guardrail compliance score, or for earlier PRPC releases, the percentage of out-of-the-box (OOTB) functionality, to determine the amount of custom code in your application. The higher the guardrail score, the lower the risk of upgrading your existing applications. However, most customer applications require some rework, especially of the UI.
The PRPC version on which the application was first built is more significant than the current version of the product because an application built on an earlier version of PRPC is unlikely to take advantage of recent features. For example, if you originally built your application on PRPC 5.3 and later upgraded to PRPC 6.3, your application might still use PRPC 5.3 portals and code. Even though your application currently runs on PRPC 6.3, you are effectively upgrading a PRPC 5.3 application.
Refer to the following high-level heat map to help you decide whether to rebuild or upgrade your application, or whether you should consider additional factors:
PRPC frameworks
If your application is based on a deprecated framework, you must rebuild your application. The following table lists the most commonly used deprecated frameworks:
| Deprecated PRPC framework | Replacement Pega 7 Platform application |
|---|---|
| Pega Card CPM | Customer Service for Financial Services (CS-FS) |
| Collections | Customer Service for Financial Services (CS-FS) |
| Healthcare Individual Sales Process Manager | Pega Sales Automation for Health Care (SA-HC) |
| Healthcare Group Sales Process Manager | Pega Sales Automation for Health Care (SA-HC) |
| Order Management | Split into Configure, Price, Quote for Communications and Fulfillment Control Center for Communications |
| Test Management Framework | Project Management Framework (PMF) |
| Next-Best Action Advisor | Pega Marketing |
When you register your project on the Upgrade Center, you receive additional information about the upgrade path for your specific PRPC framework.
The age, maintenance history, and amount of custom functionality that was added to your previous PRPC framework also determine how easy it is to upgrade the application. For example, an old framework with a high level of customization might be easier to rebuild than to upgrade.
Some Pega 7 Platform applications are redesigned such that you need a ruleset-bridging strategy to provide compatibility with previous business processes. For example, in 2015, Visa announced significant changes to its chargeback rules. These changes are due to take effect starting in April 2017. Because Visa changed the core basis of the chargeback rules, the resulting changes have a wider impact on Smart Dispute functionality than can be included in the semi-annual Smart Dispute Compliance Releases. Smart Dispute customers must upgrade to the Pega 7.2-compliant version of Smart Dispute.
Other considerations
In addition to referring to the general guidance provided by the heat-map above, consider the following items when deciding whether to upgrade or rebuild your application.
Application size
In general, small and medium-sized applications are easier and faster to rebuild than are large and very large applications. Use the following application size categories, which are based on the number of application rules, to determine the size of your application:
- Small – 10,000 to 30,000 rules
- Medium – 30,000 to 70,000 rules
- Large – 70,000 to 120,000 rules
- Very large – more than 120,000 rules
User interface (UI) and business process customizations
The largest changes in the Pega 7 Platform involve the UI. The Pega 7 Platform now supports HTML5 full standards mode. Many previously supported UI sections, controls, and skins have changed and must be updated. The Pega 7 Platform provides reports and utilities to identify and help convert many UI items; however, you must also consider the level of nonstandard UI in your application and the underlying complexity of the business processes. For example, if your application was built on PRPC 5.5 with a heavily customized UI, but with comparatively simple underlying business processes, rebuilding might be easier than upgrading.
Examples of customized UI include custom HTML and extensive use of JavaScript. Examples of customized business process functionality include activities that reference custom Java steps or SQL statements in reports and other parts of the business processes.
Application documentation level and age
If you understand how your application works, it is easier to rebuild. If your application was built on PRPC 5.4 or earlier, and you have limited documentation or application knowledge, consider a fundamental review of your current business requirements.
If you do not understand how your application works, upgrading might be easier; however, it might be difficult to recover from an application error after an upgrade.
Training
Consider the costs of retraining your end users. Because the Pega 7 Platform uses a new standards mode UI, some UI changes might require retraining your end users, regardless of whether you rebuild or upgrade your application.
Tightly integrated customer application sets with a large number of end users might be easier to upgrade instead of rebuild because of the higher training costs that are associated with rebuilding. However, if business processes can be logically separated, rebuilding the business functionality on the new Pega 7 Platform might allow you to use new functionality faster than if you upgrade. Users can be retrained and migrated to an entirely new platform with revised and updated business processes, one sliver of business functionality at a time.
Multiple applications
In the following situations, multiple applications might affect your decision to upgrade or rebuild the applications:
- Multiple applications on a single Pegasystems instance:
All applications on a single Pegasystems instance must move to the Pega 7 Platform at the same time. If you have a large number of applications that are owned or maintained by different business units, consider splitting the applications onto multiple Pegasystem instances in the future. Separating applications offers greater ease of maintenance and update flexibility across organizational business units after the upgrade. If you decide to split your applications, first upgrade the single Pegasystems instance to the Pega 7 Platform. Then, split and migrate the applications onto different environments as a separate project. - Multiple small or medium applications spread across multiple Pegasystems instances:
Consider consolidating the applications onto a smaller number of Pegasystems instances. Often, the separate Pegasystems instances were developed over time and might have been built on different versions of PRPC, with varying degrees of customization. In this case, consider combining common business functionality as part of a rebuild effort, rather than attempting to lift and drop multiple older applications onto a single new instance.