25th September 2020 | Written by Kevin Weiler

Managing the complexity of moving a legacy application to the cloud

While “lifting and shifting” a stand-alone legacy application to the cloud is usually a straightforward operation, some organizations struggle with the complexity of migrating applications with many integrations and dependencies on other services. At Nuvalence we’re helping a client migrate and modernize a large application that integrates with no less than fifty other applications, both internal and external to the client. This migration would be a real challenge without a coherent plan of attack to keep us focused.

The overall strategy we’re using is to identify those integrations that will cease to function once the application is moved, and refactor those integrations to a form that works in both the on-premise and cloud environments before the application is actually migrated. This approach allows us to reduce risk by minimizing what’s actually changing on the day we cut over.

We’ve adopted a 5-step plan for organizing the migration project:

1) Inventory the integrations

Our first step in the process was to create a master list of services and applications that the target application interacts with, and the integration points with those other services. To do this we started by reviewing the existing documentation, and followed up by interviewing developers, systems administrators, and other subject matter experts.  During this process we also identified a number of applications with enough integration points to justify their own sub-projects to manage the refactoring efforts.

2) Classify the integrations

Next we reviewed each integration and classified them according to the method of interaction.  Some of the interactions involved sharing files on a mounted filesystem, others involved sending automated emails, and still others involved sending and receiving files via FTP, for example.

 3) Find a migration solution for each classification of interaction

Next we determined how we would refactor each of the classifications of interactions we found.  For example, since the existing mounted filesystem would not be available in the cloud environment, we had to find a solution that would provide similar functionality that works both on-premise and in the cloud. Since the client is migrating to AWS, we settled on Amazon S3 as the solution for this type of integration.

 4) Select an integration of each type to use as a pilot

Next we selected a specific integration of each type to use as a pilot, and refactored the integrations according to the plans laid out in the previous step.  We thoroughly tested the integrations in both the on-premise and cloud environments to verify the approach for each classification of integration.

5) Refactor the remaining integrations

Now that a solution has been developed for each classification of integration, we’re rolling through the lists of integrations and refactoring them according to the solutions that have been verified in the previous step.  At this phase we can easily parallelize the effort because solution patterns have been identified and documented for each type of integration.

Using this approach, we’re systematically refactoring a massive legacy application to be cloud-ready, if not entirely cloud-native.  Since the integrations have been refactored according to verified methods, we can look forward to the day we cut over to the new environment with confidence.

 

 


Leave a Reply

Your e-mail address will not be published. Required fields are marked *