Integration Platform Migration - Steps

Migration

At a high-level, migration needs the following steps

• Discovery
• Implementation
• Release

Discovery

The discovery phase may be conducted through workshops between enterprise systems stakeholders to arrive at the Migration Strategy. The discovery may include analysis of current state architecture, of existing code, performing certain proof-of-concepts (POCs) to ascertain conformance to design patterns, POCs for connectivity with other enterprise applications and external systems, etc. The discovery phase brings about a specific set of outcomes that guide the rest of the phases. This phase may define a sequence of activities to build through the newer technology platform, starting with building the core functional blocks, common artifacts, and the order of migration of other applications based on this information.?

One of the first tasks as part of the workshops is to be clear on the benefits of migration, of course. There could be multiple triggers to embark on the migration exercise, and to identify the value proposition and document them through consensus would be the first step. In bringing about the consensus there could be a whole lot of inputs one could get as part of the workshops, sometimes from teams that do not see the value of migration, and these discussions can be helpful in documenting where the “value” of migration is. These workshops also help with prioritizing the applications for migration. Some application migrations may bring more benefits to the enterprise as a whole than another.

In-depth analysis would be needed to identify corresponding activities/tasks among the older and newer platforms and to verify if there is an existing tool or accelerator for the job or if an appropriate accelerator may be developed, to convert configuration of the corresponding tasks from one platform to another. For example, the table below identifies a couple of such activities, that are used in each of the following platforms that achieve the goal of mapping.

Based on the table above, an accelerator may be developed to convert existing activities in one platform to another. Identifying such activities as part of the discovery phase and assessing the feasibility and building these tools greatly helps during the implementation phase.

Implementation

The migration strategy that is produced after the discovery phase, contains components that may be worked upon in sequence. The phase typically starts with extending the POCs that were created during discovery into standard reusable artifacts that can be part of enterprise application frameworks. This may consist of building observability frameworks, configuration for DevOps tools or CI/CD tools, frameworks for connectivity to internal and external systems, etc. All these artifacts become the building blocks for applications that are yet to be migrated.

Product mapping is an important consideration, both at the discovery and implementation phase. In the discovery phase, the activity is focused on mapping a tool from an older platform to a corresponding tool in the newer one. During implementation, it is about building frameworks around the solution that is selected. For example, if building an in-memory cache is part of the solution, the older platform may have chosen a proprietary tool, while the newer platform may utilize an open-source solution, for example, Redis, as an in-memory cache. In the implementation phase, one could build reusable framework around operations that may be invoked with Redis store in the target platform. There are some platforms that provide their own products for various functionality, that may be considered, for example, in the case of TIBCO platform, ActiveSpaces is an option if your target platform of choice is TIBCO.

An important but often underplayed aspect of implementation is the need to train teams on the newer frameworks. Often times, in large corporates, the lack of skills in technical platforms may be compensated through contractors, however, the existing technical teams are the ones with the wealth of functional knowledge. The cost and effectiveness of training existing personnel on the newer technologies often beats the cost of training on the large amounts of functional knowledge that existing teams accumulate over the years. ?However, it may be assessed subjectively, based on the scope and context of the migration.

Building shared artifacts allows for proceeding into migration of individual applications. Based on the dependencies that were identified in the discovery phase, and the priorities, appropriate applications may be selected for migration. The usage of accelerators would be a key differentiator in this phase. Accelerators help

• Ensure common tasks are automated, reducing manual effort
• Ensure consistency across all processes
• Overtime, as the accelerators mature, they become a powerful time-saving mechanism for large scale migrations

One of the critical activities of the Implementation phase is testing. There are many tools in the market that can help with regression and performance testing. An enterprise with well-defined processes would have testing tools and standards in place, whether it is for a migration project or otherwise. The appropriate tools may be leveraged to work toward regression and performance testing. It is recommended to keep the older and newer systems “alive”, to ensure periodic tests are performed and any inconsistencies may be identified and fixed.

This phase also involves setting up the runtime for the target environment. This may include one-time setup and configuration of reusable CI/CD pipelines.

Release

As part of Implementation, the release scripts would be in place. Ideally, there would be parallel environments running for some time that can help with having a back-up for unforeseen runtime issues, and also as a validation through periodic checks for ensuring consistent results across both environments.

Any tasks related to provisioning, setting up appropriate users and roles, support training, documentation of Standard Operation Procedures (SOPs), and handing-off to support teams would be part of this phase. A good amount of time may be spent with support teams for live support in the initial days until Support teams are able to pick-up and handle maintenance chores.

Building common artifacts, setting up the new runtime environment, performing the application migration tasks, testing, setting it up for deployment for the first application, and supporting through the initial release provide valuable insights into existing application and the effort involved in the migration process. By identifying the opportunities for improvements in the first migration cycle, and applying the learnings into code migration, automation and CI/CD pipelines, the process matures and becomes repeatable as more applications are targeted for migration.