How to perform an easy AWS Lift-and-Shift
Table of Contents
- Intro to cloud migration
- Lift and shift (re-hosting)
- Pros of rehosting:
- Cons of Rehosting:
- Cloud-native (re-architecting or refactoring)
- Pros of refactoring:
- Cons of refactoring:
- How lift and shift works on AWS
- The basic process of using SMS is as follows:
- About the Author
Intro to cloud migration
Cloud migration is the process of moving data and applications from a traditional server set-up, such as a data center, to a cloud-based set-up. The complexity and speed of the process depend on the type and number of applications to be moved as well as how they are migrated. This migration is done in an effort to reduce cost, increase performance, and to take advantage of other benefits of cloud platforms like resiliency, scalability, or innovation.
A detailed explanation of this process can be found here.
Lift and shift vs cloud-native—two strategies for migrating to the cloud.
There are multiple ways to migrate from a traditional set-up to a cloud-based one but the two primary solutions are lift and shift and cloud-native.
Lift and shift (re-hosting)
Lift and shift or rehosting means simply migrating data and applications as they currently exist to a cloud platform. It is the most common method of migration, and most supported by third-party services, due to the lower skill level required and the speed at which it can be done. This method of migration can be automated easily and accommodates established businesses with a lot of legacy data and applications. Businesses can avoid the costs of having to repurchase, replace, or reconfigure applications by moving them as is.
Pros of rehosting:
- Faster and cheaper—initial cost and time can be less than other methods of migration. Time crunches due to expiring hosting contracts or sudden increases in volume can be quickly relieved if data is already cloud-compatible and applications are well documented.
- Requires less skill—rehosting can be done even if no experts exist within the company or application documentation is poor. The process can be easily automated and there are numerous third-party options for hire further reducing effort.
- Simpler adaptation—it is often easier to make applications cloud-native once they’re in the cloud. The difficulties of migrating information and traffic, and adapting workflow are already handled reducing the number of steps still needed.
- Access to platform benefits—once applications are moved, some benefits of cloud security, resiliency, and support are available. Migration can provide immediate cost-benefit and risk reduction even when not optimized.
Cons of Rehosting:
- Lack of adaptability—migration includes operating systems, configurations, and “non-cloud” assets. Moving data without modification prevents the creation of an efficient system and can add unnecessary complexity.
- Inefficient resource use—non-cloud applications tend to be over-provisioned to accommodate potential use. When applications are moved they require more resources in the cloud because of this over-provisioning, meaning higher cost until they can be resized.
- Transfer of problems—data and applications are moved statically from existing servers to the cloud, including any issues, malware, or gaps in security they possess. Once moved issues can persist, malware can spread, and security issues can continue or expand.
- Extended timeline—the transition process will continue past the initial migration, costing additional time and money. After data and applications are moved, they often need to be modified to correct inefficient resource use or compatibility issues.
Cloud-native (re-architecting or refactoring)
Migrating in a cloud-native way requires re-architecting or refactoring applications to be moved in order to take maximum advantage of cloud functionality. Applications must be broken down into components and rebuilt using a service-oriented, scalable, and redundant design. Refactoring is the most advanced method of migration and the one that best utilizes cloud functionality. Refactoring applications allows for agile development or DevOps deployment in the future.
When this method is selected for cloud migration, it is often chosen early in a business’s lifecycle when only a few applications exist, when an expert is already present within the organization, or when there is a strong need to add features, scale, or performance to applications. This process can be done incrementally to make the process more manageable but more time must be available for the project.
Pros of refactoring:
- Cost reduction—cloud-native applications can often be billed per transaction, so they only cost when actively being used. There is also the cost-benefit of not having to house servers or manage equipment.
- Increased resilience—applications can be more easily shared across resources, meaning if one server goes down others can fill the need. The amount of resources a given cloud platform has in comparison to a single company greatly reduces the chance of an outage.
- Responsiveness to demand—cloud platforms have resources ready for vertical or horizontal scaling, allowing them to adapt according to business demand. Cloud-native applications are easier to autoscale, reducing the need for individual modification.
- Easily adopt innovations—cloud-native applications benefit from easier or automatic upgrading. Not needing to reconfigure applications means innovations in cloud services can be taken advantage of immediately.
Cons of refactoring:
- Lock-in—the more cloud-native your application is, the more dependent it is on the platform. With refactoring, all applications are integrated into the cloud which increases reliance on the provider and limits the ability to change providers. Skill level—requires expertise on the applications to be moved, automation, and the cloud platform. Developing expertise takes a long time and hiring an expert is expensive.
- Time—takes time because most or all components require modification to function as cloud-native. This means paying for time spent actively working as well as extra time for servers and storage.
- Human error—everything has to be changed, presenting greater opportunities for mistakes. If mistakes occur they require more time, skill, and money to fix.
How lift and shift works on AWS
AWS supports lift and shift through its Server Migration Service (SMS), which allows you to automate, schedule, and track transfer from your current servers to AWS. The SMS can be monitored and controlled through the AWS Management Console, further automating the process. SMS leverages AWS snapshots technology to duplicate on-premise resources and launch them on the cloud. Although you are responsible for the storage resources used during migration, like AWS snapshots or Amazon S3, SMS itself is a free service.
The basic process of using SMS is as follows:
- Scheduling—initiate the process immediately or schedule a time in the future. This step is customizable to minimize the impact on productivity.
- Uploading—a snapshot is taken of the server and sent to the Amazon S3 bucket. This process is done incrementally to reduce server downtime and bandwidth use.
- Converting—the server image is converted to an Amazon Elastic Block Storage (EBS) snapshot and removed from S3. These snapshots serve as backups for a given point in time.
- Creating AMI—the EBS snapshot is converted to an Amazon Machine Image (AMI). Once an AMI is created, it can be run as a virtual server on Amazon’s Elastic Compute Cloud (EC2) and thus replace the physical server that was migrated.
These stages are repeated every 12 to 24 hours, according to the need for 90 days. This helps ensure a complete and successful transfer by capturing any changes that may occur during the migration process.
Migration to a cloud platform can provide significant benefits to an organization but is a task that requires planning and some tough decisions. Using tools like Amazon SMS or third-party services can simplify the process but migration is only the beginning. Once a cloud set-up is achieved applications and data often need to be tweaked and should always be monitored and backed up, as cloud systems aren’t infallible.
About the Author
Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.
Recommended product: Coding Essentials Guidebook for Developers