Hi Bhusan,

I am assuming that the approach is final that the future deployment architecture will have single PRPC installation where all 3 application will be hosted. rules schema will be single which will host all rules from all 3 application. But transactional Data for 3 application will be in 3 different schema.

First I am describing the approach for Upgrade and 2nd I will describe the common rule schema but different data schema approach.

Upgrade Approach:

In Dev,

is your approach is correct, here we have to do rule migration approach, where 1st a new PRPC 7 installation need to be established and then there RAP of all 3 6.X application need to be imported, and all revalidate&Save and other post upgrade steps need to be done.

but in PROD and UAT it is not so easy because of the live data.

In Prod/UAT (even may be in SIT)

Step 0: create 2 blank schema for Rules and Data

Step1: import the ruleschema from the Pega 7 Dev enviornment into new fresh UAT env. no need to do anything else because it is already Pega 7 upgrae rule schema.

Step2 : in NEW UAT Data schema import the dump of old UAT schema for APP 1 (Rules + Data)

Step 3: Take export of Transactional tables of App 2 and App3 from their old existing environment, and import in the new UAT env data schema where already R+D of App 1 exist.

Step 4: run the 3^rd (2^nd migrate for creating and granting objects) and 4^th steps (Data only Upgrade) of Upgrade process.

Step 5:

Clean the unused rules table from the UAT Data schema.

Now the 2^nd Part where separate data schema for separate app, but common rules schema. For that please see the attached diagram.

Regards

Shankha

Hi,

This would be a possible approach, but the application specific schema would be an additional schema other than the RULES & DATA schema. So, as the applications are three then the total number of schemas would be 5 schemas - 3 schemas being application specific transactional data holding, 2 would be the Pega schemas (RULES & DATA). The 3 schemas which are newly introduced would not participate in any update/upgrade as they hold only application specific transactional information.

Few additional considerations to be made in the entire process are

• How will the Operator records be managed or mapped considering all the applications have common operators accessing
• Do these applications have Class, RuleSet, AccessGroup, etc. kind of rules with same names

In the approach mentioned by Shankha, the steps mentioned for Production / UAT are not proper. When the RULES schema from DEV is being copied into UAT/PROD then importing the application RAP with rules & data is not required, the RAP can be only data RAP.

If you are modifying the D-A-D-T rules specifying the schema names then make sure it is not being done for the Pega OOTB D-A-D-T. When updating to a later version then schema mapped D-A-D-T might cause failures. Instead, you can use a separate JDBC/JNDI source Database and configure that in the D-A-D-T.

You need to plan for additional tasks like

• Migrating the data belonging to shared tables without any data conflict
• Application specific customizations performed to shared tables
• Pega Strategic Applications / Industry Solutions / Frameworks usage, if any
• Security model like Privileges, Access Roles, Access Groups to be migrated, etc.,.