Choosing a migration approach

Before you migrate your systems, you can choose to migrate artifacts only or you can choose to migrate artifacts in your test and development environments and then migrate business data and applications in your staging and production environments. The approach you choose depends on the production downtime that the business can tolerate.

Migrating artifacts only

Use this approach in the following cases:

You can keep two systems running in parallel until all existing processes have completed.
You are changing database vendors, or you want to update your IBM® BPM Express applications to use a new IBM BPM Advanced or Standard installation.
You do not have long-running process instances and human tasks, or you can run parallel production environments while you drain the process instances and human tasks in the source environment as new instances are started in the target production environment.
Your business cannot tolerate a production environment downtime window to perform the migration.

To migrate artifacts, you create a parallel target production environment that is configured from scratch differently from the source production environment. After you have migrated the artifacts, you can modify your applications to use the new capabilities that the new version of IBM Business Process Manager contains. You can then test and deploy the applications to the parallel target production environment. When the applications are deployed to the target production environment, a new set of database tables are created, so the applications do not have access to the application data that is stored in the databases that are configured for the source production environment.

There are two approaches that you can use when migrating artifacts: the drain approach or the milestone-transfer (restaging) approach.

With the drain approach, you migrate artifacts to the new system and let the existing process instances in the old system run to completion. This process is called the drain approach because the existing process instances are drained from the old system. Then you start all new instances in the new system.
With the milestone-transfer approach, you transfer the process instance state midstream. You let the existing process instances in the old system run to a designated set of business milestones and then start new instances in the new system from those milestones. This approach is not supported by the system and requires custom coding to perform the transfer.

Migrating artifacts and then migrating business data and applications

Use this approach in the following cases:

You have long-running process or human task instances that started in the source environment and must complete in the target environment.
You have product data in queues that were created in the source environment and this data must survive the migration and be managed in the target production environment.
You want to move your applications to the target version without a dependency on the development tools and the development environment.
Your business can tolerate a production environment downtime window to perform the migration.

When you migrate artifacts and then migrate business data and applications, you migrate the artifacts in your development and test environments and then you migrate the business data and applications in your staging and production environments. To migrate business data and applications, you export the configuration information from your current environment (the source), modify it for your new environment, and transfer the modified configuration information into your new environment (the target). Then you point to your databases from your new environment and update the databases. Alternatively, you can clone your databases and use the cloned databases to test the migration before you migrate your production environment. When all applications are working in the new system, you convert the databases to make them compatible with the new system. For a procedure to follow, see Migrating artifacts and then business data and applications.

This approach works on one deployment environment at a time. If your environment contains multiple deployment environments, consider the relationships within your topology so that you can map them properly in the target environment.

Summary of the benefits and drawbacks

The following table compares the approaches.

Table 1. Table of benefits and drawbacks
Approach	Benefits	Drawbacks
Migrating artifacts (drain approach)	You can migrate one application at a time to the new system No system downtime is required You can change database vendors You can update your IBM BPM Express applications to use a new IBM BPM Advanced or Standard installation	Historical information is not moved to the new system You must keep two systems running in parallel until all existing processes have completed You must have a separate Process Portal for the users of the two systems, or use a custom federated portal
Migrating artifacts (milestone transfer approach)	You can migrate one application at a time to the new system No system downtime is required You can change database vendors You can update your IBM BPM Express applications to use a new IBM BPM Advanced or Standard installation Depending on how you set up the milestones, the time it takes to migrate all instances can be much shorter than with the drain approach	Historical information is not moved to the new system You must keep two systems running in parallel until all existing processes have transferred You must have a separate Process Portal for the users of the two systems until all process instances have reached their designated milestones, or use a custom federated portal Custom development of the transfer process is required and might be complicated depending on the existing process design and where records are stored
Migrating artifacts and then migrating business data and applications	All historical information is preserved	This approach has more steps to perform System downtime is required (24-48 hours or more depending on the size of the database) All applications must be migrated at the same time