Editor's Note: This is a series devoted to the migrations from the IBM Digital Process Automation eclipse based designer to IBM Digital Process Automation?s Web Process Designer. To start your readiness check register for our questionnaire here: https://info.bp-3.com/webpd/
Not performing in-flight instance migration in IBM Business Process Manager (BPM) when you deploy new snapshots of your Process Applications creates a different, although very similar, problem to that described in my previous article on Dependency Management of Toolkits.
This problem is most likely to manifest itself in one of two circumstances
1. If you discover a problem with an instance in Production for which there is a resolution in a later snapshot
2. If/when you need to migrate your BPM platform to new hardware - possibly as part of an upgrade
There really isn?t much you can do about the first problem above. If you don?t do in-flight instance migrations then you really don?t have any options in this scenario. You can try to migrate in-flight instances, but you really have no idea whether or not it is going to work or not.
Platform migration is very much more difficult in an environment where there are Process Applications that depend on a multiplicity of Toolkit snapshots. Normally a migration is a good opportunity to clean up the Process Center and get rid of a lot of cruft that has accumulated in there over the years. But if you have Process Applications that are importing many different snapshots of Toolkits then you are going to end up re-introducing quite a bit of that cruft. Also, you will almost certainly want those Toolkit snapshots to appear in the ?right? order, i.e. the order in which they were created. You will certainly want the most recent snapshot to be at the tip. Sadly this ordering of Toolkits cannot b,e guaranteed by simply importing the Process Applications. Instead you have to reverse engineer all of the Toolkit Dependencies and manually import all of the required Toolkit snapshots (bottom-up) in the correct order if you are to achieve the view that you want. This process is both time-consuming and error-prone!
To be really effective then you need to be migrating in-flight instances as a matter of course on every Production deployment. This requires more discipline in your coding practices to make sure that code is forwards compatible, and also migration testing as a key part of the overall deployment process. If your testing is manual then this probably seems like - and indeed probably is - a huge burden. But if you have automated testing then this can relatively easily be incorporated into your CI/CD DevOps pipeline.
In fact, automated testing is probably a prerequisite for routine in-flight instance migration. Perhaps that sounds like shooting for the stars, but good DevOps has been demonstrated time and again to, ultimately, lead to better agility and reliability - so maybe the question to ask is whether you can afford not to do it?