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.
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 3rd (2nd migrate for creating and granting objects) and 4th steps (Data only Upgrade) of Upgrade process.
Clean the unused rules table from the UAT Data schema.
Now the 2nd Part where separate data schema for separate app, but common rules schema. For that please see the attached diagram.
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.,.