This article will look at producing a long-term BizTalk migration strategy, and then explore three key features of an individual BizTalk migration project (migrating from one version to another) which are essential to maximise efficiency and ensure the work is completed before support ends.
Many companies use Microsoft BizTalk as their application integration solution. However, BizTalk is now considered legacy software and many of its earlier versions are now out of support (2013 and back), with end-of-support dates approaching for the remaining versions.
PLANNING A LONG-TERM STRATEGY
Due to the complexity of migration and time pressure as support windows close, it is often not practical to immediately migrate to a more future-proof integration solution such as Azure Integration Services. It is instead often necessary to migrate in stages, which can involve using other BizTalk versions as stepping stones toward the final goal.
The closer Biztalk versions are to each other, the easier the migration will generally be due to greater overlap in features for adjacent versions. Therefore the project can be completed faster than a migration to a later version or different integration solution altogether. This time could make all the difference between whether a production system goes out of support or not.
Therefore, the first key to a successful migration is to plan this long-term strategy and decide which BizTalk versions to use as stepping stones to reach your desired integration solution. Many factors will influence these decisions, such as which BizTalk versions you currently have in use, and the estimated complexity of each part of the migration process.
There is a range of potential technical challenges, for example, you may need to set up new BizTalk environments or upgrade servers on which an existing environment runs. Understanding the long-term strategy in advance will allow you to make huge time and financial savings over the course of a migration project.
THE KEY PILLARS TO A SUCCESSFUL BIZTALK MIGRATION
With a long-term strategy in place, the next step is to complete the migrations themselves. There are three key areas to focus on at this stage to ensure each migration goes as quickly and smoothly as possible. These are to understand your codebase, enlist expert assistance, and have a strong testing strategy.
The following sections show how focussing on these areas can help you avoid common pitfalls and complete your migration as quickly as possible, avoiding the risk of running applications on out-of-support systems.
1. EXPERT ASSISTANCE
As a legacy system, Biztalk has many features and dependencies which are no longer in common use. Additionally, when older applications were first written they may have taken advantage of libraries that are now deprecated or not widely used. Migration requires identifying and redeploying these resources. This is a complex technical task, especially as the original developers are often long gone and documentation can be scarce.
The longer ago the applications were written, the more challenging this can become, and the added complexity can cause a project to go off track. To mitigate this, it’s worth enlisting experts who have many years of experience working across all versions of Biztalk.
Another key area where expert assistance is vital is in modifying existing BizTalk configurations to support a migration project. We recently worked with a client running multiple versions of BizTalk simultaneously, and their migration plan involved moving code from earlier versions onto an existing BizTalk 2013 setup. This required vertical scaling of the existing BizTalk 2013 servers to handle the load of the migrated applications. In these situations, expert help can be invaluable for planning, configuring, and tuning the performance of these legacy systems to ensure a smooth migration.
2. UNDERSTANDING THE CODEBASE
Over the years it is often the case that source code on older BizTalk systems can be lost or become out of sync with the production environment. Understanding the state of the codebase is essential for planning a successful migration.
There are three general scenarios, each requiring a slightly different approach:
- Complete confidence – full source code is provided and it is known exactly which version is deployed to the production system. This is possible if continuous integration was used during deployment, linking specific versions of the code to what is deployed in a production environment. In this case, no comparison is necessary and only migration is required.
- Partial Confidence – source code is provided but there is doubt over which versions are deployed to production. This requires a comparison phase comparing assemblies deployed on the production system with assemblies built from the existing codebase. The results of this comparison will either clear up doubt over which version is deployed to production or identify gaps in the existing codebase which require decompiling production assemblies and reconstructing the code.
- Low Confidence – there is either no source code or no guarantee that the code represents the state of the production server. In this case, the best approach is to decompile the production server assemblies and reconstruct the code from scratch. This is the most time-consuming option but does ensure the correct version of the code is migrated.
There may also be additional challenges specific to each migration project. In a recent BizTalk migration project, we encountered a system where multiple versions of the same assembly files were installed together on the production system. We needed to design a custom deployment solution that could deploy the different versions in the correct order to replicate the production setup.
3. TESTING
Critical to all the approaches above is a strong testing regimen. This will catch any errors or omissions in the migration process as well as flag up any unexpected code changes which were missed during comparisons. The most effective strategy to test for a BizTalk migration is to design a suite of tests that cover all use cases of an application.
These tests can then be run against the pre-migration applications to establish a benchmark and then against the migrated applications to check for any differences introduced during the migration. These tests can be designed and built in parallel with the work to migrate the codebase, and this is strongly recommended as testing early will surface any issues with old environments or any missing dependencies. These can then be resolved without holding up the main migration effort.
Due to the high complexity of BizTalk migration projects, and the requirement to orchestrate many different processes at the moment that a migrated application goes live, it is very useful to arrange to run tests on the production environment after the migrated code is deployed to ensure everything is working as expected. This will catch any issues which were difficult to capture in a test environment, such as account permissions or IP restrictions, and gives confidence that the migrated code is working as expected before putting a high load on the system.
CONCLUSION
A BizTalk migration can be a complex and time-consuming task but is essential to avoid the risk of running systems on out-of-support technology. This article covered what to consider when planning a long-term migration strategy, and then examined three key areas to focus on to ensure a successful migration: enlisting expert assistance, understanding your codebase, and developing a strong testing strategy. Focussing on these areas can help avoid many of the common pitfalls in migration projects, and greatly reduce the time it takes for these time-critical projects to be completed.
Transparity has extensive experience in completing BizTalk migrations and a team of BizTalk specialists with many decades of experience. Contact us today to find out how we can assist with your BizTalk migration.
