You almost certainly have legacy applications – older pieces of software that your employees are accustomed to using. They serve your needs and are often heavily proprietary. Unfortunately, legacy applications cause problems for many businesses. Thus, getting rid of them is key. However, what to do about legacy applications is not always clear, resulting in them being left in place far longer than is necessary. On top of that, replacing them can result in retraining costs and even data loss. How do you get into the 21st century without leaving behind things you need?
There are three overall approaches you might take to the problem.
Lift and Shift
Lift and shift is also called “rehosting”, and you have probably already done some of it. Any time you move data from an in-house server to the cloud you are performing lift and shift.
In lift and shift you simply move your legacy applications and data wholesale from one server to another, treating the cloud-like another data center. This approach was common in early cloud adoption, and has been used by many large companies.
Advantages of Lift and Shift
- You can accomplish the migration very quickly. There is no large scale recoding and, in many cases, all you need to do is change a few DNS records.
- Rehosting can generally be automated, although manual rehosting can be helpful for training and greater understanding.
- It is sometimes easier to optimize the legacy applications after they are running in the cloud rather than before.
Disadvantages of Lift and Shift
- You aren’t making the most of cloud architecture with optimized software.
- This approach tends not to scale well.
- You still have to manage all of the same patches and updates, resulting in saving less IT time than other approaches in the long run.
Lift and shift is a good approach if you need to migrate large amounts of data quickly. It also makes for a good stop-gap while a more optimized cloud solution is created. If you want your data out of the data center right away, then this is the right approach to use. However, it does still leave you in a position of using the same legacy architecture with the same potential problems.
Application Refactoring
A second approach is called refactoring. When you perform refactoring, you generally buy a Platform as a Service (PAAS) account, giving you a set of managed services over which you have more control.
The legacy applications are then transferred to the cloud, but are refactored to take advantage of more cloud-native features. These options let you worry about the application, not the OS itself. There will be some change to the design, but the code is kept intact as much as possible.
Advantages of Refactoring
- You can still use the existing codebase and thus have to do less work than a full rebuild.
- Your apps will be modernized to use cloud capabilities. This makes things more scalable.
- It allows you to move to a continuously innovative system using containers, with which you can slowly catch up to modern code.
Disadvantages of Refactoring
- You are still locked into the legacy framework at many levels, which can sometimes trap you in a legacy situation which is not ideal.
- Many PaaS options use ephemeral storage, which requires a significant change to the codebase from using a local file system.
- You have a certain amount of transitive risk based on contracting with the outside provider.
Refactoring is a good plan if you have a lot of existing code, data, and institutional knowledge. For example, it reduces the amount of extra training your IT personnel need. It can allow you to make incremental changes to bring things forward. For many companies, refactoring is the best option, allow you to balance speed of deployment with improved performance.
Rebuilding
When you rebuild, you discard the original code and then re-architect a new solution based on a PaaS infrastructure and using the full capabilities of the cloud. The new software is designed to run natively on the cloud platform. Because of this, it doesn’t involve licensing any software. Ideally, the new software should act in a similar way, resulting in minimal retraining for users.
Advantages of Rebuilding
- Legacy code is completely retired, meaning that you no longer have to worry about maintaining it.
- New software is optimized for the cloud, resulting in improved speed, reliability, and security.
- Modern innovation can be used freely, including advances in artificial intelligence, blockchain, and DevOps practices.
- Highly scalable. You can plan for the future and create solutions that will grow with your company.
Disadvantages of Rebuilding
- Code is optimized for a specific platform, resulting in vendor lock-in. A change of vendors may result in loss of functionality and assets.
- Longer development time may leave you having to use the existing legacy infrastructure for longer.
- Higher initial expense. Because you are doing all of the code changes in one go, the expense over the short term is higher. Your budget may not be up to all of the expense at once.
Rebuilding is a good option if you need or feel you will benefit from wide scale adoption of newer technologies. It may be the best option if your legacy applications are causing security concerns. Additionally, many businesses go for lift and shift or refactoring first and then opt for a rebuild later. It’s important to choose the right platform when rebuilding because of vendor lock-in concerns.
Conclusion
The right way to handle your legacy applications depends on your need. If you are in a hurry to get rid of an expensive server room, lift and shift may be the answer, at least for the short term. Refactoring is a good option for companies that know they need to make changes but want to keep them gradual. Rebuilding is the best option if you want to adopt newer technologies quickly and have security concerns.
You may need expert help to choose the right one. The Provato Group offers this expertise. Schedule a consultation with us to find out how to best handle your legacy software without losing anything in terms of data, time, or extensive user training.
