What are the benefits and challenges of using a lift-and-shift approach to cloud migration?

I am my experience lift and shift mostly help in case of when your existing hardware is going EOL and you don’t have existing source code for modification.

Lift-and-shift offers fast, low-cost migration with minimal disruption. It's ideal for legacy apps or quick wins. However, it doesn't leverage cloud benefits fully and can lead to higher long-term costs due to inefficiency. Use it as a stepping stone, plan for future optimization, and consider security risks of moving unaddressed vulnerabilities

Lift and shift is fasted way to mark that check mark of having a cloud service without doing significant re-architecture of the existing service.

The lift-and-shift approach, streamlines the transition of applications and workloads from on-premises to the cloud, preserving the existing architecture with minimal changes. While it offers benefits like rapid migration, cost-effectiveness, and risk reduction, challenges exist. Its strengths lie in speed and simplicity, making it ideal for organizations seeking quick migration without extensive application changes. The appeal is further heightened by immediate cost savings, a pay-as-you-go model, reduced business disruption, and testing efforts. This approach is especially applicable in scenarios involving M&A (Merger & Acquisition), where the circumstances often necessitate "data virtualization."

Lift and shift can give immediate benefits because compute is now software defined. Vertical CPU and memory scaling, disk scaling and upgrading the entire IO capabilities may now be a matter of a few minutes. Reliability is improved and self-healing can frequently be implemented even though the application was never designed for this. Monitoring and management can be implemented at new levels of insight without application updates.

In addition to the lack of optimization for the cloud environment, lift-and-shift can lead to increased technical debt, as it may perpetuate legacy architectures and code inefficiencies. This approach also overlooks the potential for organizational change, such as shifting to agile development methodologies or restructuring teams for better cloud management. Furthermore, without proper planning and assessment, there's a risk of underestimating the complexity of migration, leading to extended downtime or disruptions to business operations. Additionally, without addressing architectural and design flaws beforehand, scalability and performance issues may persist, hindering the expected benefits of cloud migration.

Lift and shift does not let us holistically think big and reduce the number of interconnected systems. Lift and shift also generally maps to similar cloud product offerings (e.g.- paas) and does not translate to low maintenance saas in most of the transitions.

Lift and shift comes with disadvantages. Mainly, 1. Onprem services which are never designed for cloud native if we put those on cloud, they will not optimally perform. 2. Major factor is cost. Since onprem workloads are designed in such a way that they run on virtual machines and just migrating those in cloud means more of cloud instances usage and cloud instance disk storage. Cloud instance disk storage is one of the costliest component there in public clouds. This increasing the cost of running the service.

There are some challenges with the lift-and-shift approach when optimization is limited. This could mean that we're not fully utilizing the features offered by the cloud. In the long term, our cost efficiency may suffer if our applications aren't well-suited for the cloud, requiring a careful examination of license costs. If our applications don't fully utilize cloud security features or adhere to specific cloud rules, it can lead to security risks and compliance problems. Additionally, opting for the lift-and-shift approach may restrict our opportunities for innovation, as we might overlook exciting cloud services by not making necessary changes to how our applications function.

When lift-and-shift is the final state and there is no plan to refactor to a more cloud native format, the costs will still be a lot higher than cloud native compute patterns for the same application workload.

Evaluating and Optimizing Post-Migration: Following the migration of a legacy portfolio management system, we conducted performance tuning and optimization exercises to enhance its cloud readiness. By leveraging cloud-native services such as AWS Lambda for serverless computing and Amazon Aurora for database scalability, we achieved significant cost savings and improved system responsiveness. Continuous evaluation and optimization ensured that our application remained aligned with evolving business needs and technological advancements.

Lift-and-shift projects should project the cost of the lift and shifted application if it is let run in that format until it is retired. These costs should be compared to the one-time costs plus ongoing costs of refactoring to a cloud native format. If the ROI of shifting to cloud-native is attractive enough, then the project should be defined to lift-shift-migrate pattern and budget from the start. This will help prevent lift-shift-stall pattern.

As previously noted, this method is particularly suitable in situations related to M&A (Merger & Acquisition), where the conditions frequently require "data virtualization." In business scenarios with tight delivery timelines, the need for swift and simple migrations is paramount, necessitating minimal alterations to the application. Another factor supporting this approach is the immediate cost reduction offered through a subscription model. It proves to be a favorable option when the migration initiative is inherently "tactical" in nature.

Lift-and-shift offers an efficient way to migrate workloads to AWS, accelerating your cloud journey. Leverage tools like AWS Migration Hub for a smooth process, and benefit from managed services like DMS and SMS for simplified data and server migrations. This approach shines for legacy apps, quick wins, and minimizing downtime. However, remember it's a stepping stone, not a destination. While initial costs might be lower, limited optimization can lead to long-term inefficiencies. Overcome this by planning for refactoring later and utilizing the AWS Well-Architected Framework to identify optimization opportunities. Additionally, proactive cost monitoring and security measures with tools like AWS Cost Explorer and Security Hub are crucial.

Lift-and-shift is ideal when an organization needs to move to the cloud quickly, either to exit a data center, respond to competitive pressures, or reduce infrastructure costs. It’s also appropriate for stable applications with low change frequency, where the primary goal is to gain immediate cloud benefits like elasticity and global availability without altering the core application. However, it is less suitable for applications that require high performance optimization, or for those where future-proofing with cloud-native features is a strategic priority.

Refactoring: This approach involves modifying the application code to leverage cloud-native services and architectures. It delivers better scalability, performance, and cost optimization but requires more development effort. Think of it as rebuilding your engine for optimal cloud performance. Replatforming: This involves moving the application to a different platform within the cloud while preserving its core functionality. Think of it as swapping the chassis for a more cloud-friendly model. It offers some modernization benefits without a complete overhaul.

Re-architecture to cloud native architectures is the way to move to cloud, rather than doing lift and shift. Perhaps, using a middle-ware like Snowflake does help when dealing with both the form factors of onprem and onsaas by keeping the code and the architecture similar.

Replatforming is a common alternative to lift-and-shift that allows the business to take advantage of the cloud by reducing cost, complexity, or maintenance burden. This involves making a few cloud optimizations during migration -- shaping the application towards being cloud-native. For example, you might be managing your own database servers and migrate to a database as a service offering like AWS RDS.

Strangler Fig is a pattern that some lift-and-shift efforts can use to migrate to cloud native with the least disruption. In this pattern only small functions or APIs of the application are refactored to be cloud native over time. Eventually, like the tree that this is named after, the individual replacements completely replace the old application.

If migrating a large portfolio of applications - do not lift-and-shift all of them before getting started on refactoring ones that are appropriate for refactoring. Ensure that large migration projects bring the resources for the refactoring steps online long before the lift-and-shift of all projects is done. It's important to maintain momentum immediately after a given team has lifted-and-shifted their application.