In addition, while attempting to test for a null deployment ID and ignore those tasks for now, I've found that TaskDataImpl does not serialize deployment ID in its read/writeExternal. Was this intentional?
Due to some bugs in jBPM5.4.0.Final I am planning to move to version 6. Since you have already gone through this exercise can you please tell me what issues you might have gone through ? Fortunately unlike your case our project has not went to production and we are still in development stage and I see this is the right time to move for version 6. It would be great if you can point me to the issues at higher level so that I can make some decision based on that.
I think that is a very good time to switch to 6.x. We are aiming to get 6.1 in about a month, so if you find issues in the next months we can make sure that those get solved before releasing 6.1.
Keep us posted about your findings.
Apologies for the late answer.
The best solution, which you've probably already done at this point, is to simply fill the column in the old rows with the name of a non-existent deployment id -- unless you expect these tasks to be handled in the new system, in which case I would link them to a new deployment id.
The deployment id is important upon task completion, in which case the task completion would trigger the process instance to move forward -- and process instances are grouped by deployment.
(However, if you're just only using the jBPM engine as an embedded engine in your application, I don't think you need to worry about deployment ids: the advice above applies when using the jbpm-console or kie-wb.)