Add a section about migrating message contracts

Author: kentdr

nservicebus/upgrades/9.1to9.2/index.md

@@ -23,7 +23,11 @@ Update endpoint configuration code to use the new package and namespace. The API
 | `NServiceBus.SystemJsonDataBusSerializer` | `NServiceBus.SystemJsonClaimCheckSerializer` |
 | `NServiceBus.DataBusProperty<T>` | `NServiceBus.ClaimCheckProperty<T>` |
 
+### Migrating message contracts
 
-The NServiceBus.ClaimCheck library is line-level compatible with NServiceBus.DataBus, endpoints using NServiceBus.DataBus need not be upgraded to ClaimCheck all at once .
+The NServiceBus.ClaimCheck library is line-level compatible with NServiceBus.DataBus, meaning, in-flight messages that are sent using NServiceBus.DataBus will be properly handled by endpoints that have been upgraded to use NServiceBus.ClaimCheck; this is also true in reverse.
 
+Some care should be taken when migrating message contracts from `DataBusProperty<T>` to `ClaimCheckProperty<T>`.  While NServiceBUs.DataBus and NServiceBus.ClaimCheck are line-level compatible, they are not runtime compatible.  An endpoint that is currently running NServiceBus.DataBus will not write properties that are `ClaimCheckProperty<T>` to the DataBus. The reverse is true of NServiceBus.ClaimCheck endpoints and `DataBusProperty<T>`.  To facilitate the migration, each endpoint will need a copy of the message contract that uses the supported property type.
+
+If message contracts are in their own versioned library that have been migrated to `ClamCheckProperty<T>`, it is probable NServiceBus.DataBus endpoints can remain on an older version until it can be upgraded to NServiceBus.ClaimCheck.  If message contracts are not in their own versioned library, a local copy can be made to facilitate the transition. In this case it is imperative that all class names, namespaces, and property names are exactly the same to make sure the message can be properly deserialized when it is received.