Moving from IBM Business Automation Workflow traditional to Cloud Pak for Business Automation

To migrate from a traditional Business Automation Workflow environment to a containerized environment, you must first ensure that your application code uses features that are supported in both environments.

Convert traditional Business Automation Workflow models for a container environment

Use the following guidance to choose your conversion approach:

Convert in the traditional environment when any of the following conditions apply:
  • No container authoring environment is available yet.
  • Migration of inflight process instances is required.
  • You want to prepare projects incrementally as part of the existing lifecycle before moving to containers.
Convert in the container environment when all of the following conditions apply:
  • A container authoring environment is already available.
  • Projects can be moved to the container platform and converted there.
  • Conversion and adoption can progress application by application on the container platform.

You can choose one of the following options to achieve this:

  • Convert in the traditional environment: 
    • In your traditional development environment, change the target environment of your existing projects and all dependent toolkits to Traditional or Container in Process Designer.
      Note: Click Finish editing after switching to the target environment. The project is not fully validated until you do so.
    • Fix all critical validation errors.
    • Any code that uses features that are supported only in the traditional environment must be modified or re-implemented to ensure compatibility with container environment.
    • Create new snapshots once all code changes are complete.
  • Convert in the container environment: 
    • Export your .twx files from the traditional environment and import them into the container development environment.
    • In Process Designer, fix all critical validation errors.
    • Any code that uses features that are supported only in the traditional environment must be modified or re-implemented to ensure compatibility with container environment.
    • Create new snapshots once all code changes are complete.

Moving process instances from a traditional environment to a containerized environment

If the new snapshots remain compatible with the original snapshots running in the traditional production environment, you can move existing active process instances from the traditional production environment to the containerized production environment.

Before starting the instance migration, you must deploy the new snapshots to both the traditional and container environments, then run the instance migration in the traditional environment to move all existing instances to the newly created snapshot. Always test this process in a non-production environment before executing it in production. To move process instances from a traditional environment to a container environment, choose one of the following two options:

Note: If your Business Automation Workflow environment uses the default Content Platform Engine that is embedded with the product, instance migration is not supported. To enable instance migration, you must first configure an external Content Platform Engine.

About this task

Before you move to any Cloud Pak for Business Automation capability, it is important to understand required tasks, available moving options, and your license entitlements. Complete the following steps in the specified sequence.

Image showing the flow: Assess, Prepare, Deploy, Move, Modernize

Tip: Hover over the step name in the list for more details.

Back to top

1. Assessing your readiness

At the start of your transformation, assess your current readiness to adopt Cloud Pak for Business Automation.

About this task

Deploying projects in a container environment can be faster and easier than in a traditional installation. Also, updating software in a container environment can be easier and less disruptive. And you can take advantage of new features to modernize your business automation. Consider the relevant factors before you decide to use containers.

If you have the following requirements, you might want to choose a container deployment environment:
  • Dynamic scalability to adjust to workload
  • Zero downtime support for fixing
  • Ability to not only quickly fix or upgrade, but quickly roll back to previous versions
  • Better resource usage and management
  • Better resiliency for your applications
  • Lower cost for application isolation

Back to top

2. Preparing to move

Moving to containers requires planning and preparation. The transition effort varies depending on your deployment type and how well-maintained your applications are. For Standard deployments, the effort might be minimal if you have kept your applications that are updated and removed deprecated features. First, choose your path. Then, prepare your projects so that they are compatible with the container runtime environment.

Before you begin

Different conversion approaches apply depending on your environment readiness and migration constraints. Choose the approach that fits your situation. Image showing paths to move from Business Automation Workflow and Business Process Manager to IBM Cloud Pak for Business Automation

After you import your projects into IBM Business Automation Studio, critical errors help you identify artifacts that are incompatible with the containerized runtime environment. After you fix these errors, you can continue to work in the authoring environment and when you're ready, deploy your artifacts to the Cloud Pak for Business Automation runtime environment. For more information, see Converting project artifacts.

Tip: If you want to move in phases, keep your authoring environment in the traditional Workflow Center and deploy your projects to the Cloud Pak for Business Automation containerized runtime environment. You can also deploy your container-ready projects to the traditional environment.

About this task

