...

For each situation, you have to determine what to do and if a migration is needed. For some changes (for example additions to the model), it might not be necessary to actively migrate cases.

Case Migration

When your changes have been set, you could end up with either a migration flow (actively migrating data) or an empty migration flow to just update and recalculate all data based on the same data + new model. One way of triggering a migration, is to use a message event and an automatic task. The message event triggers the migration, the automatic task processes any changes and makes sure the newly derived case state is mapped back to the process profile. Any newly created tasks will become active after the process evaluation.

In the DCM Foundation there is a model pattern to do this migration. There is a migration version number added to the metadata. This way you can monitor which case is migrated to which version of the model. There is a migration endpoint triggering the migration automatic task. The task consists of "doing the migration steps" (can be empty when there is no data migration needed), and setting the migration version to the latest number after the flow. This way you could create a case-list, and check the cases that still need migration. The easiest way of migrating all cases is by throwing a message event to all cases.

A different approach could be to lazy migrate each case. So when a task is started, check whether migrations are necessary, and perform the migration steps. However, this means that you possibly need to keep older model patterns (for example legacy attributes) in your latest Blueriq case model for a longer time. The migration strategy could of course also be a combination of active and lazy migrations.