Cloud migration strategies

How would you migrate on premise workloads to the cloud?

You may pick different strategies considering time/budget contraints and the ability to modernize existing software:

  • Lift and Shift, replace infrastructure components with cloud equivalents
  • Improve and Move, modernize the application architecture while migrating it
  • Rip and Replace, completely re-write the solution with cloud-native technologies

Lift and shift Link to heading

Lift and Shift involves hosting the application in cloud replacing current infrastructure components with cloud equivalent components (e.g. Virtual Machine → EC2, Load balancer → ELB, MySQL → RDS, etc.)

PROs Link to heading

  • fast and easy way to perform a migration
  • requires fewer or no changes to existing software

CONs Link to heading

  • neglects many benefits of a cloud environment (cost optimization, disaster recovery automation)
  • no managed availability, manual scalability

Use when Link to heading

  • there is an urgency to move away from current situation (e.g. a loan contract expiring in a few months, on-premise atacenter decomissioning)
  • you can’t afford the budget or the risk to modify existing application (very old software with oor documentation of internals, a core dependency for many other systems)

Improve and Move Link to heading

Improve and Move involves, while migrating, a modernization effort to repurpose an existing solution for the cloud (e.g. monolith → microservices, sync flow → async flow with queues or events, etc.).

PROs Link to heading

  • better integration with the cloud enviroment
  • may leverage auto scalability and managed availability of cloud components
  • may eliminate some technical debt

CONs Link to heading

  • may require in-depth revision of the application (e.g. heavy refactoring)
  • requires a budget for updated skill sets and new tools
  • does not work with off-the-shelf apps

Use when Link to heading

  • migrating recent custom applications
  • application requirements do not match with runtimes offered in managed cloud components

Rip and Replace Link to heading

The Rip and Replace approach is the most disruptive, it involves a complete re-design of the application from scratch using only cloud-native components. Re-writing is the only possible way to enjoy cloud at its best, for example considering new patterns like serverless.

PROs Link to heading

  • takes full advantages of the cloud
  • can optimize costs of infrastructure
  • will eliminate technical debt

CONs Link to heading

  • rewriting effort may be non trivial
  • requires a budget for updated skill sets and new tools
  • may have an impact on dependent applications

Use when Link to heading

  • the application does not meet it’s goals (poor performances under normal usage, frequent crashes)
  • the application is not worth maintaining or evolving (very old technology, expiring maintenance contract)

The migration process Link to heading

A cloud migration path usually includes four stages:

  1. Assess, identify application workload and its dependencies
  2. Initialize, create a foundation in cloud defining user and roles, network topology and security groups
  3. Deploy, move the application to the cloud environment
  4. Optimize, iterate and optimize

Where to start? Link to heading

You would rather start with a pilot using a non critical application, you will either create a success case or learn from errors and retry with much more experience.

For your first migration you should favour applications that:

  • are isolated and non business critical
  • have no compliance challenges
  • require less data migration
  • don’t have propietary licences
  • can afford some downtime

In general you will find quite difficult migrating very interconnect/core applications (e.g. backoffice, data analysis, e-commerce, ERP) and, of course, there may be also cases where migration will be really hard due to legacy HW, data tranfer amount or impact on dependent processes (e.g. OLTP DB).