CloudMigrating Legacy Applications to the Cloud: Four Viable Approaches

We often help companies who want to move their legacy applications to the Cloud. There are several ways to accomplish this, depending on their goals, how their legacy application is structured, and what they hope to gain by moving to a Cloud serverless architecture. 

It can be extremely costly to keep legacy systems running. According to recent studies, the amount companies spent on legacy technology has been increasing over the past six years. Supporting on-premises legacy infrastructure to keep legacy applications running can lead to many problems, including increased susceptibility to malware and relying on systems for which no patches (or experts who can fix the application) are available.

In most cases, our clients want to preserve the data and even the business processes associated with the legacy applications. And, careful coordination is required to make sure that the application—in whatever form it is in at any given moment—is running smoothly as the transition is taking place. 

As we have done this work, we have found that the approaches to migrating legacy applications to the Cloud tend to fall into four categories. 

The Four Approaches to Migrating Legacy Applications to the Cloud

The quickest and easiest solution is lift and shift. This approach requires no application architecture changes and minimal or no code revisions. It simply installs your application in the Cloud using its current architecture on virtual hardware. 

The upside to this approach is it is cheap, efficient, and relatively easy to implement. 

The major downside of this approach is that you can’t take full advantage of the benefits of a Cloud serverless architecture, including scalability, security, and resiliency. It also introduces an additional security risk, as the application could serve as an attack vector—a vulnerability that hackers could exploit—which would then give a hacker access to the rest of your infrastructure. 

In addition, a legacy application is built to handle a certain workload in a certain environment. Moving it without first thoroughly testing its performance and scalability, especially when changing the access from a local network to the wide-area network (WAN), can cause the application to to be overextended in unexpected ways. A sudden increase in usage could crash the application, cause data to be lost, or result in a denial of service (DOS) situation.

The second choice in migrating applications to the Cloud is to rebuild your legacy application. The rebuilding approach moves your application to a serverless infrastructure and rearchitects it to use native Cloud technologies, such as platform-as-a-service (PaaS). 

This approach is more expensive and time-consuming, and often requires significant code changes. To ensure no interruptions to service in the Cloud environment, we need to make a full-scale analysis of workflows, any application dependencies, and your application’s role in other data and processes across the business. 

However, this is the most sustainable application migration approach. The application can be scaled for any increases in demand or usage, have remote availability, and will continue to meet all the needs of the business. This is usually the best business choice in the long run.

The third choice is to rewrite a portion of the application such as the business logic (the “middle tier”) or front end. You can rebuild the “middle” of the application, where all of the business logic and business rules reside, leaving the front end and back end as they are. Or, you can also opt for a more modern-looking front end, if your middle-tier services are advanced enough to support that front end. 

Rewriting one or more components of an application to take advantage of Cloud services is referred to as “refactoring.” It often involves breaking down the application into distinct modules that will help you quickly deploy new functions to respond to evolving needs. 

Before implementing this method, we make sure the application performs well when separated from its database through the WAN. This is often the first step when deciding whether to rebuild an application altogether or just refactor it. 

In some cases, we maintain the legacy application in read-only mode, which gives us access to the historical information without having to support the ongoing functionality of the legacy app. 

The final approach is to completely scrap your legacy application and use SaaS to customize and replace the legacy application. This makes sense in certain situations. A simple example would be if you currently host an email server. You could replace it with web-enabled Office 365, which includes Outlook and lets you manage users and mailboxes. 

There are many SaaS applications today that could easily replace your legacy applications. Some minor customization would make it specific to your business needs. This option should probably not be used if you are currently using a legacy application that is highly depended upon, highly customized, and/or can run only on the infrastructure it currently resides in.

We may end up using a combination of approaches in situations where we are moving more than one legacy application to the Cloud, or moving a combination of functions to the Cloud. For example, we may rewrite a business-critical application, and replatform or “lift and shift” others. 

Our team works with you to make these decisions, driven by your business needs, the urgency of the move, and the operational impact it will have on your business for a smooth transition.

Maintaining Legacy Applications Hinders Productivity

