The highs and lows of choosing a cloud migration strategy

Social distancing and general safety provisions as a result of Covid-19 will, according to Gartner’s latest spending forecast, accelerate the adoption of cloud in the enterprise. Initiatives to help organizations continue operating–the rollout of remote work options, increased availability of online transactions for customers, and distance learning in education–will be bedded down in 2021.

 One CEO summarized the situation for consultancy McKinsey earlier this year: "We are witnessing what will surely be remembered as a historic deployment of remote work and digital access to services across every domain."

An integral part of digitalization for the enterprise is moving its existing, core applications - those on which the business depends - to the cloud. IDC believes the migration of such software systems is a critical component of the overall cloud journey, saying: "These applications cannot be immediately discarded as they adopt [the] public cloud."

All of which throws a lot of work the architect’s way.  Not only do they have to develop and coordinate the cloud architecture, but they must also determine the best way to move such applications to the cloud, develop a cloud strategy and coordinate a plan of action to get there.

Long before Covid-19, Red Hat had identified the three ways in which architects could make the journey: lift and shift applications; augment them with new layers, or re-write or refactor them. The merits of each are back in the spotlight as architects face the accelerated adoption of cloud. But what are the pros and cons of each approach - and do they operate alone or in conjunction?

Lift and shift strategies

Lift and shift is a shrewd bet for the architect. It involves re-hosting an existing application - moving it from your servers to those of a service provider, without change. Even before Covid-19, this was a popular choice as the Cloud Migration 2.0 report found most organizations had tried this. 

What’s the appeal? Re-architecting existing applications for the run-time of cloud demands a full-scale review, analysis, and assessment of your application's data, its performance, usage, and users' requirements. It means translating and re-interpreting all that for the new, service-oriented and elastic infrastructure of the cloud.

Nobody ever ran towards the job of refreshing an enterprise platform if the outcome was going to be the same thing just "newer." The same applies now. Lift and shift gets an application “on” the cloud at lower cost and commitment. It’s also useful for prolonging the life of aging applications as they get to take advantage of the performance boost of running on modern hardware, while their owners get to save on data-center costs. Cloud Migration 2.0 tells us: “Rehosting has [the] greatest benefit for applications nearing the end of [their] utility phase, with up to three years before end of life.” 

Lift and shift does have downsides. The Cloud Native Computing Foundation (CNCF) has nicely articulated what it means to be cloud native: "Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments.” The types of enterprise applications being shifted to cloud have not been built this way. They are centralized and monolithic, depend on custom storage and fail-over-and-recovery, and employ proprietary and/or custom-built management interfaces and tools and practices. Lift and shift will package this into a virtual machine - but it won’t change the fundamentals. As the Red Hat whitepaper puts it: 

Lifting and shifting is not intended to modernize the application architecture. Instead, it gets enterprises running on a modern deployment platform with a buffer of time to refactor the application later.

There’s another challenge: unwritten applications can pack a hidden cost. According to McKinsey, 84% of on-prem applications are over-provisioned - that’s a whole lot of excess storage and compute capacity getting shunted up into the cloud, making them many times more expensive to keep running as is.

Finally, there’s data connectivity and performance to consider. If the data doesn’t move with the application, you might encounter brand new challenges in networking, availability, and stability. The head of architecture for one unnamed North American telecoms provider told Cloud Migration 2.0: “Moving only the applications - not the data - created connectivity challenges.”

Augmentation

Augmentation is a more advanced step on the journey to the cloud. It involves placing new layers of software around an existing application to make its functionality, features or data available to new applications, services or platforms. This can mean, for example, wrapping an HCM system in an API layer or interface to run on mobile or as part of a Software as a Service.

Augmentation is a pragmatic option. It means avoiding the risk and costs involved of a complete rewrite while - at the same time - opening up that older application and data to modern forms of delivery. You get to set the pace at which you move to the cloud by refactoring and rewriting applications as needed while - again - being able to prolong an application’s life.

This can be helpful, for example, where your business and technology operations are not yet aligned to be sufficiently agile to exploit a native-cloud infrastructure or where you have a mixed technology estate. Take an HR department running an ageing JD Edwards while sales are rolling out Salesforce: uniting these on one platform would potentially be difficult, costly and contain a large element of risk that must be mitigated and managed.

While augmentation will take you further down the road to cloud, it does have one fundamental drawback: the underlying architecture won’t change, so the application cannot be considered genuinely cloud native. It won’t, therefore, be able to take full advantage of the scalability, flexibility, and resilience that are built into the cloud in areas such as compute, storage, networking, and orchestration. 

Rewrite or refactor

Rewriting means completely updating an application for cloud. You would pursue this as part of a long-term modernization plan because it means either rewriting an application, its features and/or functionality or refactoring the application’s code to something modern and cloud native. That would likely mean containers and microservices architecture - with the features and functions of a monolithic application rewritten or replaced, and the code refactored.

This process does, however, offer the opportunity to remove the inefficiencies and technical debt accrued by applications. Also, you can eliminate vulnerabilities, performance issues, and management complexity that can blight virtual implementations and that would persist in both a lift and shift and layered model. As the Red Hat whitepaper notes, the scope of change is an opportunity to simplify. 

Resist the temptation to simply migrate old behaviors, and instead plan and prioritize as if developing a new application. This will help create applications that are more flexible and accommodating to the changes that will come.

Rewriting or refactoring has one final advantage: it will free your organization from dependence on older applications that might have become expensive and time-consuming to maintain, or those that are supported by a single vendor, or that rely on support skills that are difficult to source. As before, rewriting is a huge strategic commitment that can be expensive and time-consuming. History shows organizations are reluctant to spend time re-implementing an existing system unless it delivers something genuinely new or unless the costs or security concerns make the move unavoidable. It might, therefore, pay to take rewriting and refactoring slowly - to work application-function-by-application-function, or to employ greater use of augmentation. 

Conclusion

Cloud is a journey - one that’s poised to become a deal busier during the next few years. There’s no single, prescribed way to make that journey successfully: lift and shift, augmentation, and rewrite/refactor all play their parts, either as standalone policies or as cogs in an overall strategy. The approach you take will be determined by requirements and circumstances - those of your organization, its operations, and the applications and functions that must be modernized.