In Business Automation Workflow, instance migration is one of those topics that tends to be a challenge. It requires to be considered from the beginning and managed throughout the lifecycle of the project. The aim of this blog is to discuss useful development patterns than can avoid issues with instance migration.

In a typical project lifecycle, a new release is developed and launched with the aim to reach the 'Business As Usual' mode. This is the mode when users mainly focus on evolving the process, adding new features and fixing defects with the business process. The snow ball tends to start building up when the development start without recognizing the current state of the process in production. As the changes are implemented the process keeps moving into a challenging territory with instance migration. 

When the process is ready for deployment, this is the typical point where the teams start to realize the challenge with the instance migration and the state of the process in the production environment. They tend of be faced with 3 options where the easiest one is keeping the instances on the older snapshots. 

Though it sounds like the easy option but in reality, it is only saving the complexity till later. A lot of snapshots can have an impact on the performance and maintainability of the platform. My approach is always try to migrate the instances if possible to avoid the situation where I have multiple snapshots running at the same time.

Key benefits from updating the snapshots:

• Less snapshots, better performance
• Users can benefit from the updates to the latest business logic
• There is a better chance to migrate the instance at deployment time than few snapshots later when the code has diverged significantly

Though the benefits outweigh the risks, ensuring that the process instances can be always updated is not an easy task. There are few patterns than can be challenging to handle. I am listing below some of the scenarios and development patterns to resolve those issues.

Below are some of the scenarios that can pose a challenge to instance migration and possible ways to manage them:

• A significant change to the flow of the process has occurred.
• Parallel paths are used, and changes happens to one of the paths including removing or adding an entire path.
• Moving a task to a totally different location in the process which would affect the overall logic of the process.

A significant change to the process flow:

The problem occurs usually when a task is no longer needed or a new path need to be implemented. I usually find those scenarios occur at the beginning of a project while the business teams are agreeing the stable form of the process. It is definitely less to see this in an established process. 

When a task is removed during development and the administration team is deploying a new snapshot, they will be faced with a choice as to what to do with the tokens that are at the deleted tasks. This can be a challenging situation to decide, specially that we might want those users to benefit from the new updates in the process. 

One way to handle this situation is by creating the 'Deprecated Task' pattern. The example below takes a simple process of one task and shows the 'Deprecated Task' pattern when a new task/path is added to the process.

The initial process

The approach is to keep the current task and marking it clearly that it is a deprecated task while removing all the lines connecting to it. This would ensure that no new instances will go through that path. Then develop the new path or add the new tasks you are looking to add like the example below.

In this scenario, the instance migration scenario was avoided all together. The new instances will go through the new flow, while the old instances will move from the current task and use the new flow.

In future blogs, I will discuss the other patterns.