A legacy infrastructure running outdated applications that have been changed or customized far beyond their original purpose may cause high response times, slow the ability to retrieve data to a crawl, and result in a significant loss of productivity. 

When weighing the pros and cons of maintaining the on-premises legacy infrastructure to support your legacy applications, we consider the hardware (servers, software licensing fees etc.), the cost of installation, the backup of data, and internal or external IT service and support. Large on-site server farms are costly in terms of hosting costs, physical space, cooling, life-cycle management, daily maintenance, and employee hours. 

The benefits of migrating to the Cloud are weighed against the fact that the legacy application is possibly a large, complex system that may be more expensive to run in the Cloud or the migration may be too risky to undertake. This is rare, however.

The Business Case for Stakeholders

Getting the approval and support of your stakeholders—executives, shareholders, department managers, project teams, partners, and customers—can include these considerations and benefits:

• Investing in Cloud application development and mobile apps makes good business sense and supplies greater speed, flexibility, efficiency, distributed intelligence, automation, and security. 

• Changes are faster and rollouts are less risky, due to the modularity of Cloud applications and the availability of cloud native CI/CD solutions. Improvements can be made to one function without negatively affecting other functions. 

• You will increase the pool of developers able to work on the application, rather than being dependent on one person who may have long since retired or who is getting ready to retire.

• Current access roles and rules built into the legacy application will be maintained and can be improved with newer Cloud-based access tools. 

• Elasticity can be gained across all aspects of the environment. 

• The long-term ROI is often a positive factor. You will see an immediate savings in the life cycle management of the on-premises equipment. Instead of you having to upgrade every three to five years, the Cloud provider will do it. No longer will you have to keep an inventory of individual equipment or support for end-of-life dates. No more downtime for patching. This saves time and money.

• Onsite servers have a finite amount of space available for your data. If you need more, you must buy a new server and integrate it into the legacy infrastructure. The Cloud has an infinite amount of space, and you will pay for those times when you experience an unexpected increase in traffic. However, you will only pay for the space that you use, rather than being forced to build an infrastructure to handle unusual spikes in traffic. 

• Your current infrastructure is limited by the physical components, operating systems, and applications, and how they function together. With a serverless architecture, you gain simplified updating and patching, guaranteed high availability, reduced development time and effort, agility, increased performance, and the choice of a pay-as-you-go cost structure. 

• Thanks to the five 9’s guarantee included in your Cloud service provider’s contract, you’ll have improved and increased availability to your application.

• The Cloud helps to decrease the costs of scalability that come with supporting a datacenter. It cuts down on the amount of workforce needed to support it.

• Because of the amount of traffic within a corporation, it’s hard to keep a handle on the information flow. By migrating your legacy applications to the Cloud, you can ensure the company’s activities are recorded and monitored, allowing for real-time visibility to help you improve operations.

Risk Mitigation for the Planned Rollout

Before migration, we always analyze the current and proposed functionality, business and data requirements, infrastructure, overall architecture, integrations, and other technologies to ensure success.

We also set the project up so it reduces the amount of risk involved, by:

• Maintaining the current and new versions. By keeping both running during the migration process, we can roll back to the outdated version if we uncover new issues that were not previously identified.

• Reengineering dependencies. Before going live with the new application, we examine and map all of the dependencies in the old application. We make sure that each dependency is retained or improved in the new serverless environment. 

• Selecting a small test group. Migrating everyone at once is a guaranteed way to find issues but may have severe consequences. We use a small test bed, then slowly expand from there.

• Addressing any issues. If an issue is found (a dependency, code error, or failed connector) we address it at once. This prevents the accumulation of issues, and the resolution of these issues as they occur further simplifies future work. 

• Migrating one function at a time. We replace components individually. Migrating individual components results in quick feedback, and limits interruptions to ongoing business processes.

There are many things to take into consideration before migrating legacy applications into the Cloud. Each situation is different. One approach may work well for one application, but may not work with another. There is no universally packaged way to go about the migration process, but there are definitely best practices that ensure a smooth transition.