In the event of a change in BizTalk, you normally deploy at a specific time/date all your changes when there is no “traffic”. This is because you first have to remove the Schemas, Maps and Orchestrations before you can deploy the changes. Therefore all the processes in BizTalk that make use of these artifacts have to be stopped and can not run. Especially when you use a Canonical Data Model (CDM) it can be difficult to deploy changes because Maps and Orchestrations in different processes use the same Canonical Schemas. One of the advantages of the ESB toolkit is that you can easily deploy modified Maps and XSD schemas but how does it work?
Orchestration-based and messaging-based services in an Itinerary don’t depend on Schemas and Maps like “regular” Orchestrations do. So in the event of a change, there’s much less disruption with this model.
Orchestrations are not bound to a specific map because transformations are performed by the MapHelper class. Therefore they don't have to be removed when deploying a change.
Orchestrations are not bound to a specific .XSD schema because the used Message Type is a XmlDocument. Therefore they don't have to be removed when deploying a change.
Orchestration-based and messaging-based services in an Itinerary don’t depend on Schemas and Maps. When Schemas and Maps are removed from BizTalk, the ESB still can process the messages and map to the other message types because the maps are still in the GAC. This can be very useful in an 24*7 environment where it’s crucial that it is possible to deploy changes without stopping other processes that do not depend on the changed Schema or Map. Deploying changes with the ESB Toolkit is very powerful so you have to be careful and know what you are doing!