BPM, Workflow, and Case

“I have a process application initially developed in BPM 8.0 and need to get it to a supported product version without changing anything.”

“I’m on BAW 19.0.0.3 but have process applications that still use heritage human services and heritage coaches.”

“I need to move my entire environment including running process instances to new servers or a new datacentre. “

Migration/upgrade situations are as diverse as ice cream flavours – which does not make it easy to choose the right ingredients. You might also want more than one flavour, but is chocolate and mango really a good combination?

1 Know the terms

Whether you are migrating or upgrading makes a big difference. For many people these terms are interchangeable. Here’s how IBM defines the terms:

You are migrating when you make a new installation or come from a BPM version earlier than 8.5.0. This includes moving to new hardware (whilst staying on the same version) or moving from a traditional installation to a container deployment.
Migration can comprise two things: The process application code, which can be migrated to a new environment, and the business data, including in-flight and historical process instances as well as the applications – in other words the process database.

You are upgrading when you stay on an existing installation with an existing process database, which is the case when coming from all BPM versions since 8.5.0.

Check the IBM Documentation for more details about the different scenarios, especially when moving between Express and Enterprise editions.

https://www.ibm.com/docs/en/baw/20.x?topic=workflow-migrating-upgrading

You want to move from BAW 18.0.0.1 to BAW 20.0.0.2 and switch to a new machine? Then you probably do both, upgrade and migrate, but it may depend on what your objective is. Keep reading, goal setting is coming up next…

2 Know what you want to do

Since migration can be so many things, it is important to have a clear idea about what you want to achieve. Here are some guideline questions that can help you draw your scenario.

• Do you need to keep historical and inflight data?
  In other words, do you need to keep the same database?
• What version are you currently on, and what is your target version?
  Remember that if you are currently on BPM 8.5.0 or a newer version, you can (only) do in-place upgrades towards BAW.
• What platform are you currently on, and what is your target platform?
  If you want to stay on the same type of platform and on the same machines, you can do an in-place upgrade. If you need to change VMs (for example to get around an OS upgrade), then you will at least need to do a “migration to new hardware” (which reuses the existing DB). And If you want to move from on-premise installations to a container-based deployment or to IBM’s SaaS offering, you’ll need to migrate the projects to the new platform, leaving historical and in-flight data behind.
• Do you just want to maintain your applications as-is or are they evolving?
  If your applications are actively evolving you might want to consider adopting the latest features as you go. This means converting old processes and services into the new artefacts and redesigning your coaches using the latest UI toolkit. If you have historical applications that only need to continue to run without any changes, then you may leave them as-is (provided that you don’t use any removed features in your application).
• Do you want or need to change anything else, like your DB vendor, OS, backend systems, infrastructure provider, datacentre?
  All depends on your context. Obviously, you do not only have a BPM/BAW environment, but many other systems. Sometimes the BPM/BAW migration is just a small part of a bigger change in your enterprise’s application landscape. You’ll need a detailed assessment of your scenario. But try not to overcomplicate things… check the next chapter!

3 Stay focused

BPM/BAW systems often are at the heart of your enterprise, integrating different systems and bringing the right business tasks to the people in charge. So, by nature things can get quite complex.

Try to stay focused on your goals (set in chapter 2) and don’t mix too many things if you don’t have to. Are there things that can happen one after the other? Often you don’t have to do everything at once. Start with your paperwork (licences), then do your infrastructure and finally look at the application code. It’s tempting to redesign your entire process including the coaches when you start assessing if you have any legacy code that might break on the newest product version. But hold on – is optimising some code that currently works fine worth breaking your upgrade to the newest product version and risk the acceptance by the business users? Often the answer is no. Unless of course you plan to redesign the application anyways. Then leaving the old one behind and starting on a blanc page on your new environment might be a good idea.

4 Get help from the experts

No matter if this is your first or fifth BPM/BAW upgrade and if you already have a clear view of what you want and need to do or not – It is always a good idea to ask the experts! So do check with IBM Expert Labs who offer a range of services around migration. They’ll help you work on your migration strategy, prevent technical pitfalls, and have the deep product knowledge to conduct the technical work on your environments if you like. So reach out to your IBM representative and ask for a BAW modernisation workshop.