A leading financial information services provider was running Pega 6.2 for one of its biggest and most complex business functions. However, the application performance had degraded over time and the user interface code was also getting progressively obsolete, requiring significant changes to support a new browser version. Above all, the obsolete Pega version and the technology stack (UI to be specific), risked increasing the technical debt.
Deciding to Upgrade
The primary objective for upgrading Pega v7.1 at the expense of business critical projects for the company were manifold. A few of them are listed below:
- Leverage responsive user interface
- Internet Explorer 10.x browser support
- Improve overall application performance
- Reduce browser plug-in dependencies
- Split database dchemas for better maintenance
- Better mobility support
Assessing Prior to Upgrade
The journey started with a pre-upgrade assessment that was performed even before Pega 7.1 was released for enterprise usage. The key focus of the pre-upgrade assessment was to quickly verify the key features of 7.1 and identify quick wins, if any. The company also wanted to come up with an upgrade approach that detailed estimates and create a clear roadmap.
The pre-upgrade was time-boxed to 6 weeks to keep the scope fairly tight. The activity was a runaway success achieving all key objectives within the defined timelines. Given the outcome, it was no surprise that the mandate was to go ahead with the upgrade as and when Pega released v7 for commercial use.
Planning the Upgrade Journey
Pega v7 was released for commercial enterprise level applications in summer of 2014. Pega 7 upgrade efforts were planned for a 4 month (16 weeks) period. This included support development on Pega 7 so that an immediate functional release could happen post Pega 7 release. Below are the steps to be completed:
- Environments setup
- Skimming of rulesets & sanity testing
- Perform Pega 7 upgrade on Dev & QA
- Multiple rounds of regression testing & defect fixing
- Perform Pega 7 upgrade on UAT
- UAT sign-off
- Production upgrade
Future enhancements were already being developed on Pega 7 and an on time production release of Pega 7 was critical for meeting business needs. However, the QA team had identified a huge volume of defects during their regression cycles in below areas:
- Functional defects contributed by Pega product, code refactoring and backward compatibility issues
- UI specific issues: HTML5 / IE10 document mode changes
The company was able to turn these roadblocks into stepping stones. They learned from these problems, and daily triage calls and joint overall status calls among teams helped monitor progressive status of the project.
Key Takeaways for Future Upgrade Projects
Upgrading to Pega 7 has two approaches: the “like-to-like” upgrade and the “compliance upgrade”. Like-to-like primarily focuses on making existing Pega 6.X version work as-is and not to meet the latest Pega 7 standards, such as HTML5 compliance and responsive UI. A compliance upgrade is on par with Pega 7 standards and involves larger refactoring efforts, especially if there is an inherited legacy code from previous Pega versions. The objectives determined through the assessment phase, can help select the best suitable approach.
Assessment prior to upgrade plays a prominent role in determining the impact required and expected stability of the upgrade. It also helps one to sketch an execution plan. Some of the key aspects that to be considered for the assessment phase are:
- Deprecated controls
- Backward compatibility
- Code refactoring efforts
- Determine product-related issues
Pega v7 upgrade need to be planned with proper assessment phase in order to predict the risk and efforts accurately. Clients are looking forward to adapt the new maintenance level update (MLU) approach to be on top of the latest Pega 7 versions going forward and to avoid big-bang upgrade approach and business is leveraging case management and mobile support.