Since Activiti went GA on December 1st last year, we've been getting a lot of requests from people that want to migrate from jBPM to Activiti. [piece removed, see (*) in the comments]
When we started Activiti, we didn't plan any of those migrations as that would take a big chunk of our development resources. Converting jBPM's jPDL process xml files is only one piece of the puzzle. Migrating the runtime database data to a newer version of jBPM or to Activiti is the biggest challenge.
But Activiti progress has been faster then expected due to the overwhelming contributions by the community. Those were far beyond our expectations and hence we've been able to execute our roadmap faster then expected. As a result of our good progress and the demand expressed by our community, we are now able to revisit the choice of building migration from jBPM to Activiti.
When we started Activiti, we didn't plan any of those migrations as that would take a big chunk of our development resources. Converting jBPM's jPDL process xml files is only one piece of the puzzle. Migrating the runtime database data to a newer version of jBPM or to Activiti is the biggest challenge.
But Activiti progress has been faster then expected due to the overwhelming contributions by the community. Those were far beyond our expectations and hence we've been able to execute our roadmap faster then expected. As a result of our good progress and the demand expressed by our community, we are now able to revisit the choice of building migration from jBPM to Activiti.
This iteration, we'll start building jBPM 3 to Activiti migration in the community project including runtime database, history database and process definition migration. In the Activiti 5.2 release, planned for February 1st --less then 3 weeks from now--, you can expect the first drop of migration functionality. Though it will be hard to achieve 100% coverage, we hope that in subsequent releases of the migration, we'll be able to convert most jBPM 3 installations automatically. And for those aspects that we can't cover in a generic way, we'll provide good reports and hooks so that developers can customize the migration to deal with their specific situation.
Tom, it seems that it is incorrect of you to state that there will be no migration path from jBPM 3 or jBPM 4 to jBPM 5. I've spoken with the jBPM team and they have told me that it's planned. Are you saying they are wrong? Wouldn't they know?
ReplyDeletePeter,
ReplyDeleteThe last I've heard was that it wasn't planned. If you've heard it from the jBPM team, then I'll update that part right away.
It's correct to say there's no path planned from 3->4->5 but misleading to ignore that there is a path planned from 3->5 http://community.jboss.org/wiki/jBPM5migrationtoolproject
ReplyDelete(*) Originally the removed piece stated that there is no migration from jBPM 3 to jBPM 4, nor from jBPM 4 to jBPM 5
ReplyDeletePeter and Brent pointed out that there is a jBPM 5 migration project. Despite that the migration page doesn't mention anything about runtime database migration aspect, I agree that because I don't have any insight into the further plans of the jBPM team, it is indeed more appropriate for me not to put that statement up there.
As a quick addition, since migration is seldom a one step project, I blogged some thoughts on a smooth migratin path in a couple of steps here: http://www.bpm-guide.de/2010/12/24/using-bpmn-2-0-models-with-jbpm-3-a-migration-path-and-more/. No some migration tool, more an approach and some tooling support, but working in big real life projects :-)
ReplyDelete