Getting your organization to cloud is only the first part of the journey. Once there, you need to capitalize on the huge efficiency and innovation potential it offers. This means building applications and services specifically to maximize the value of a cloud environment.

For new greenfield developments this shouldn’t be a problem. But what about your legacy estate? If you’re a large organization, you’ll likely have hundreds, thousands, maybe even tens of thousands of applications in your portfolio, many of which will be mission critical.

To capture long-term value, you’ll need to carefully decide which of these applications need to be modernized, and to what extent. You’ll also need to consider your infrastructure and data architecture choices, whether you’ve already “lifted and shifted” your applications or are just starting out on a cloud migration.

Modernize applications: Simply rehosting your applications in the cloud will likely cut some costs and solve some technical debt issues. But how much difference will your business users actually see and how much additional business value will it actually unleash? To truly maximize the value of the new environment, you must modernize your applications for the cloud.

Modernize infrastructure: As the world moves towards software-defined infrastructure, systems that can operate in the new “infrastructure as code” paradigm are becoming essential. Modernizing your infrastructure for this kind of environment—enabling much more automation and intelligence-driven management—can significantly optimize not only your costs, but also your business agility and flexibility.

Modernize data: Data is the third key pillar of a modernization strategy. In many enterprises today, legacy on-premises data architectures are complex, expensive, inflexible and hard to maintain. In contrast, modern data architectures in the cloud allow you to spin up advanced hyperscaler analytics services—including machine learning and deep learning—at a speed and with a level of simplicity that would be impossible in your own data center.

There’s a wide spectrum of modernization approaches to choose from, with varied levels of cost, complexity and ultimate value to the business.

Accenture’s “7Rs” framework breaks down this spectrum into a clearly defined set of migration options. As you go across the scale, the degree of modernization increases from zero (i.e. rehosting and replacing) to comprehensive (i.e. refactoring and reimagining).

Here are some questions to ask as you sort through which of the 7Rs are most suitable:

• Do you have a choice? A key distinction is between discretionary and non-discretionary modernization. If you need to modernize an application even to get it to cloud in the first place, it’s a “must do.”
• Will the application actually benefit from modernization? If you have a stable legacy application with a limited lifespan, assess whether modernization is necessary.
• Can the application make use of its new cloud foundation? Very few applications will be able to use the full capabilities of cloud through rehosting alone. More than likely, you’ll need to modernize them to benefit from the new cloud environment.
• Is this a candidate for a cloud native transformation? By replatforming or refactoring an application for the cloud, you’ll create more flexible architectures and more value for the business. The question is how much modernization is appropriate in each case (see below).
• Will you recover the costs of modernization? The more changes you make, the more expensive and time consuming your modernization initiative is likely to be. This needs to be weighed carefully against the extra value you’ll be creating as part of a total cost of ownership assessment.
• Are there knowledge or talent constraints? When it comes to older mainframe applications in the estate, it’s essential to consider whether you still have the skills and knowledge to even attempt a modernization.

When you replatform an application, you’ll typically look to make minimal changes to the code—just enough to ensure it can deliver the same functionality in the new cloud platform.

With refactoring, you’ll be effectively breaking the application apart and reconstructing it in a new cloud native architecture. You may also be using a new programming language. The degree of code change—and subsequent testing required—will be significant.

For some applications it could make sense to go even further and consider service decomposition. This is where you decompose your application into a series of reusable components or microservices, expose them via APIs, and use an orchestration layer like Kubernetes. You may even decide your application warrants a serverless architecture, in which you run code in the cloud without managing infrastructure at all.

Digital decoupling is an advanced technique for modernizing large legacy applications, such as mainframe software.

Older applications can be challenging to rebuild in the cloud, especially when it comes to replicating their embedded business logic and data. With digital decoupling, you build a new system alongside a as a greenfield cloud-native development. By synchronizing data in your new and old systems in close to real time, both can run in parallel. This means you can modernize the application a piece at a time, using cloud-native architectures, modern techniques like DevSecOps and high levels of automation.

Think of it like building a new house right next to your existing home. You get to live in both buildings, while you gradually connect up each room and transfer your furniture across. Eventually you’re ready to live only in the new, without ever having had to renovate the old.

Sidestepping the pitfall

• Focus on the value, not just the cost. Modernization is a long-term process based on a solid assessment of where you are now and where you want to be.
• Don’t try to boil the ocean. The sheer scale of a cloud modernization initiative can be overwhelming. Consider breaking your application portfolio down into segments.
• Align the organization behind the program. One of the biggest hazards in any cloud journey is a lack of alignment between IT and the rest of the business.
• Think about the operating model. A modernization program must consider how the organization will run and manage the new applications in the cloud. There needs to be a fundamental change in ways of working, both at the infrastructure and the application level.
• Be smart about your priorities. In deciding which applications to modernize first, it’s absolutely right to be application-led and value-led. But getting bogged down in your most challenging project straight away is guaranteed to sap enthusiasm, even if it ultimately delivers the most value.
• Decide about the data. If an application has a database sitting behind it, modernizing the two together should be considered.
• Make time for testing. Many legacy applications are the result of years of accumulated knowledge and effort. To achieve the same level of performance, your modernization program needs to respect that degree of effort and test the refactored code exhaustively.
• Consider third-party tools carefully. There are several solutions available in the market that can automate aspects of your modernization program, but it’s unrealistic to expect any tool to automate modernization with 100% accuracy.

Modernization is the key to reducing technical debt and ramping up organizational speed and agility in the cloud. But full-scale modernization won’t be right for every application, every circumstance or even every company. There may be good business reasons for focusing initially on rehosting as a means to get to cloud quickly, but even if you choose to defer modernization for now, it needs to be on your agenda for the future.

Ultimately, if you want to benefit from the full value of cloud, you need to be working towards cloud native applications, infrastructure and data. A carefully considered modernization program is how you get there.