Even in 2021, many companies still run business-critical, legacy applications on-premises, just as they have for the last 20 to 30 years. The midrange server hardware, and their unique architecture, on which many of these applications run is both their biggest drawback and biggest advantage; the benefits of being able to vertically scale a platform were measured against the drawbacks of the necessary custom hardware. Migrating the workloads running on these types of systems to the cloud, which can potentially offer huge benefits, presents some unique challenges – here are four strategies for doing this, with pros and cons for each.
Option 1: Lift and Shift
The “lift and shift” option means you’re simply representing the on-premises network within a cloud service provider. This is the easiest and quickest option.
Until recently, this was not an option for most legacy applications. This was because the main hyperscale clouds did not offer dedicated infrastructure as-a-service (IaaS) implementations for several common data center operating systems. The process required purchasing a vast amount of dedicated hardware to offer as-a-service to customers, and it wasn’t clear if the demand warranted that cash outlay.
Recently, however, it’s clear that the only way for organizations can leave behind the data center is by moving business-critical applications to the cloud. There are now hyperscale cloud providers that offer lift and shift options for even the most demanding workloads.
Despite these benefits, it’s important that a lift and shift approach is carefully planned before executing. Even a couple of seconds of downtime in traditional application workloads can cost businesses thousands of dollars. Finally, organizations should understand that they won’t be using the cloud to its full potential simply by recreating their on-premises environment.
Option 2: Rewriting or Refactoring
Refactoring a traditional application into a cloud native application has been the de facto migration option for many years. It provides greater long-term cost savings than other options, because previously underprovisioned data center resources can now be consumed on-demand in the native FaaS offerings of hyperscale cloud providers. The compute capacity is nearly limitless, and only scales as resources are being used.
However, refactoring to cloud native services does have major risks, such as high short-term costs. Refactoring an existing business-critical application is typically much more complex than a simple lift and shift. Also, an application that has been part of the core business stack will have likely accrued many dependencies and interfaces with other systems and added modules that must be accounted for.
Another consideration is that legacy interfaces must appear identical to other systems post-migration, otherwise you must expand the scope — including other systems in the migration project that originally weren’t planned. Many of the hyperscale cloud providers do not support legacy interfaces in their cloud native services. Scope creep can become a real issue in this scenario, and your organization could lose sight of the migration timeline.
An enterprise service bus (ESB) is one potential solution to the problem of legacy interfaces. An ESB is typically deployed as a “bus” between various business applications, ensuring that all those interfaces use a common interface. The ESB handles the network, transport, routing and delivery of messages and content. However, ESBs add yet another layer of complexity, increasing the risk of failure for the overall refactoring project.
Option 3: Dynamic Lift and Shift (Reshape)
Reshaping an application to the cloud typically lies somewhere between the lift and shift and the refactoring strategies. It’s similar to lift and shift, but usually involves some minor modification to the application to take advantage of native tools within the cloud infrastructure. An example is adding automated launch and tear down of development and test environments.
One of the main advantages of a reshaping is that it is cost-effective. An organization will see significant cost savings over a simple lift and shift, for example, by only having to pay for the hours that the development and testing machines are powered up and running.
It also means that the development teams are free to experiment with refactoring certain applications without a hard deadline (such as a data center exit.) Finally, a dynamic lift and shift strategy allows development teams to leverage cloud native functionality, such as infrastructure as code, to automate traditional workloads without retraining on a whole new development stack.
Option 4: Drop and Replace with COTS
Another option is to replace your custom application for one that is commercial off the shelf (COTS). For example, replacing a custom-built customer relationship management (CRM) system with a vendor’s product.
This is not feasible for some organizations because of their business environment constraints, but it is recommended when possible. COTS products (that are typically SaaS) usually have a repository for various connectors to different legacy applications; however, this is largely dependent on the size and maturity of the COTS product.
It’s important to note that one of the largest risks of considering a COTS application is the skills within the organization. If the current development team’s skillset lies with custom, traditional applications, they will need extra time to retrain and develop the extensions to integrate the COTS product with their existing environment.
Migrating any application to the cloud is a large undertaking. There will always be risks when moving existing on-premises applications to the cloud, but in general, the overall positive impact of moving legacy applications far outweigh any risks, regardless of the approach you decide to take.
