5 biggest mistakes when migrating a process from Metastorm BPM 7.x to 9.x

For many of our customers the migration of their processes to Metastorm BPM 9.x is one of the most important tasks this year. Some of our customers have already successfully migrated their processes from e-work to Metastorm 7.x in the past and now they have to do it all over again to Metastorm BPM 9.x.

In the following blog post I share the 5 biggest failures which have been made in previous migration projects so you can avoid making them yourself.

1. Starting without planning
At the first glance it seems too easy to migrate a process from Metastorm BPM 7.x to Metastorm BPM 9.x. With version 9.x have the Metastorm BPM Migration tool available which offers an easy to use wizard and does it all for you. Simply select your XEL or XEP files and at the end you have a ready to go solution package for Metastorm BPM 9.x. In a perfect world you can click Deploy and you can do a test drive with your process within minutes.

But don't get too excited. That is all fine for the simple processes where all elements are contained within one procedure. As soon you have integrations, external tables, javascript code, little hacks to make things work your way than the Metastorm BPM way, libraries, DLLs, you quite certainly face challenges.

2. Concentrating efforts on UI customisations too early
A major concern when migrating a process is the UI. Will it behave in the same way? How will the user accepting the new look and feel. How it feature xyz working. Is it working at all. Will we face huge problems at UAT?

My advise here is: Don't concentrate on the UI with the highest priority. The main focus should be on pure process functionality only. Are forms generally working the standard way? Are all JScript.Net code blocks still working? How about the server side VBS scripts in your solution? All those things should work first before you start tweaking the UI for the new version.

3. Fixing broken legacy code
One big challenge is old legacy code. During the migration process the code you had in your "Do This" tab will be transformed in one big string, so readability is down the drain and using the old wizard to go through the code wouldn't work either. You would need to fix the old code manually and you might can image how painful that could be. One rule of thumb: when you need to fix one area of code once, very likely you need to do is twice or three times, If you have the time to rewrite the old server side script blocks to the new supported language C#, then you would do yourself a favour when it comes to urgent bug fixes after you went live.

4. Starting too complex
Before you start with your biggest and most complex business process to migrate pick a test run process instead. That way you get more familiar with the tools available, how the migration tool works in detail and the approaches to take for a successful migration. It will be an agile and experimental way before you are ready for the big migration processes. Build your confidence first.

5. Forgetting to plan ahead
Just because the code might work after your migration you might to consider to prepare yourself for the future. JScript.Net and server side vbscript are not supported anymore and should gradually be replaced in all processes and libraries. It is good practice to replace all occurrences of the Evaluate Method which contains all the old Do This code long term. It will make your life far easier.

I hope you can take some useful information away. As always we would like hear your thoughts on this.

Any questions regarding this please feel free to contact us directly.

P.S. On all the big migration projects we worked on in the last couple of years the migration took nearly half as long as the first implementation on the Metastorm BPM 7.x version. Just a rough estimate.

P.P.S. Book your free 1-2-1 online session to discuss your migration needs today!