Migration method comparison

To determine the most appropriate migration method for migrating to a newer version of IBM® Business Process Manager, analyze the amount of stateful data in the environment, the amount of downtime your system can support, and whether you want to preserve your previous configuration.

Migration method considerations

There are several different issues to consider when determining the right migration method for migrating to a newer version of IBM Business Process Manager. The following section enumerates a set of items to consider when deciding which method best fits your migration requirements.

Production data
Downtime
Long-running processes and human tasks
Application enhancements
Target environment configuration
Risk mitigation
Selective or phased application migration

Production data

The runtime migration method results in the source production environment being replaced by the target production environment. The implication on application data is that data that was created in the database by the source environment is available to the target environment post migration. This enables important scenarios. For example, processes and human tasks can be started in the source environment and finish in the target environment post migration. Messages in queues and failed events that existed in the source environment can be managed by the target environment post migration. The runtime migration method is the only method that provides this capability. The manual and artifact migration methods both result in a parallel production environment that has its own separate databases configured, completely distinct and independent of the source environment, even when the applications from the source environment are deployed to the target environment.

Downtime

The runtime migration method results in the source environment being replaced by the target environment while the manual and artifact migration processes depend on the creation of a parallel target environment. The implication is that the runtime migration method requires a downtime period when the databases are being upgraded and migrated from the source version to the target version prior to starting the migrated servers. The runtime migration procedures provide a minimal downtime procedure that can be used in some cases, but still does not eliminate the need for downtime.

The manual and artifact migration methods both require a parallel environment to be created that can be used in production concurrently with the source environment. The source and target environments can execute side-by-side until it is appropriate for the source environment to be discontinued. The ability to have two environments running concurrently on different versions also implies a level of operational complexity and likely requires additional capacity.

Long-running processes and human tasks

There are a few different scenarios and options regarding processes and human tasks to consider:

The processes and tasks are short-running and can be completed in the source environment just prior to the start of the migration downtime window
If the migration process can incur downtime and the processes and tasks can be completed before the downtime window, all three of the migration methods are viable options. The decision of which option to use will thus depend on one of the other migration requirements.
The processes and tasks are long-running and the migration can incur downtime
In this scenario all three options are viable but there are important trade-offs to consider. Using the manual and artifact migration methods, the parallel production environments will need to be run concurrently for as long as it takes for the processes that started in the source environment to complete there. If a downtime window is not a gating factor, the runtime migration option is more ideal in this scenario enabling processes and tasks that are started in the source environment to complete in the target environment post migration.
The migration cannot incur any downtime
No downtime rules out the runtime migration method so either the manual or artifact migration method must be used to create a parallel target environment where the applications can be redeployed. Since these methods result in parallel environments that contain two different process and task databases, the new processes and tasks should ideally be started in the target environment, and the two environments must run in parallel until the processes and instances in the source environment have completed.

Application enhancements

The advantage of using artifact migration and the development tools is that the applications can be updated to the newer version artifact level and then be enhanced with features provided in the newer version.

Target environment configuration

If you require the same configuration in your target environment as your source environment, the runtime migration method is typically more appropriate because it will automatically replicate the source environment's topological configuration to the target environment. However, if you need to reconfigure the target environment configuration completely differently than your source environment for one of several good reasons, you must either do that before or after version-to-version migration as an independent exercise, or use either the manual or artifact migration methods if you plan to do it concurrent with the version-to-version migration.

Risk mitigation

The parallel environments provided by the manual and artifact migration methods enable a target production environment that is completely independent of the source environment that is serving the existing consumers enabling the target environment to be rigorously tested before going live in a production setting. In addition, artifact migration can reduce risk by leveraging the development tools to aid in verification that the application being migrated does not contain any issues that would present backwards compatibility challenges. Even in scenarios where migrations are leveraging the runtime or manual migration methods, artifact migration validation using the development tools is often done as an initial stage of the migration effort to validate application compatibility.

Selective or phased application migration

If you have a situation where you do not want to migrate all your applications in a single downtime window to the target version, you should use either the manual or artifact migration approaches. These approaches provide support for two parallel environments, the source and the target, and support selective or phased deployment of the migrated applications to the target environment. In contrast, the runtime migration method migrates all applications from the source environment to the target environment.

Migration method comparison

Use the following table to compare the benefits, costs, and risks of the three migration methods:

Table 1. Version-to-version migration methods: a comparison
Migration method	Benefits	Costs	Risks
Runtime migration	No dependency on the development tools Source environment configuration is replicated in the target environment Source environment applications are migrated to the target environment Source environment application data is moved, using existing database tables Process and human tasks can start in the source environment and complete in the target environment Application instance data on queues and failed events in the source environment can be handled post migration by the target environment Additional hardware and/or software resources not required to manage another production environment	Downtime is required when the target product environment assumes the role of the source production environment Requires all applications on a node to be ready to migrate at the same time New features are not enabled automatically and sometimes unavailable without migrating the application artifacts using artifact migration Parallel production environment cannot be set up Test focus: End-to-end testing to validate migration process Regression testing and performance tuning	A rollback plan must be in place to handle a possible migration failure. For more information, see Rolling back your environment. Existing user applications should continue to execute in the new runtime at the same level of function they had in the old runtime. In some cases, however, there may be a change in code on which the application depends, such as a JDK change, which may have negative impact on the unchanged application.
Manual migration	No dependency on the development tools Target production environment can be configured differently than the source production environment since configuration is not automatically migrated from the source to the target Parallel production environment supported: Selective application migration No downtime Ability to perform extensive testing before migrating to production environment, but usually regression testing is enough No dependency on migration tools	Existing data is not moved; new database tables are created New features are not enabled automatically and sometimes unavailable without migrating the application artifacts using artifact migration Manual (scripted) deployment of applications is required Requires updates to client applications Hardware and software licenses may need to be evaluated for any additional licenses required when running in parallel	Existing user applications should continue to execute in the new runtime at the same level of function they had in the old runtime. In some cases, however, there may be a change in code on which the application depends, such as a JDK change, which may have negative impact on the unchanged application.
Artifact migration	Ability to exploit new features Parallel production environment supported: Selective application migration No downtime Ability to perform extensive testing before migrating to production environment No dependency on migration tools	New development environment is required Existing data is not moved; new database tables are used Manual (scripted) deployment of applications is required Requires updates to client applications Hardware and software licenses may need to be evaluated for any additional licenses required when running in parallel Additional test coverage for application updates is required	Application updates might require some level of testing.