Constellation migration approach for traditional UIKit application

User Experience
, , ,
1

Hi All,

We are currently on Pega 24.1.3 and are planning an upgrade to Pega 26 in September. Our application consists of one parent case type and 250+ child case types. For this discussion, let’s refer to the application as TraditionalApp.

We have a requirement to introduce a new child case type under the existing parent case type. To support this, we are considering a two-phase migration from our current UIKit-based TraditionalApp to Constellation.

Phase 1

  1. Create a new ConstellationApp
  2. Add TraditionalApp as a built-on application
  3. Run Traditional UI in Constellation for the parent case type, which would render the UIKit rules through iframe/mashup views in Constellation
  4. Create a Blueprint for the new child case type by exporting one of the existing child case types using the App Signature portal and Blueprint the new child case type.
  5. Import the Blueprint using the wizard to generate the new child case type directly within ConstellationApp
  6. Point users working on the new child case type to ConstellationApp
  7. Existing users working on the one parent case type and 250+ child case types continue to point to TraditionalApp.

Questions for Phase 1:

  • Will importing the Blueprint for the new child case type generate a new class structure?
  • Will that impact the work pool of the parent case type?
  • Are there any best practices for generating only the new child case type class structure in this scenario?

Phase 2

  1. Run App Signature on the full parent case type and all 250+ child case types in UIKit-based TraditionalApp to export them for Constellation refactoring in Blueprint
  2. Import the Blueprint using the wizard to generate the artifacts in ConstellationApp
  3. Remove TraditionalApp as a built-on application
  4. Migrate all inflight cases to the new ConstellationApp view-based UI
  5. Point all user access groups to ConstellationApp

Question for Phase 2:

  • Would this phase impact the classes and rules generated during Phase 1?

Any guidance or best practices would be greatly appreciated.

Thanks!

2

Please find my answers:

Will importing the Blueprint for the new child case type generate a new class structure?

[Ramesh] Use Extension with Blueprint to achieve it. This will ensure to new case type to align with he same ECS.

Will that impact the work pool of the parent case type?

[Ramesh] No impact if you’re using Use Extension with Blueprint.

Are there any best practices for generating only the new child case type class structure in this scenario?

3

Thanks for your response and inputs. We will incorporate the incorporate Extension with Blueprint into the steps.

I also wanted to confirm whether the Phase 1 and Phase 2 steps listed above are appropriate, given our current Case type and Application composition, as well as the features that will be available in Pega’26.

4

Hi @Jey2705 ,

In the Phase 2 you can add a step to migrate any Background processing / utilities to your new application RS, before removing the traditionalApp from the built-on stack.