BPM Platform Migration
We often have to migrate systems to different platforms. There are many different reasons. The migration paths are not always automatic, and often not at all simple.
In the past few years, Business Process Management Systems (BPMS) have become very common, especially in large organisations where the cost benefits can be huge. One problem being faced now is what to do when you need to migrate these processes to different systems.
Because most of these systems have quite different approaches to managing processes, especially at the presentation (user interface) layer, the answer is by no means simple, nor obvious. The approach we have found to work in all situations is to start by documenting the processes.
This may seem obvious, but what we have found is that almost no BPM systems are documented. The BPMS itself is designed to provide an adequate level of documentation, the theory goes. In practice, it does not even come close. The result is an almost complete lack of documentation. This makes the systems very complex and risky to maintain as they are, and especially to migrate.
A further problem when migrating is that in order to do this effectively, the migrators need to be sufficiently conversant in both the source and target technologies. While one expert may have some knowledge of another BPM system, it is rare to find several in one team. This causes at best, a single point of failure. At worst, it requires two completely separate teams, and all the communication overhead and risk of miscommunication that typically presents.
Finally, the resulting changes to the systems as used by your staff need to be fully communicated to those staff. The impacts need to be assessed, and training sessions need to be planned. All of this is incredibly difficult to discover and manage when the system lacks proper documentation. Fortunately, once it is documented properly, it is actually a very simple task to manage.
The solution we have seen work best in these situations is to document the original system as thoroughly as possible. This documentation should be primarily targeted around processes, given that this is a BPM system being migrated. It should also be well able to manage data design, full role designation, preferably the full RACI matrix, and business rules. It is difficult to define form design between different BPMS because of the very different approaches to implementation, but at least the types of fields and the required functionality should be represented.
More than anything else, the greatest additional benefit from this documentation is that is allows the business owners of these processes to understand their scope, and the migration process itself. Without this transparency, the results are almost impossible to gauge until the project is complete.
In our own documentation system (Business Optix Trial Download) we also have the ability to add test cases (each linked to components), complete change management documentation (including change requirements and before & after processes), and user instructions to allow the generation of user documentation. Although these are additional, we have found them invaluable for any type of system documentation, especially migrations.