Discussion
USAA
US
Last activity: 6 Apr 2018 19:26 EDT
Need suggestion on upgrade strategy
We have an aplication on PRPC 6.3 with CPM for FS framework running in production. There are some CR's approved and available in UAT ready to be moved to production soon and few CR's yet to be approved. Also there are fixes for some bug's in UAT yet to be moved to production.
With this state of the application (Code in pre-production is more than production with 12 CR's and some Bug fixes) we are thinking through what would be the better approach for Pega 7 Upgrade.
Approach 1: Take the production CUT as of today and upgrade to Pega 7. Install the approved CR's and Bug Fixes once the upgrade is successful and retrofit these rules based on need.
Approach 2: Upgrade along with all the CR's and Bug Fixes to Pega 7 and later delete the ruleset versions pertaining to the specific CR's which are not approved by the customer for production (In this case ruleset skimming will not be done before upgrade)
Approach 3: Skim the production CUT to one version and install all the CR's and bug fixes on top of the skimmed version before upgrade. Perform Pega 7 upgrade and delete the unwanted RS versions if any specific CR is not approved.
These three options have been thought through but we are looking at understanding what would the best approach which can result in maxium gain in terms of time, effort and risk. Please let us know your recommendations and any other alternative way out other than the three options above.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accenture
IN
below is another approach which I will recomend
Step 1: Do Major skimmin in your current DEV. but your application in your current DEV wll still point to old Major version. and your parallel development will continue in lower major version only, but in a new patch version.
Step 2: Clone a new enviornment with current DEV schema copy.
here you will do the Upgrade, and your application will point to Highest major skimmed version.
Step 3: Make unavailable those selective rules which are part of not yet approved CR. even you can keep it, as you will do basic testing after Upgrade.
Step 4: when Upgrade done, import the RAP from old dev for the parallel development work which is still in lower major versions., to new DEV
Step 5: copy the rules from lower version to higher major version in new dev, using System ->Refactor->Ruleset->Copy/Merge Ruleset
Regards
Shankha
USAA
US
Hi Shankhabrata,
Thanks a lot for the suggestion.
While the approach you have suggested would help us for supporting parallel development along with upgrade, the major concern we had was to understand what would be the best approach if the CR's (which were already developed and moved to UAT) should not be in production later due to any denials from business.
It will be easier for us to deal with deploying the CR's later post upgrade seperately but will this have an impact or increase the retrofitting effort? Is it going to make a lot of difference if we do the upgrade with the CR code rather than importing these seperately on top of upgraded prod code? (Delpoying the CR's seperately post upgrade is easy for us because we can select and deploy only the approved CR's by then and no code rollback would be needed).
Pegasystems Inc.
IN
Approach 1 is looking good in this scenario as no extra code is going in the system and there will be no issus of deleting non approved CR codes etc.In your route to live plan if possible, you can try to put all approved CRs till date in pre -prod environment and do smoke testing and then carry forward the same rule schema to Production using Lift and Shift approach. If there is any new CR rolled out in between it has to be rolled out in upgraded environment later but in this way you are minimizing the chances of same.