Cloud Migration Strategy: 5 possible paths


What Is Cloud Migration?

Cloud migration is the moving of applications, data, and other business aspects from on-premises to a cloud computing environment. By migrating to the cloud, your business can see reduced computing costs and improved performance, reliability, and security.

Let’s look at the hypothetical company AcmeCorp to see how it could benefit from cloud migration.

AcmeCorp used to be the go-to company for local, same-day small parcel delivery. Recently, AcmeCorp lost half of its business to Uber and Lyft, which offer more convenient delivery services and at a lower cost.

AcmeCorp’s operations and customer interactions are running on legacy infrastructure: 15-year old on-premise hardware and software.

Customers can arrange deliveries with AcmeCorp only via telephone or an outdated website. Customers can’t see any useful updates about their deliveries while they’re in transit. And AcmeCorp can’t easily change its delivery routes once drivers are on the road.

Meanwhile, Uber and Lyft utilize features made possible by cloud infrastructure like mobile apps, live delivery driver location broadcasting, automated SMS delivery updates, and AI-powered delivery route planning.

AcmeCorp will soon become unviable as a business unless it uses cloud computing to bootstrap its digital transformation. AcmeCorp’s heavy lifting can be handled by a cloud provider with practically unlimited computing power at a low cost.

A one-size-fits-all approach for moving to the cloud doesn’t exist. A company like AcmeCorp could benefit from an expert technology partner like INGENO to help them explore, select, and implement a suitable cloud migration strategy.

This article will explore five mature, tried-and-tested cloud migration strategies that INGENO could help you implement in your business.

Cloud Migration Strategies

1. What Is Lift-and-Shift?

Rehosting, also known as lift-and-shift, is the moving of an application and its data to cloud hosting without redesigning the app. Lift-and-shift takes advantage of a cloud provider’s infrastructure as a service (IaaS).


  • Immediate cost savings. Applications can utilize more cost-effective cloud computer systems without costly development and testing time.
  • Easy performance boost. Applications may be running on more powerful cloud-based hardware.
  • Lower risk of new security vulnerabilities. Applications stay mostly the same when moved to the cloud.
  • Highly available second site. Moving data to a cloud location is often cheaper than existing disaster recovery plans.


  • Doesn’t take full advantage of the cloud. Lifted and shifted applications were built to run on on-premises hardware. Their architecture won’t allow them to take advantage of features like autoscaling and dynamic load balancing.
  • Latency and performance issues. On-premises applications were designed to run on specific systems. So, they may not perform well once moved to a cloud environment.

2. What Is Refactoring for the Cloud?

Refactoring is the migration of an application to the cloud by re-architecting it to run on a cloud provider’s platform. Refactoring for the cloud takes advantage of a cloud provider’s platform as a service (PaaS).


  • Improved functionality. Your applications can be re-architected and developed to benefit from the flexibility and scalability that comes with the cloud.
  • Minimal rewriting. Developers can reuse the languages, frameworks, and unmodified chunks of code from your existing applications.
  • Reduced costs. High operating costs can be avoided by re-architecting an application for more efficient resource management on the cloud, scaling up and down as needed.
  • Improved reliability. Application components are decoupled from each other and integrated with highly available managed services.


  • More complex. Refactoring involves code changes that require expertise to pull off successfully. There is always some risk of errors in code that has been changed, leading to delays, cost increases, and unexpected service downtime.
  • Increased time to deploy. All code changes need to be tested thoroughly.
  • Vendor lock-in. Integrating with the services of any cloud provider makes migrating to a different provider later more difficult, but it’s usually the better strategy to optimize time to market and innovation opportunities.

3. What Are Cloud Containers?

A container is a standalone software executable that contains everything it needs to function. A container decouples an application from the environment in which it runs. A container can include software dependencies needed by the application, such as code libraries and specific versions of programming languages. A cloud container is just another name for a container that is executed by cloud computers.


  • No vendor lock-in. An application packaged in a container is decoupled from its operating environment and can easily be redeployed.
  • Minimal effort to deploy. An application can have everything that it needs to run included in its container. So, the application should run as expected, with no bugs from differences in environments.
  • Cheaper to run. Containers don’t require much memory to run because they don’t need an operating system to be executed. So, they can be cheaper to run in a cloud environment.
  • Easy to create. Applications are usually simple to containerize.


  • Not all applications can be containerized. An app can’t be containerized if it is dependent on a specific platform, or if it directly manipulates hardware devices.

4. What Is Serverless?

An application has a serverless architecture when it is broken up into functions that can be invoked and scaled individually on the cloud as needed. Converting an application to a serverless architecture takes advantage of a cloud provider’s function as a service (FaaS).


  • No need to manage servers. Developers can focus on business functionality. All server software and hardware needed to run the functions are handled by the cloud provider.
  • Pay for what you use. You are charged for the resources that are used when requests are being handled. You pay for your exact customer demand.
  • Always available. Server resources are made available as needed. And your application will almost never be unresponsive due to the performance of the underlying infrastructure.


  • Not suitable for longer-running functions. Serverless functions are designed to run for a maximum of minutes. Functions that take longer to run will time out.
  • Charges for data transfer. You are charged for computing resources used. High external data transfer can increase costs significantly.
  • Difficult to debug. Function contexts don’t persist once completed. So, bugs can be challenging to locate.

5. What Is Cloud-Native?

A cloud-native migration is the moving of your entire infrastructure and development operations to the cloud. Let’s take a look at the benefits of cloud-native development and management in the next section.

Benefits of Cloud-Native

A significant benefit of the cloud-native approach to development is in how infrastructure resources are allocated. In traditional applications, developers manage resource allocations manually. Cloud-native applications, however, are deployed on the cloud where the underlying computing, storage, and network infrastructure are abstracted away.

Backed by virtually unlimited computing resources, developers can allocate resources and not worry about whether those resources will be available.

Cloud-native application performance can be improved further beyond infrastructure. From analytics to databases to IoT to ML, each service that forms a part of a cloud-native application is developed with the best-suited language and framework.

Cloud-native applications aren’t tied to any particular operating system or type of computer. This means that the underlying hardware and software executing the applications can be replaced when newer, better versions become available.

Finally, microservices can be developed, tested, and deployed by independent DevOps teams on their own schedules, without disrupting other parts of a cloud-native application. In this way, an application can be updated with small improvements more frequently.

Migrating to the Cloud With Minimal Disruption to Business

Cloud migration can be done in a phased approach to minimize business disruption.

In phase one, applications can be moved to the cloud immediately with lift-and-shift with minimal risk of disruption to business activity. No code is changed, and surrounding infrastructure is communicated with as before the lift-and-shift. Any parts of applications that run for extended periods of time can be migrated to cloud containers.

In phase two, the lifted-and-shifted applications can be refactored to take advantage of more cloud-native features and services, such as serverless functions.

After phase two, any and all future application development and management can be cloud-native for improved application speed, agility, and resilience.

Leave a comment