Fist of all, using a workflow engine makes it easier to quickly develop process oriented applications. It does not necessarily make it easier to migrate.
If you search the forums in a little detail, you will see that it is not impossible to migrate running instances, but that it is not something that is supported by the jBPM community. Small changes are not that difficult but require db manipulation. Just have a look at how the db structure is and it will become fairly obvious. It mainly boils down to changing foreignkeys.
It surprises me you frequently have the need to add/change transitions etc... feels like a very 'ad-hoc' process. If business processes change that often, there is a more substantial underlying problem imo.
It seems to me that not having tools to migrate running processes is a serious flaw. As for having to change our process --- that's really not a relevant remark. We have a very complex business process and it has been three years since DonorsChoose first chose jBPM. Throughout that period of course the business process has evolved. It doesn't change constantly, but it does change, and so far we've simply avoided even touching the jBPM graph because we haven't been able to migrate running processes. (When I say "we" I mean the team prior to my joining --- I'm hoping to rectify this).
I did a quick search for "migrate running processes" and didn't find any guide to this process --- one of our engineers attempted to modify the DB in place but didn't find an easy way to do this. If anyone could point to documentation of the DB schema or a forum topic where someone discusses this, that would be most appreciated.
Check if this will help for now:
You can start from here and then see how it goes, but again this is not for the faint hearted.
Having said that, it is not impossible, and totally depends on what kind of process you have.
I have done simple test simulations where. data is converted using a driver program that put in very simple words, 're-runs' the process.
Now this and portions of this might or might not be feasible in your case.
But again, with the database structure being a lot more formal in the v3, you can attempt to repoint the tokens and make other changes. I have not done that personally at that level, so cannot comment on that approach, but, as Ronald mentioned, given enough understanding of the database, and your process being conducive, who knows, it might actually be possible.
Regarding your comment about not having tools to migrate running processes, it is not a very straightforward problem to solve, especially something that can be branded as a 'tool' as ultimately most approaches have to be customized.
Let us know what you find,
Well before I read your post I managed to find this:
So it appears Caleb Powell's team has come up with a tool they're using internally. That's precisely the sort of tool we would need. Without this, our workflows are stuck 3 years out of date and getting worse.
I left a note on his blog encouraging them to release the code. Perhaps if you guys prodded them as well we might be able to get that code open sourced. Even if the tool set is limited and/or semi-manual it would be a huge improvement over the current system of having no way of migrating running process instances at all.
contact has already been made and they seem to be willing. But if you read a little more, you'd see that there also is a migration command in 3.2 by Bernd Ruckner/Camunda. That can be a start as well.