Change the projects that are running in the traditional environment before you move them to the container runtime environment. To prepare your project for a container runtime environment and reduce the incompatibilities and critical validation errors, take the following steps in advance:

Note: For most production migrations, convert projects in the traditional authoring environment before moving them to the container environment. This approach supports phased conversion with lower risk and is required if you plan to move inflight process instances.
  • For process apps and toolkits
    • The target runtime environment for existing process apps, toolkits, and case solutions might be traditional (on-premises). Switch the target environment to a traditional or container before you can install these projects to a workflow server in a container. Consider completing your move in stages. You can convert the target installation environment of your projects (and contained artifacts) to Traditional or Container and continue to run them in the traditional runtime environment. Then, when you're ready, you can switch them over to run in the container environment. When you change the target environment to Traditional or Container, critical validation errors identify artifacts that are incompatible with the container environment. See Converting the target environment of projects External link opens a new window or tab.
    • Replace the deprecated APIs that you used in your applications.
    • Refactor applications to externalize custom Java™ Platform, Enterprise Edition or Java applications as separate services that run in their own container.
    • Redo the server-level configuration if your applications require it, for example, modifying the 100custom.xml file.
    • Reconfigure the SSL of any external service provider if your applications make external calls to any outside service.
  • For case solutions
    • Remove all deprecated features.
    • Remove Case Forms.
    • Ensure that all custom Content Platform Engine event handlers work in Content Platform Engine in a container environment.
    • Ensure that all custom IBM® Content Navigator plug-ins work in IBM Content Navigator in a container environment.

      For detailed steps for the Content Platform Engine and IBM Content Navigator, see Moving from on premises to containers within FileNet® Content Manager environment External link opens a new window or tab.

Change the projects that are running in the traditional environment before you move them to the container runtime environment.

If you decide to back up and restore the runtime database later (for moving inflight process instances), manually transfer everything that is not in the runtime database, including the following customizations:
  • Hostnames: external clients such as REST or WS and end-users use the hostnames of the old environment. Either make sure that the same hostnames are used, or make sure that the external clients can deal with the changed hostname.
  • Customizations to 100Custom.xml. For more information, see The 100Custom.xml file and configuration.
  • All customizations that are in the WebSphere® Common Configuration Model (WCCM):
    • Custom data sources, which are part of Liberty configuration. For more information on customization of data sources, see Configuring custom Liberty data sources.
    • JMS queues. JMS-related settings, such as ConnectionFactory, TOPIC, and Queue, are also part of Liberty configuration. For more information, see Customizing Workflow Process Service Runtime.
    • Authentication aliases.
    • SSL certificates and signer certificates.
    • Customizations to, for example, connection pool size.
    • For web services, no policy sets are there on Liberty. Some of the functions that policy sets offer can be achieved by other means of configuration, such as SSL settings.
    • Custom EAR files.
    • Security properties. For more information, see Configuring security in Business Automation Workflow.
    • Use the exportWASConfig.py script to export customized WebSphere Application Server configuration, including data sources, authentication aliases, and JDBC and JMS providers, from the source environment. For more information, see Migrating the configuration from the source environment External link opens a new window or tab.
    • The BPMConfig -migrate exports the config for migration. It must include all kinds of customizations.
  • More system lane users. For more information, see Adding system lane users in Business Automation Workflow.

After you convert your applications to run in a container environment, you might still have applications that are running in a traditional environment and you might need to support both streams. You can use branches to manage both streams. For example, you can create a branch for your traditional application before you convert your projects and keep the current branch for the application that is running in the container environment. By separating the traditional and container branches, you can make fixes and enhancements to either branch as needed.

Back to top

3. Deploying your projects to the container runtime

Deploy your projects from the traditional Workflow Center to the Cloud Pak for Business Automation containerized runtime environment. Hybrid deployments are supported, allowing the authoring environment to remain on-premises while running projects in the containerized runtime environment.

Before you begin

If not done already, deploy a Cloud Pak for Business Automation environment that includes Business Automation Workflow Runtime.
Important: Use the same time zone settings in Cloud Pak for Business Automation runtime as you had in the traditional environment, for both the workflow server and the database. For setting the time zone in the server, see Setting the time zone in Business Automation Workflow. For changing the time zone in the database, see your database information.
To deploy, choose either of the following options.

