Verify the built on application and rulesets versions are specified correctly in the application rule.

All those things are already taken care of.

Assuming we do a major skim before the upgrade. Most likely the new major version is locked even before the upgrade. Post-upgrade what should be our approach when we reach the Lock & Roll step ?

I would say that one of the main reasons for doing a Lock & Roll is to provide a clear distinction between the code that was pre-upgrade and post-upgrade. Doing a pre-upgrade skim would achieve this. However, although it is recommended, a pre-upgrade skim is not mandatory. If a pre-upgrade skim is not done then I'd say a lock & roll takes on greater importance.

In your case, the lock & roll is not so key as your post upgrade code changes will be in a new major version anyway - and as pointed out above, you won't be able to lock your rulesets if they have been locked and skimmed anyway. Unless you want to use the lock and roll tool to a create a new application rule, I'd suggest you can skip this step and continue your post upgrade steps and future development in your new major version.

Thanks for the insight HOBBSA01.

From my perspective pre-upgrade skim is highly recommended for the following reasons...

*Helps with the pre-upgrade assessment / estimation; especially while verifying “rule counts” in the new skimmed major version.

*Rule zips and the new Pega7 rule schema will be lighter. (only incase of install-migrate approach)

*Upgrade.bat and migrate.bat (for rules schema) might take less time to run hence less likely to fail. (assuming the old ruleset major versions are deleted after the major skim) 

*Post upgrade steps like “upgrade controls” / “revalidate and save” should take less time.

*Rule resolution will be faster in the new pega7 application.

Hi Vignesh,

Following 2 points of your comment are CONDITIONAL.

*Rule zips (only incase of install-migrate approach) and the new Pega7 rule schema will be lighter.

*Upgrade.bat and migrate.bat might take less time to run hence less likely to fail. (only rules schema)

The condition is , after you skim to a Higher Major version, you need to delete all the older versions from the prior major versions and test & Verify. Until, you do this, your Rulebase is NOT lightened and hence might take more time for upgrade.

THanks, Jaffer

Thanks for pointing out the gaps Jaffer. I have edited my previous comment accordingly.

We are upgrading a 6.2.1 application to 7.1.9

As a pre-upgrade step we performed a major skim for all the existing application rule sets from 01- to 02-

When we were about to delete all the 01- rule sets we realized that all the Rule-Obj-Class definitions are still associated with 01-XX-XX rule sets; most of them in 01-01-01. So skims do not accommodate Rule-Obj-Class definitions; since they are only associated with a rule set version for portability and are not rule resolved ?

Kindly post your views and suggestions to tackle this situation.

We created a custom activity to adjust the .pyInitialVersion for all Rule-Obj-Class instances that were still pointing to 01-XX-XX versions.

The activity does the following ...

• Obj-Browse on Rule-Obj-Class instances; to create a list of targeted pzInsKey(s)
• Loop the list and perform a Obj-Open-By-Handle on the class instance.
• Update the .pyInitialVersion to the desired value (02-01-01; passed as a parameter).
• Save the class instance and exit the current loop.
• Continue looping till the list is exhausted.

We noticed a glitch in V6.2.1 while doing a major skim.

After major skimming from 01-XX-XX to 02-01-01 the new major version still had all the withdrawn rules from 01-XX-XX

Major skimming should exclude withdrawn rules however it did not happened in our case.

REFERENCE # https://community.pega.com/sites/default/files/help_v72/procomhelpmain.htm