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!

5 Reasons to start your Metastorm BPM 9 migration project today

Metastorm BPM 7.x projects are still coming our way these days although Metastorm BPM 9 has been launched a while back in 2009. Metastorm BPM 9.x has changed a lot since then and migrating a Metastorm BPM process from version 7.x to version 9.x can be a long project, there maintaining large scale processes seem to be much easier for many companies than moving to the next version.

So, why should you start thinking of migrating your existing processes instead of maintaining the very well running e-work or Metastorm BPM 7.x processes?

In our oppinion the following are 5 strong reasons why you should start as soon as possible.

Software Vendor Maintenance

As an Opentext customer using Metastorm BPM (or Opentext MBPM) you are paying annually for your maintenance. This includes software support, new software versions and the use of the Metastorm Community. But there is one problem. Every version has a specific end of life date. Once the software support has offically discontinued you might be in a risky situation when your IT infrastructure changes and e.g. new database systems are not supported with the version you are running. This is just one example of many problems which can occur. It can be absolutely fine for you and nothing goes wrong. But do you like to put your business at risk based on hope? if you want to pay for extra support.

Metastorm BPM Training

Opentext, as most software vendors, os offering training courses for their products. But in most cases only on the latest versions and technologies are on the course program. If you are still running Metastorm BPM in an older version and need resources to deliver the project, you can not get them trained on the old version anymore. You would rely on existing staff to pass on the knowledge or need to bring in external consultants who might have this knowledge.

Metastorm BPM Consultants

The longer the new version is available it is more likely that you struggle to find BPM consultants who can deliver services for all your Metastorm BPM or e-work versions. The earlier your start migrating your processes to the new version the better are your chances to get help when you need it most.

New version, new features

With the new version of Metastorm BPM 9.x you can use some great new features to design your processes and to improve the user experience. Reporting is an important element of BPM  projects and now you can use the built in Report Designer instead of building reports with e.g. SQL Server Reporting Services. The social component in Metastorm BPM makes it possible to chat with other process user when they are online. And of course, many many more.

Enable your processes for the mobile world

Since the Metastorm BPM 9.1 release you can use the new Metastorm BPM Mobile Client. With the mobile client you can easily allow your mobile workforce to interact with the available processes using e.g. iPhone, iPad, Blackberry or Android smartphone. As the client is based on HTML5 it will basically work in any HTML5 browser in the same way.