This post was originally published here
What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:
1. You need an intermediate step
Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)
2. Install the latest BizTalk CU on your development machine
The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.
We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.
When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:
That last error lead us in the right direction: BizTalk Server 2010 CU2:
This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.
After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!
So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.