Cloud migration strategies

Are you in the process of migrating workloads to the cloud?

Based on time/budget contraints and the willingness to modernize current solutions, you may pick different strategies:

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

Lift and shift

In the Lift and Shift approach current application will be hosted in cloud by replacing current infrastructure components with cloud equivalents (e.g. VM or Server → EC2, Load balancer → ELB, MySQL → RDS, etc.)

PROs

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

CONs

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

Use when

  • 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

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

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

CONs

  • 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

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

Rip and Replace

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

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

CONs

  • 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

  • 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

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?

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).