Question
Ministry of Education Saudi Arabia
SA
Last activity: 7 Aug 2023 10:33 EDT
Out of Place Upgrade from 7.3.1 to 8.6.2 Data Migration
We are planning to upgrade from 7.3.1 to 8.6.2, our configuration is as below
Application server: Tomcat
Operating System: Linux
DB: Sql Server
In House application not cloud. Application is already running in production.
We opted to go with Out of place. Our DB team is asking for below questions to assess the lift & shift option to migrate data schema from old server to new server.
1. Any recommendation to keep the new schema's within the same old server, any dis advantages if DB team creates new DB server for 8.6.2 and migrate data schema?
2. Will there be Rules schema having referential Integrity dependency with Data Schema?
3. What will be the count and list of Data Schema tables which will be part of this activity?
4. What is the expected size and row count of Data Schema tables and its order of data load? We can get the count from DB but is there any order of data load?
5. There are Data schema tables which doesn’t have Primary Key (like: pc_data_workattach). Why is it so as certain Data Migration Technique expects PK for maintaining data Integrity.
Accepted Solution
Updated: 9 Dec 2021 5:13 EST
Pegasystems Inc.
IN
You can choose third step
Trial Prod Migration:
1) Clone the rules and data schema from old to new prod
2) Perform the in place upgrade (rules and data)
3) Import required application RAP/bug fixes
4)Test properly
Actual Prod Migration
5) Drop only data schema from new prod (retain rules as is)
6) Re-import the DATA schema tables as part of downtime and perform the data only upgrade
7) Import the data instance
8) Smoke Test and decide go/no-go
This is less risky approach
Pegasystems Inc.
IN
1. Out-Of-Place method creates new RULES schema and not DATA schema. Existing DATA schema can be used as-is for 8.6 also. why your DBA saying new server for DATA schema?
2. No.
3. 8.6.2 introduce the new tables. not sure with exact number. You can try this in lower environment and find out
4. same as above
5. pc_data_attach contains primary key. I agree each table should have primary key
Updated: 29 Nov 2021 2:42 EST
Ministry of Education Saudi Arabia
SA
Here is the approaches we thought about
Pega 7 Old application server & old DB Server (Old schemas)
Pega 8 New application server & New DB server (New schemas)
Rules schema will be upgraded with Product import along with upgrade fixes.
For Data schema, copy delta (only required tables data) from old pega 7 data schema to new pega 8 data schema using SQL Server Export Import option.
DNS switch to point to new Pega 8 after upgrade.
Updated: 29 Nov 2021 2:47 EST
Pegasystems Inc.
IN
This path works fine. Only challenge could be longer downtime as it required to migrate the data schema tables from old DB server to new one and then performing the data only upgrade during the downtime
Updated: 29 Nov 2021 3:01 EST
Ministry of Education Saudi Arabia
SA
Another option is clone Pega 7 data schema to Pega 8 and run Upgrade.sh, you think this requires less downtime compared to copying delta using sql server export import option?
Option 1: Clone Pega 7 to Pega 8 and run Migrade.sh for Rules Schema & Upgrade.sh for Data Schema. This requires more down time because Migrade.sh takes time.
Option 2: Same option i described in my post.
Pega 7 Old application server & old DB Server (Old schemas)
Pega 8 New application server & New DB server (New schemas)
Rules schema will be upgraded with Product import along with upgrade fixes.
For Data schema, copy delta (only required tables data) from old pega 7 data schema to new pega 8 data schema using SQL Server Export Import option.
After data import we can run tools to find any issues in data schema. or do we need to run the upgrade.sh?
Option 3: Similar to option 2 but data schema will be cloned from Pega 7 to Pega 8 and run the Upgrade.sh for Data Schema.
Another option is clone Pega 7 data schema to Pega 8 and run Upgrade.sh, you think this requires less downtime compared to copying delta using sql server export import option?
Option 1: Clone Pega 7 to Pega 8 and run Migrade.sh for Rules Schema & Upgrade.sh for Data Schema. This requires more down time because Migrade.sh takes time.
Option 2: Same option i described in my post.
Pega 7 Old application server & old DB Server (Old schemas)
Pega 8 New application server & New DB server (New schemas)
Rules schema will be upgraded with Product import along with upgrade fixes.
For Data schema, copy delta (only required tables data) from old pega 7 data schema to new pega 8 data schema using SQL Server Export Import option.
After data import we can run tools to find any issues in data schema. or do we need to run the upgrade.sh?
Option 3: Similar to option 2 but data schema will be cloned from Pega 7 to Pega 8 and run the Upgrade.sh for Data Schema.
Which of the above options will be good for our requirement ? which one requires less down time and less risky with no issues in live after upgrade? Is there any better option available other than these?
Accepted Solution
Updated: 9 Dec 2021 5:13 EST
Pegasystems Inc.
IN
You can choose third step
Trial Prod Migration:
1) Clone the rules and data schema from old to new prod
2) Perform the in place upgrade (rules and data)
3) Import required application RAP/bug fixes
4)Test properly
Actual Prod Migration
5) Drop only data schema from new prod (retain rules as is)
6) Re-import the DATA schema tables as part of downtime and perform the data only upgrade
7) Import the data instance
8) Smoke Test and decide go/no-go
This is less risky approach
Ministry of Education Saudi Arabia
SA
5) Drop only data schema from new prod (retain rules as is)
Initially clone Rules & Data schemas along with data from old prod to new prod, later drop the data schema from new prod before down time?
6) Re-import the DATA schema tables as part of downtime and perform the data only upgrade
What tables we need to re-import we might not require to import all the tables data right?
7) Import the data instance
Data Types / local tables?
Pegasystems Inc.
IN
5) Yes before downtime
6) All tables of data schema (ootb tables + application specific)
7) Data instance like DSS... those are newly created in pega 8.x, when you drop pega data schema before downtime. it removes everything hence you need to package them and re-import