Upgrading Persisted Workflows (WF 4.0)

When changing workflows, Microsoft does not support direct data migration from the long-running and persisted workflows instances. This means that every change to the workflows necessitates recompilation of the project and redeployment of the code/site. This may pose a problem for workflows that are persisted to the data store. If the changes to the workflow do not result in changes to the serialization of the workflow instance to the persistance store (database), you may be ok with updating the workflows and survive the exercise.
But, if those changes result in different serialization - meaning there are new states, activities, fields, etc. - then upgrading the workflow assembly and trying to resume persisted instances will not go all that well.
One of the ways to mitigate this in a state machine activity is to short-circuit the states. Meaning, apart from the initial trigger, there would be an additional trigger for short-circuiting the flow. The Receive activity, the trigger, could accept just the case identifier if your case data is stored in a database anyway. Then the case would travel directly to the state it was left in, before it was persisted, rather than go through the state machine all over again.
In the destination state activity itself a workaround is required in the Entry activity. There could be a simple If activity that does not perform any particular actions if we are short-circuiting *or* perform all the normal activities if the case came into the state the regular way.
Hopefully things get easier in the future.