When in the upgrade process should we upgrade the app server ?
Hello,
We are planning a migration from Pega 6.3 to Pega 7.
Because our current application server, server hardware and java version will not be supported by Pega 7, we will need to upgrade those components as well.
My question is: When in the update process can we upgrade the app server ?
The database will not change so could we for example, run the in-placer or Out-of-place migration on the database only? Then in parallel, upgrade the application server. And do these tasks independently from each other? Are those two tasks totally independant?
For example:
We have: Pega 6.3 on Jboss 5.1.2 on an Oracle Linux Server 6.5. (None is supported by Pega 7)
We will upgrade to: Pega 7, Jboss 6.4 on an Oracle linux server 7 (Not supported by Pega 6).
When should we upgrade the app server and server hardware in the overall migration process?
Any advice would be appreciated,
Thank you
**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.
Cognizant
IN
“Migration Upgrade" methodology could be followed for this scenario.
Could perform these steps in the order shown below.
- Setup a new environment with Oracle Linux Server 7 / Jboss 6.4 / Pega7
- Skim Pega6 application rulesets to a new major version. ($)
- Perform Out-of-Place upgrade on cloned Pega6 Schema resulting in split Pega7 schema.
- Configure Pega7 environment to use the upgraded split schemas ($) / data schema only.
- Perform the post upgrade steps on top of the skimmed major version. ($)
- Create product zips based on the skimmed major version. ($)
- Follow “Migration Upgrade” for higher environments.
($) Only performed in development environment.
Assumptions...
- Production environment is in sync with the lower environment
- No changes to the database server and it is compatible with both Pega 6 / 7
Paypal Inc
IN
Usually , It is suggested to do platform (app server/os/database) upgrades prior to that of Pega 7 upgrade.
Upgrade your platform to one of the Pega 7 supported platforms, test the current application thoroughly and then proceed with actual Pega 7 upgrade.
In this case, even if Pega 6 does not run on the upgraded platform, it is better to upgrade the platform before actual Pega upgrade.
In any scenario, please ensure that there are full backups and the platform/pega upgrade is carried out initially in a sandbox before development/production environments
Pegasystems Inc.
US
Please see the Upgrade Guide for your target release for more information. For example, the Pega 7.1.9 Platform Upgrade Guide includes this information:
If you are updating the version, or changing the vendor of your database server or application server, complete and verify those changes before upgrading the Pega 7 Platform. If you upgrade the supporting software at the same time as you upgrade the Pega 7 Platform, it is difficult to isolate the cause of any problems that might occur.
TCS
GB
I can see multiple options for your upgrade. Quoting couple of them here.
Option 1 :
1. Build a new RTL with Pega 7.1.9 compatible app server , Java version and hardware before Pega upgrade
2. Copy the existing Pega 6.3SP1 DB schema into another schema attached with new infrastructure.
3. Perform Out-of-Place split-schema upgrade within the new infrastructure and perform all the required Post-Upgrade activities.
4. Complete all the Route-To-Live testing and deploy into Production with Lift-Shift approach.
5. Discontinue/Re-purpose Pega 6.3SP1 infra once new Pega 7.1.9 goes Live successfully.
Option 2 :
1. Jboss Redhat EAP 5.1.2 ( with Pega 6 ) supports both Pega 7.1.6 and Pega 6.3Sp1.
2. Within the current infra, Perform Out-of-Place split-schema upgrade and perform all the required Post-Upgrade activities.
3. Complete all the Route-To-Live testing and deploy into Production with Lift-Shift approach.
4. Discontinue the usage of Pega 6.3SP1 infra once new Pega 7.1.6 goes Live successfully.
5. Upgrade your app server, Java version and hardware that is compatible with the latest version of Pega 7 ( say Pega 7.1.9 )
6. Perform "Out-of-Place UPDATE" from Pega 7.1.6 to latest version of Pega 7 ( say Pega 7.1.9 )
The above is only an overview. There are lot of considerations/intricacies within this.
I can see multiple options for your upgrade. Quoting couple of them here.
Option 1 :
1. Build a new RTL with Pega 7.1.9 compatible app server , Java version and hardware before Pega upgrade
2. Copy the existing Pega 6.3SP1 DB schema into another schema attached with new infrastructure.
3. Perform Out-of-Place split-schema upgrade within the new infrastructure and perform all the required Post-Upgrade activities.
4. Complete all the Route-To-Live testing and deploy into Production with Lift-Shift approach.
5. Discontinue/Re-purpose Pega 6.3SP1 infra once new Pega 7.1.9 goes Live successfully.
Option 2 :
1. Jboss Redhat EAP 5.1.2 ( with Pega 6 ) supports both Pega 7.1.6 and Pega 6.3Sp1.
2. Within the current infra, Perform Out-of-Place split-schema upgrade and perform all the required Post-Upgrade activities.
3. Complete all the Route-To-Live testing and deploy into Production with Lift-Shift approach.
4. Discontinue the usage of Pega 6.3SP1 infra once new Pega 7.1.6 goes Live successfully.
5. Upgrade your app server, Java version and hardware that is compatible with the latest version of Pega 7 ( say Pega 7.1.9 )
6. Perform "Out-of-Place UPDATE" from Pega 7.1.6 to latest version of Pega 7 ( say Pega 7.1.9 )
The above is only an overview. There are lot of considerations/intricacies within this.
If you say, some of your applications has to run in Pega 6 and some has to run in Pega 7, then you will not discontinue your old Pega 6 RTL infra.
At the end of the day, the approach depends upon how far your client can afford.
Thanks,
Jaffer
Accenture
IN
as you do not need to change your DB infrastructure or current DB version, and as most of the upgrade steps at the DB level, I will suggest below
you do an out of place upgrade in a cloned DB schema.
and then when in the last part you need to deploy the EAR file, then you do that into a new APP server environment which is compatible with Pega 7.
this is kind of similar approach as Option 1 of previous post by Jaffer.
Regards
Shankha