Introduction

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.

BizTalk Platform

Over the last couple of years the BizTalk platform has matured to its current version. With end of 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).

Migration

The following steps describe the migration of applications from an older BizTalk version to a new BizTalk version:

• Backup Visual Studio projects.
• Convert projects in Visual Studio through Visual Studio Conversion Wizard (For troubleshooting see this page).
• Compile the solutions against .NET Framework.
• Build and deploy.

Or

• Backup Visual Studio projects.
• Recreate projects in Visual Studio 2010.
• Copy old artefacts from the old projects into the new project.
• Compile the solutions against .NET Framework.
• Build and deploy.
  
  

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 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).

It may be possible you have to recreate some of the old artefacts to in case you want to leverage WCF-based adapter that were not available in BizTalk Server 2004 or 2006. In that case it is better to do migration manually.

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 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.

Conclusion

You may be tempted to do migration on auto pilot. Using the msi generated in the old environment and import them in 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 have to be recreated and cannot be migrated.

See Also

Read suggested related topics:

• Understanding BizTalk Application Deployment and Management (MSDN)
• Troubleshooting BizTalk Server Migration (MSDN)

Another important place to find a huge amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.