Versioning long-running orchestrations

Orchestrations can be built to operate in a stateful, long-running fashion. This introduces a host of powerful service aggregation and coordination capabilities. However, it would appear to be quite difficult to ever find the right time to introduce a new version of such an orchestration. If we always have orchestrations dehydrated and waiting for messages, how can we ever hope to bring a new version online without being forced to tear down existing instances of the orchestration?

In this scenario, we want to initiate a manual review of any product label changes that have been introduced by the upstream systems. We need a new schema representing a product label review:

Next, we need a property schema that holds a pointer to the unique review ChangeID review that this review schema retains during long-running processes:

In order to inflate this review message, we need a map that takes the data from our Product schema and maps it to the review schema:

Because...