"thomas.diesler(a)jboss.com" wrote : This is based on my understanding that a process definition is an immutable entity, which is defined in XML. | process definitions can be considered as immutable, correct. "thomas.diesler(a)jboss.com" wrote : | The state of running processes is persisted in the database. For many a reason It cannot be expected that jBPM can be updated for running proccess. there are two types of migration 1) migrating a process instance to a new process definition in the same jBPM installation 2) migrating the complete jBPM database to a new major version (3.x to 4) In the general case, process instance migration is too complex, as you don't know to what extend the new process definition will look like the old one. However, in the majority of use cases, the updates to the process are fairly limited. If we provide a process instance migration that takes into account an optional node-name-mapping, then I think we have covered the 80% of the migrations with 20% of the effort. Migrating the runtime state is doable IMO. The logs and history is always too complex. What I think we definitely should consider is process instance migration from 3.x to 4. Our users *will* have to do this. With our without our help. This is the feedback that we got at jBPM community day. I think that should be definitely feasible with serialization to XML. After the clean shutdown, we should be able to provide a tool that serializes a the complete process instance information to XML and load that XML file in the new DB. IMO, this is mostly a question of resources. "thomas.diesler(a)jboss.com" wrote : If this feature is required we need to see this reflected in the test suite. In other words, as long as there are no automated tests that verify that an update of jBPM from version X to version Y for a non trivial set of running processes - this feature is not there. agreed. "thomas.diesler(a)jboss.com" wrote : | | ProcessEngine.prepareForShutdown() | | | | This will allow processes to terminate, while others cannot start. A user is expected to setup a new instance of jBPM version Y that can receive new process requests. i don't think this is realistic for the complete process instances. think of the legal case taking 3 years to complete and new legislation requiring updates to the process in the meantime. we need some form of process instance migration for that. but a clean shutdown could make sure that all asynchronous messages get processed before the shutdown is completed. that only leaves the timers to be taken into consideration. "thomas.diesler(a)jboss.com" wrote : IFrom that perspective, it is unnecessary and not even desired to provide backwards compatibility for database layout. i agree. backwards compatibility of DB layout is not feasible and not necessary. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161705#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...