Introduction
These days I have come across various organizations that have these massive legacy applications that have been built and have accumulated features over many years. They work great and provide the required business value, for now. However, the technology used to build these applications is obsolete and the design and architecture are also outdated. With the cloud and AI the next big things in the IT world, one question seems to come up. How and when can we migrate these applications to newer technologies? I try to answer this question in this article.
The 3 Steps for Migration
The main challenge is how can we schedule the upgrade of a very large legacy application. How can we justify the time and budget needed to upgrade or re-write major portions of the already working application. This step is the most challenging. How do we convince stakeholders that we need to move to newer technology when in practice the business working remains the same?
Step 1. Create an application architecture highlighting the benefits of the new technologies to improve the business model
The first step would be to put together a detailed design and architecture of the application using newer technologies. Here, you can create a diagram with cloud technology components like Azure Vnets, VMs, Storage accounts, and PAAS services. You can highlight the benefits of using cloud technologies along with cost savings in the form of maintenance and scalability. You can also incorporate services that can improve the business working model like Big Data and Machine Learning. Also, you can highlight that support for older technologies is to be discontinued in the future and that could lead to numerous issues in the support and enhancement of the application in the future.
The main point I would like to make here is that simply a lift and shift of the same application as it is to the cloud might not be so easy to sell as the business stakeholders already have an application that meets business needs. Hence, migrating the application with new and advanced features that will benefit the business like better performance, better searches, access to more data and quick generation of more reports would be an attraction to migrate the application. This step needs lots of analysis of the existing application and what shortfalls it currently has. Then, you need to try and solve these issues with the new cloud and AI services. If this step is successfully completed, you have already won half the battle and you are now on the way to a successful migration.
You can also find tools that can help you in this process like Azure Migrate. However, I would always support more direct analysis and study in addition to the use of these automated migration tools.
Step 2 - Create a working POC application to demonstrate the benefits of the new technologies
Rather than jumping onto a new concept with a very large plan and big application, I have always been a fan of starting off with a small Proof of Concept (POC) application. Start by creating a few core features of the application to showcase the benefits of the newer technologies like using Azure for cloud native applications. Try to cover the features which were the source of issues in the existing legacy application and how these issues are now resolved or improved with the new design. This will give confidence and enhance support for the new application.
In order to re-use the components of the POC, it is always better to design this POC using techniques like microservices, loosely coupled components, and services. This will ensure that the time and budget used in the design and development of the POC do not go to waste.
Step 3 - Migrate in Phases.
Do not completely stop development on the legacy application. Well, even if you want to this in most cases will not be possible as the business has to run and some sort of support and enhancements will always be required. However, try to limit this new development work to a minimum. Try not to add too many new features as if we keep on adding new features it will be difficult to catch up on the new application.
Break down your application into distinct phases for migration. I would recommend something on the below lines:
- Migrate your data stores including relation, non-relational and other databases.
- Migrate your middle-tier services. Try to migrate to Web APIs or containers as required.
- Migrate your other stores for storing secrets etc.
- Migrate the front-end components using MVC, Razor Pages, SPA, or other technologies.
If possible, try to integrate the existing legacy app into the new cloud artifacts like connecting to a cloud database like Azure SQL after the first step mentioned above is completed. In some cases, this might need too much time and effort and hence we could simply build the new application in parallel rather than integrating the migrated components into the already existing application. I would leave that decision to you.
Summary
In today’s article, we looked at how we could migrate an existing legacy application to the cloud and to newer technologies. This is just a recommended framework and not something that is a hard and fast rule. Depending upon your application, time available, and budget constraints these framework steps might need to be modified or enhanced. In some cases, we might need to do a simple lift and shift of our application due to the use of 3rd party applications, etc. Hence, please see this as a guideline that I have put together from my experience.