Apply to Cloud Pak for Business Automation the customizations you already had in Business Automation Workflow, as described in the previous step Preparing to move.

Procedure

  1. Set up the connection between the traditional Workflow Center and the Workflow Server in Cloud Pak for Business Automation. See Customizing the container runtime environment Workflow Server to connect to Workflow Center.
  2. Make sure that your projects are compatible with the container runtime environment. For more information, see Preparing to move.
  3. Change the target environment of your projects to the Traditional or Container environment. For more information, see Converting the target environment of projects External link opens a new window or tab.
  4. If you are not planning to move process instances to the container environment, you can install snapshots from Workflow Center to Cloud Pak for Business Automation.
  5. To move process instances (including inflight instances) to the container environment so they can be completed there, you must do the following steps:
    1. Create Traditional or Container snapshots for all projects .
    2. Deploy those snapshots in your traditional environment.
    3. In your traditional environment, migrate all process instances to the Traditional or Container snapshots.
      See Snapshot and process instance migration External link opens a new window or tab.

4. Moving the development of your projects

Move the development of your projects to Cloud Pak for Business Automation by importing them from Business Automation Workflow and importing them into IBM Business Automation Studio.

About this task

Your projects must be compatible with the Cloud Pak for Business Automation container runtime environment where you deploy them. Prepare projects first in the traditional Process Designer, or import your process apps and case solutions into IBM Business Automation Studio, fix critical errors and continue to develop them in Workflow Designer.

Important: Import the toolkits first and then the process applications. To preserve the toolkit versioning order from your current Workflow Center, import them in the correct order. The last imported toolkit is the tip in the new Business Automation Studio.
Importing a project that you exported from the traditional Process Designer can cause errors. Modify your projects to enable your project to be installed and run in the Cloud Pak for Business Automation environment. You can do the conversion in either of the following places:
  • In Cloud Pak for Business Automation, by exporting the project from the traditional Process Designer and importing the project into Business Automation Studio. When you open the project, you can convert, manually fix, or delete artifacts in the Project Conversion tab. For more information, see Converting project artifacts.
  • In the traditional Process Designer before you export the project and import it into Cloud Pak for Business Automation. For more information, see Converting the target environment of projects External link opens a new window or tab.
Note: If you import unconverted projects into the container authoring environment, you must complete conversion before the projects can be played back or deployed.

Procedure

To move your development projects, complete the following steps.

  1. Deploy Workflow Authoring in Cloud Pak for Business Automation.
    To deploy, choose either of the following options:
  2. Export each project as a TWX file from the traditional Workflow Center.
  3. Import the TWX file into Business Automation Studio.
    See Importing projects.
    Important: Import the toolkits first and then the process applications. To preserve the toolkit versioning order from your current Workflow Center, import them in the correct order. The last imported toolkit is the tip in Business Automation Studio.

What to do next

Now, you can continue to develop and test your projects in Process Designer and install them to the Cloud Pak for Business Automation workflow server.

Back to top

5. Modernizing your workflows

After you move to the Cloud Pak for Business Automation, you can start taking advantage of the capabilities.

About this task

You have access to all the Cloud Pak for Business Automation components, including the following foundation components:
  • Process and task mining
  • Robotic Process Automation
  • Kafka event framework
  • Identity and access management
  • Logging
  • Metering services
For more information, see Cloud Pak foundational services.
By moving to Workflow Authoring, you have access to the low-code designers that are integrated with Business Automation Studio. Using Business Automation Studio as a single place to design business automation, you can take advantage of the following capabilities:
  • Author your workflows in a containerized environment.
  • Publish your workflows as reusable automation services and easily call other automation services from your workflows.
  • Build low-code user interfaces that integrate tasks, data, and automations.
  • Use decision services to capture and automate repeatable decisions.
  • Use document processing to combine your business knowledge with powerful machine learning to process and store documents and unlock the data they contain.

You can increase productivity by using IBM Automation® Workstream Services for a no-code solution to streamline, automate, and accelerate activities in your daily work.

Through the IBM Cloud Pak® for automation framework, you can seamlessly access services from other Cloud Paks.

Back to top