[jbpm-dev] Migration

[Tom Baeyens]

Jeff, Burr, Martin,

Afaict, you are the guys closest to our customers.  Next week, we'll be discussing 
migration between jBPM 3 and 4 in the team.  We would appreciate your input.

If we had unlimited resources, we'ld simply provide DB, process-XML and API backwards 
compatibility, but given that our resources are limited and the improvements 
numerous, here are my initial thoughts on how we currently think to handle migration:

Probably DB migration will be too hard to supply in a decent manner.  So we'll 
probably target that users will be able to use jBPM 3 and jBPM 4 in parralel.  That 
way they can start deploying new processes to jBPM 4 and let jBPM 3 processes fade out.

For each process in jBPM 3, they could migrate the process to jBPM 4 (see below), 
redeploy and start new executions in jBPM 4.  Although from the user client code 
perspective this will be hard or impossible.

We also anticipate that we'll have to supply a process translation tool that can 
translate jPDL 3 process XML files to jBPM 4 process XML files.  Most of the process 
file will be converted.  But probably there will be some things in jBPM 3 that we 
will not support in the exact same way in jBPM 4.  So some converted processes might 
  not be complete or might not execute exactly the same way as in jBPM 3.

API will be different.  Only migration docs.  The good news is that with the arrival 
of jBPM 4, we'll start to ship a more limited API that is more decoupled from the 
engine internals so that it will remain much more stable from then onwards.

Feedback from our jBPM Community Day in Dublin was very clear: Migration is one of 
the biggest concerns for our users.

So here are my questions:

What aspect of migration will be the biggest challenge for our customers ?

Which aspects of migration will be showstoppers for ourcustomers ?

Suppose that we ship the above migration strategy and a really really really 
important client wants to migrate his DB really really really badly.  Would we
a) be able to say no.
b) provide him with skeleton code that the client can use as a basis to write their 
own DB migration in code.
c) let our consultants work out the DB migration for the first customer that wants to 
pay for it and then add it to the jBPM codebase.

-- 
regards, tom.