BizTalk applications can be migrated from a test to an
acceptance environment or from acceptance to production environment. However, BizTalk applications can also migrate from a BizTalk 2006 to BizTalk 2010 environment. This wiki article describes the steps to perform the latter. The article will assume
you want to migrate from BizTalk 2004 or higher (2009) to the latest BizTalk version 2013.
Over the last couple of years the BizTalk platform has matured to its current version. With the end of the life cycle of some versions like BizTalk 2006 it may not surprise you that a migration to a new platform is necessary. Below you will find an overview
of BizTalk versions 2004 and up with its platform support.
The diagram above is taken from Leonid Ganeline
blog (BizTalk Server MVP).
The following steps describe the migration of applications from an older BizTalk version to a new BizTalk version:
The benefit of the first is that it is less time consuming. However, you may encounter issues that can be time consuming to resolve. Latter procedure is a manual process that is more time consuming, but can result in hidden issues with maps, schema’s or
orchestrations. Below you will find an overview of the changes in tooling and features for the different BizTalk versions.
The diagram above is taken from Leonid Ganeline blog (BizTalk Server MVP).
MSI’s or bindings will do you no good to use them in a new environment because of incompatibility issues with .NET framework, adapters, host names, and so on. It is better to build the applications from the ground up. This can be done through either automated
process of using the Visual Studio Conversion Wizard or a more manual approach. Then build and deploy your solution. Configure it and then start it.
You may be tempted to do the migration on auto pilot. Using the MSI generated in the old environment and import them in a new environment or use the Visual Studio Conversion to quickly upgrade the application. This is not the procedure you should follow
though. It is advisable to have a migration plan first and dictate the priority of which application you want to migrate first. You also determine what complexity is of each
application and what the impact of migrating to a new environment will be. Some of your applications will have to be redesigned or engineered to benefit from new platform enhancements. To conclude the best and safest way is to do the migration manually. In
some scenario's you may benefit by using the conversion wizard from Visual Studio for your applications. However, the binding always has to be recreated and cannot be migrated.
Read suggested related topics: