Roll Out Strategy in BizTalk Migration

Rollout in an EAI migration project is always tricky – the goal should always be to cause as little disruption and downtime as is necessary. In order to achieve this goal of minimal disruption, an incremental phase approach is recommended.

To further illustrate our phased deployment approach, consider the following scenario which is typical in most EAI implementations in large enterprises - The existing SeeBeyond implementation has a history of having been built incrementally; new programs or upgrades were placed in service individually. Now compound that complexity with migrating the actual EAI logic to a new tool (BizTalk). Deploying such a migrated solution which includes a large number of sub-systems in service all at the same time, even if they are well tested, is an incredibly risky step for any business. Do not be deceived if each subsystem individually has a low bug rate – a single problem can manifest itself in ways across other systems that may not have been tested or accounted for. What typically occurs is that the number of such problems quickly overwhelms and cross-pollutes other systems, crippling the ability of the organization to deal with them. In other words - High Conversion Risk.

Incremental migration strategies entail the decomposition of multi-system implementations in phases which can be independently and selectively addressed and replaced. This reduces the costs and risks of a migration program. The original SeeBeyond sub-systems are retained and used until the BizTalk functions achieve an acceptable level of reliability, then they are replaced. In the beginning the smaller interfaces are piloted as the learning curve is steeper and the number of unknowns greater, so we do not want to overload with a complex sub-system. As we gain greater expertise and vital insights, we attempt to bite of larger pieces and tackle them until we meet with complete success.

In an incremental rewrite methodology, the SeeBeyond system continues to run as the new system is built, tested, and deployed. You will want to try to build the new system in a way that seamlessly integrates with the old system. The side-by-side environment maintains redundancy as functionality moves from the old to the new system.