Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Guidelines for upgrading or rebuilding your application

Updated on April 30, 2019

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.

If you currently use PRPC 4.x or PegaWorks, you must rebuild your application because there is no upgrade path from PRPC 4.x. Upgrade paths are available from PRPC 5.1 and later.

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:

For Pega 7, you can upgrade your application. For other versions, the decision depends on the percentage of customized rules and the version of PRPC on which the original application was built. 
For more information, see the text.

If your application falls in the yellow check/remediate area, or if your application is based on a framework, consider the following other 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 frameworkReplacement Pega 7 Platform application
Pega Card CPMCustomer Service for Financial Services (CS-FS)
CollectionsCustomer Service for Financial Services (CS-FS)
Healthcare Individual Sales Process ManagerPega Sales Automation for Health Care (SA-HC)
Healthcare Group Sales Process ManagerPega Sales Automation for Health Care (SA-HC)
Order ManagementSplit into Configure, Price, Quote for Communications and Fulfillment Control Center for Communications
Test Management FrameworkProject Management Framework (PMF)
Next-Best Action AdvisorPega 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.


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.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us