Why You Need to Talk to BP3 about Migrating to IBM BPM v8 by

We’ve been noticing a disturbing trend of late among BPM customers migrating from Teamworks 6 (or similar) to IBM BPM v8.  There seems to be a trend that customers are migrating their models but attempting to avoid migrating runtime data.

BP3 is the go-to team for migration.  We only know of one customer that has migrated live production instances from Teamworks to IBM BPM without BP3’s help (there may be more).  In that context, hearing that some customers are giving up on migrating run-time data rather than seeking out help from BP3 is breaking my heart.

If you’re migrating to IBM BPM v8 and you want to migrate process instances from Lombardi Teamworks, you need to get our team on the job. 

Now, let me explain why…

What does migrating Runtime Data mean?

Migrating runtime data means that you have running processes (e.g. Loan applications) running on Teamworks version 6, for example.  You would like the actively running processes to continue running on the new version of software – in this case, its successor, IBM BPM v8.  You also want to bring over all of your historical instance and tracking data into your IBM BPM installation.  This includes all closed instance and tasks as well as any supporting data like users, groups, etc.

Why is this hard?

Moving solutions from Teamworks to IBM BPM can require the refactoring of  parts of the solution.  While IBM provides an analysis tool that will call out the various items that should be addressed, the output provides little explanation of the underlying issues or insight into the importance of each item.  Additionally there is no model for providing a way to determine the level of effort required to perform these changes.  

And this only addresses the solution code.  If you want to perform runtime data migration your approach to the necessary work needs to be done in a manner that ensures the resulting solution is one that will allow for proper migration of the data.  This takes planning.  Even if you do each of these things right, if you have long running processes, changes that you made to them in the Teamworks application may cause the standard data migration tools to fail.  

Make no mistake, the first time you do this it is hard.  And the number of people who have seen and understand these problems in the real world is very small.

But there is good news.  First, you, as a customer, will only ever need to undergo this process once.  Second, and better news: our team has done it several times, and has created the tooling to help you work around these various problems and achieve success with significantly fewer headaches.

So Why Are Some Customers Hesitant?

Despite the tooling and support available, customers with very robust process solutions have delayed this migration because of the size of the effort, or because of the fear of migrating runtime data. They’re worried about business risk to this data so they’ve taken approaches to mitigate that risk.  At BP3, we understand that. But we’ve always felt like that wasn’t good enough for our heritage Lombardi customers, and so we also invested in making migrating run-time data more reasonable.

So Why Are Some Consultants Hesitant?

Most consultants familiar with IBM BPM were never familiar with Lombardi versions prior to the acquisition, and so they’re not comfortable advising customers on migrating run-time data.  They may not even be comfortable migrating process models as they don’t understand the old process modeling paradigm.

But BP3 has the most experienced team of BPM consultants on the planet.  We have more Lombardi alumni consultants on our team than any other firm in the world.  We have more consultants with Lombardi Teamworks experience than any other firm.  And our median experience *also* exceeds every other firm.  We are not afraid to advise our clients on runtime migration, and we are not afraid to make it work ourselves.  And we’ve done so.  On real world customer process models and databases, not just on fake test-lab models.

We have the know-how.  We have the intellect. We have the resources.  And in our BP Labs group we finally decided we were going to solve this problem along with our customers.  We invested in the components:

  1. First, to make sure we have a detailed assessment of the assets to be migrated.  We built the most sophisticated model-analysis tooling and know-how in the industry.  Some people have scoffed that you can’t automate this stuff, but we have proven that you actually must automate the information gathering in order to inform the expert inspection of a model.  Our tooling assists with complexity analysis, trouble-spot analysis, and best-practices adherence.  You can’t rely on manual inspection for the amount of data and detail involved on large and complicated models.
  2. Next, we built out instance migration tooling.  Mind you, IBM ships an instance mapping tool that is essential to this process. But we’ve built tooling to help us debug the inevitable edge cases that the instance mapper hasn’t seen before, and to help us figure out how to fix those edge cases so that the instance mapper can do its job.  This is more advanced than what IBM ships out of the box, but we learned from their approach and improved upon it.
  3. We make use of our testbed environments to iterate over migration trouble spots until we have removed all the ones that we can find.  This is where BP Deploy enhances our own productivity by allowing us to set up and tear down installations very quickly.
  4. We use our expertise and tooling (combination of the two) to trouble shoot any errors more efficiently than anyone else would.
  5. We turn over the results to our customers to test in their own environment and help them defuse any issues that come up after that.
  6. This is what we do, this is who we are.  We will roll up our sleeves and do everything we can to ensure your runtime data migrates successfully.  We are not content to point to problems with the standard tooling and ask you to file issues with IBM support.  We will explain each issue we encounter.  We will tell you the options for working through the issue.  We will explain how we have addressed these for other customers, and we will help you find the right answers.  If needed we will create tooling to make this easier both for you and for the next customer we work with.  We cannot guarantee your success, but we will do everything in our power to make you successful.  This attitude is part of our DNA.

Call to action

If you’ve recently given up on migration, or been advised to, contact us.  Let us do an assessment.  If you’re coming to Impact, come talk to us at our booth.  We’ll get you squared away.  There’s no excuse to lose the value of your running processes, and the promise of BPM.