Enterprises ready to migrate to the cloud face hundreds of questions, including one of most common: What’s the best approach, lift-and-shift, re-platform or re-factor? The reality is there is no single path to success. Each option presents its own benefits and drawbacks, which must be considered on an application-by-application basis.
For most companies, there are several migration options:
Rehost: Sometimes referred to as lift-and-shift, rehosting takes a forklift approach to moving business applications to the cloud, moving them without any code modification. This approach takes advantage of automation to speed migration and with fewer resources.
Reinstall: Like rehosting, a reinstallation generally entails new virtual machines created in the cloud and the same software is installed from scratch with no configuration changes. Although it’s more work than a re-host, this approach allows some cleanup to happen during the migration, reducing the risk of copying unnecessary software and configurations that are no longer necessary.
Re-platforming: This moves assets to the cloud with a small amount of up-versioning, such as using a managed database offering or the addition of automation for auto-scaling. Re-platforming takes advantage of containers and VMs; only changing application code when needed to use base platform services like Amazon Elasticache and advanced Amazon EC2 services like autoscaling and Elastic Load Balancer. Re-platforming allows workloads to take advantage of base cost optimization, without the level of resource commitment required for refactoring.
Re-factoring: This involves more advancedre-architecting and often re-coding some portion of an existing application to take advantage of cloud-native frameworks and functionality. Most often, refactoring entails changing middleware and application components to take advantage of cloud-native features and advanced concepts like microservices and serverless.
For infrastructure and workloads that have low business value, enterprises may decide to retire applications that have met end-of-life criteria; replace applications with SaaS-based versions, or retain applications as is.
Assessing the migration path is an exercise in feasibility and cost-benefit analysis:
- How strategic is this application to the business? Is it an application that contributes to revenue and should be invested in, or an application that supports operations and hence shall be sustained at the lowest possible TCO? For example, an e-commerce website for a retailer is an app that should be invested in, while an employee vacation reporting system for HR is something to sustain. Migrations are often bound by time and budget. Resources required to re-platform or re-factor are better invested in what we refer to as invest applications, rather than sustain applications.
- For sustain applications, is it possible to rehost the application in the cloud? If yes, rehosting is the best option. If not, look for a SaaS alternative. If found, retire the app. If not, retain it. For example, if a vacation reporting app uses an IBM AS400 machine, it may be best to either replace the app with a different tool or retain the application on-premise rather than investing developer resources to refactor (recode) it for the cloud.
- Invest applications require careful cost-benefit analysis. Analyze cost in terms of development resources and any business interruptions that may be required from a significant rewrite.
- For example, if an application suits the serverless computing model using AWS Lambda and the development team has the skills and resources, refactoring is the right choice if the benefits outweigh the cost, and the direction is achievable within the constraints. However, due to common constraints most applications are not easy to re-factor at the onset and companies typically re-factor less than ten percent of their portfolio.
- Lastly, if refactoring of invest applications is not feasible, replatforming is the right choice. Typically, companies opt to replatform 25-30% of their portfolio. In these cases, the burden is on the DevOps team to build a harness for the application, which without requiring major code changes, can provide benefits of cloud features such as auto-scaling and self-healing. For example, an e-commerce website written in a framework that is not suitable for serverless may be replatformed.
By looking at the totality of an IT system, it may be possible to identify which infrastructure and workloads are low complexity and low business value. These are ideal candidates for retirement. It can also identify which are low complexity, but high business value, as these can be more easily relocated to the cloud. With a thorough assessment, organizations can create a solid migration plan tailored to their organization’s short- and long-term business objectives.
Aater Suleman is CEO and co-founder at Flux7, an IT consultancy providing DevOps consulting, cloud architecture, and migration services.