I am working on migrating an application from 6.2 to 7.1.7 and need to map the flows in 6.2 to cases & stages in 7.1.7. How can I migrate my flows to cases and stages and also show process outline at the same time?
Thanks in advance.
**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.
Yes, there is no OOTB way to directly convert your existing flows to Stage-based Case processing in Pega7. These are different ways to design your Case processing. You need to re-think your existing processes and come up with various stages the Case has to flow through - define these stages and after that, you can leverage existing flow rules where applicable.
Posted: 6 years ago
Updated: 6 years ago
Posted: 19 Feb 2016 7:33 EST Updated: 19 Feb 2016 7:37 EST
Vigneshwaran Aravindhan (VigneshAravindhan)
Case type rule was available since V6.1 and I am not sure if it has been leveraged in your 6.2 application. If you already have case types in the 6.2 App then it helps to some extent.
Its possible to create new case types and gradually enable stages and steps for your V7 application over time however this is not practical in most cases; this requires a lot of attention to details. For example in Pega7 raising a ticket will help you jump within a step and thats all; you cannot jump between steps OR jump from a stage to another stage. So if you have leveraged tickets in your 6.2 App then you would have to think about how to configure the same in V7.
Also while making changes to your V6 flows to fit the stages/steps that were created in V7; think of the work objects in production. The following points were found in Pega Academy - LSA7 Course; you would have to either tackle or bypass these challenges.
Removing an Assignment shape for which there are open assignments results in orphaned assignments.
Replacing an Assignment shape with a new one with the same name may cause a problem since flow processing relies on an internal name for each shape.
Removing or replacing other wait points in the flow such as Subprocess and Split-For-Each shapes may cause problems since their shape IDs are referenced in active subflows.