Blog Post
It is becoming increasingly common to hear CIOs say that any new applications their enterprises adopt should be cloud-based, with SaaS as the first option (will an existing service fill your needs?), and with custom-developed applications written to be cloud native. But what about the many legacy systems already running in your organization? After you've done an initial triage (see my previous post), large enterprises are left with significant portfolios of important and value-adding systems. According to a Computerworld interview with Stephen Orban, head of enterprise strategy at Amazon Web Services (AWS), "now that major enterprises have gotten their feet wet with smaller cloud projects, they're beginning to focus on migrating large, critical legacy workloads."
So here's my take on how to approach this. The following is excerpted from my report, "The CIO's Guide to Cloud Computing" (PDF download).
Lift and shift: In this model, existing applications are moved to cloud infrastructure without being re-written. It’s a good option for organizations that have excessive infrastructure costs, and for applications where the data is tightly coupled to the application logic. Virtualized workloads, such as VMWare, are easier to lift and shift and can be re-hosted unchanged on supported platforms. However, if your infrastructure costs are already good, lift and shift won’t gain you much, as your application will not be able to take advantage of some of the primary benefits of cloud infrastructure, such as its scalability. And this is not a good choice for resource-intensive applications, which will likely cost more to run in the cloud and may suffer from performance and latency issues as well.
Containers provide a “wrapper” around existing code to enable portability from one environment to another. The best known and most widely adopted of these is the Docker open-source standard. Containers provide access to more of the benefits of cloud than the lift-and-shift model but without assuming the burden of having to rewrite the application itself. Containers are also useful for new development, enabling you to develop in one environment, test in another and run in a third, according to Joe Weinman, author of Cloudonomics and Digital Disciplines. But as with much of the cloud space, containers are still evolving. It’s a great tool and one that has many CIOs excited, but it may not be right for every application. Try it with a few complex but non-critical applications and learn from the experience.
Rewrite applications (or refactor, changing the code but none of the functionality) to achieve full cloud-native capabilities where greater responsiveness to business needs is important – e.g., in areas that are rapidly changing and would benefit from faster release cycles, or for mobile applications. Rewriting increases developer productivity in the long run and makes it easier and faster to roll out new versions, as applications are based on components or micro-services. It can provide higher performance and responsiveness, often at a lower cost.
Of course, large organizations are likely to have a lot of these, and rewriting can be expensive and time-consuming, so it’s essential to understand how the application addresses your business needs and what risk factors are involved. A good place to start is with applications where you’ll see the biggest business lift from an agility/business benefit standpoint and where the risks are low in terms of the application or data. Systems that are poorly designed to begin with are also good candidates, because these will "consume cloud resources inefficiently [in a lift-and-shift arrangement], thus generating a much higher public cloud bill, and may even create performance and stability problems," according to David Linthicum, senior vice president at Cloud Technology Partners. (Linthicum wrote an excellent piece on this here.)
Leave it alone. Some complex legacy systems are fine as they are – at least for now. If the demand on the system is steady and the system is working well, there may be no immediate reason to move it to the cloud. On the other hand, if only a few people really understand and can work on the system, that’s a risk factor. CIOs are weighing the pros and cons of maintaining these systems, managing the costs and complexity of data centers and shifting their investments from CapEx to OpEx. This will be a continuous process over the next five to 10 years.
