Buy @ Amazon

6 Strategies For Migrating To AWS - A Cheatsheet

Migration to cloud is no easy task. There are a lot of planning and preparation that needs to be done before the journey even begins. But this post is not about the phases of cloud migration. 

This post is about the common strategies that are adopted by the organisations to migrate applications from on-premise to cloud. This post is not a substitute to the AWS Whitepaper on this subject, but an exam cram or cheat-sheet of sorts to aid your understanding and remember it all easily. So the cheat-sheet to 6 common strategies are:

1. Re-host

  • Think: Lift and Shift 
  • Times when you can automate the entire migration by way of automation with AWS Server Migration Service (SMS), without much manual intervention.

2. Re-platform

  • Think: Lift, Tinker and Shift 
  • Times when you take the migration as an opportunity to tinker your platform for good. Typical use case is to leverage AWS Managed Services to reduce the maintenance overheads, like using AWS Relational Database Service (RDS) in cloud. The engine is same, the platform is different. This should be analogous to situations when you use the same car for driving on icy-roads or dry-roads; just that you may tinker your car tyres with snow-chains for better friction on snow-filled roads.

3. Refactor / Re-Architect

  • Think: Re-modelling for better
  • Times when you refactor and/or re-architect your app in a fairly big way. Typical use case is to go cloud-native leveraging Elastic Kubernetes Service (EKS) or Elastic Container Services (ECS) by re-factoring your monolithic app as a set of microservices. Enterprises might adopt this strategy even if this is an expensive approach, should they deem the benefits out-weight the costs.

4. Re-purchase

  • Think: Drop and Shop
  • Times when the enterprises mimic individual shopping habits, like how we simply discard our current mobile phone for the newly launched mobile phone offering promising features. Or think of how we discard our current car for a new one. Ok that might be a stretch to think of all migrations choosing this strategy. There are umpteen occasions when this is a clear winner. Think of use-cases where:
    • Companies dropped in-house and/or disparate office tools and adopt Zoho Office Suite, because they find it fairly economical SAAS offering.
    • Companies dropped in-house code-repository service and adopt Github for good.
    • Companies dropped in-house and/or disparate Continuous-Integration/Continuous-Deployment (CI/CD) ecosystem to adopting AWS CodePipeline (which can deploy apps even on instances running on-premise!)

5. Retain

  • Think: Revisit later! 
  • Times when you wouldn't want to taunt the beast, like when you have mainframes systems that are managed on-premise. You know it's a beast out there that requires to be handled with great focus and deliberations. After all, you don't want to be mauled, do you?

6. Retire

  • Think: Decommission 
  • Times when you discover legacy apps being maintained for no apparent business value add. We all have heard of this office gossip of how some office detective in sysops-team discovered an unused or hardly used app that was silently eating the server capacity. He had the audacity to put his neck out and flag this to the management. He first got reprimanded and only later was thanked and congratulated...oh, focusing on that poor application, its now decommissioned!