It can be complicated to deploy changed .XSD Schemas, Maps and Orchestrations because BizTalk artifacts depend on each other. Changes in one BizTalk application may affect other BizTalk applications therefore you usually deploy at a certain time or 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. Also other 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 also Maps and Orchestrations in other BizTalk applications can use the same Canonical Schemas.
One of the advantages of the ESB toolkit is that you can easily deploy modified Maps and XSD schemas because Orchestration-based and messaging-based services in an Itinerary don’t depend on Schemas and Maps.

• Change in a Map
  • 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.
• Change in a .XSD schema
  • 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.

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. 
Please note that deploying changes with the ESB Toolkit is very powerful so you have to be careful and know what you are doing!

See Also

For more information on deploying changed BizTalk artifacts in the ESB Toolkit see:

• Deploying changed Schemas and Maps with the ESB Toolkit with NO Downtime for other Processes