It's time to rethink app migration strategies for cloud
As applications increasingly become a collection of services rather than monolithic pieces of software, enterprises will start to question and rethink traditional migration practices.
In the early days of cloud computing, Gartner defined what it called the "Five Rs" of app migration. Many users found those five approaches interesting, but murky -- and today, some question whether they're still relevant.
Let's look at these "Rs" from a modern cloud perspective, and why it might be time for developers to rethink their app migration processes.
1. Rehost
Rehosting, also known as lift-and-shift, is when an enterprise moves an application from a physical system on premises to a virtual machine in the cloud. In this approach, the application doesn't undergo any significant changes, other than some adjustments to deployment configuration parameters needed for the cloud.
Rehosting is still useful when the goal is more about server consolidation than app modernization. Today, however, many enterprises focus on containers more than VMs to tap into additional scalability and resiliency benefits. And, with containers, organizations must have a standardized deployment and connectivity model, which requires developers to modify any applications that don't fit within that structure.
2. Refactor
Refactoring is when an enterprise migrates an application to a PaaS environment rather than to a VM. Back in 2011 when Gartner released its "Five Rs," refactoring and rehosting denoted a move to PaaS and IaaS, respectively, but today, it's more complicated. PaaS now has a much broader meaning, often referring to both the hosting resources and native web services offered by a cloud provider.
3. Revise
Revising is a process in which an enterprise changes an application to accommodate cloud-based infrastructure. Today, cloud infrastructure includes hosting, as well as dozens of cloud-native services. For example, developers can replace legacy databases with cloud-equivalent databases to make an application run more efficiently in the cloud.
4. Rebuild
Enterprises today don't aim to just migrate apps to the cloud, but to rethink app design for the cloud.
During a rebuild, developers rewrite an application specifically for the cloud. Enterprises look at this option as a forklift replacement of a whole application, which is usually disruptive. However, in today's world, rebuilding entails changing an app to use cloud-native web services -- a process that combines refactoring and revising -- or breaking the app into a new cloud front-end component and a traditional transactional back end.
Many businesses add cloud-hosted browser and mobile app support to legacy applications that will still run in the data center. In these cases, the cloud-hosted front end of the application is totally new and the traditional back end doesn't change much, if at all. As a result, for most users, rebuilding isn't a part of the app migration process.
5. Replace
The final "R" is replace -- or to completely swap out a legacy application for a hosted SaaS version. However, SaaS options are typically only available for horizontal or more general business apps. Core business applications are rarely available in SaaS form, and many companies would never run these applications anywhere but in their data centers. So, while enterprises should definitely evaluate SaaS options when available, SaaS apps today remain more like a third-party extension of cloud provider's web services that users need to integrate with their own software.
Change your mindset on app migration
Based on some of the factors outlined above, the "Five Rs" won't always properly guide an app migration process. That shouldn't be surprising, as cloud technology has evolved at a breathtaking pace. Now, we should replace the old "Five Rs" with two new ones -- rethink and rearchitect.
Enterprises today don't aim to just migrate apps to the cloud, but to rethink app design for the cloud. This enables them to take advantage of cloud-native features and benefits, while protecting investments in legacy data center infrastructure for apps that won't run cost-effectively, or meet compliance requirements, off premises. Often, developers might break an application into smaller components as part of this process.
After they rethink an application's design, the next step for developers is to rearchitect the pieces of that application that will run in the cloud. Take an inventory of the web services and SaaS tools available, and then assign and modify each cloud-compatible piece of the application to use the tool that fits it best.
Generally, applications that have a distinct separation between traditional transaction processing and user interface components will be rethought and rearchitected, with the user-facing components running in the cloud. An application that doesn't have a distinct user interface component belongs in the cloud only if it needs highly variable resources, or if certain cloud services can improve its quality and performance.
