Skip to main content

Deals You Can't Miss

1 Year Subscription

10 Tips To Fail AWS Cloud Migration


In my working on cloud migrations of varied scale with several organizations from startups to large enterprises, there has been some repetitiveness in the gotchas that I witnessed. This blog post is a satirical recollection of these to help you in your endeavors of cloud migration in general, and AWS Cloud in particular. Why AWS cloud specifically? See later section that answers this.
  1. Compare the cost of on-premise servers with AWS on-demand servers and blame AWS to be expensive 
  2. Use wrong EC2 instance types for your application servers and/or database servers only to call out AWS to be non-performant
  3. Design your VPC poorly and crib at AWS for being unnecessarily too complex
  4. Poorly configure your Security Groups and yell at AWS for being so insecure
  5. Swear by your out-dated knowledge of AWS to shout out on the limitations of AWS
  6. Not knowing where you are (knowledge of your existing systems and its operational needs)
  7. By not accounting for AWS services that you can and should leverage, you can always lay your claim on existing systems to be too complex for cloud migration
  8. By including workloads to reduce your architectural tech-debts as part of cloud-migration to AWS, you can comfortably paint a scary picture to your management
  9. Try offshoring the migration work to 3rd-party consulting vendor blindly
  10. Not trusting a 3rd-party consulting vendor and so bringing in an other one into the cloud migration game play


TL;DR; (Too Long but Do Read)


I have come across a few C-Suite technical executives claiming AWS Cloud to be too expensive and thus they chose to fight competition being in their own fort. Further inquiry revealed that the teams compared apples to oranges (see point 1 above), put square peg in round holes (see point 2 above). In one enterprise use-case I have witnessed a globally distributed company, by virtue of their organisation structure, struggle to get the VPC design done right making them juggle from all-apps-in-one VPC to VPC-per-app and every possibility in-between, all during their cloud migration. This coupled with big-bang migration efforts resulted in utter chaos and demotivated teams. It took mighty efforts to motivate and align the teams back in order. 

Overlooking simple security measures, could break the cloud migration or adoption plans. I know of many startups that jumped out of the AWS cloud adoption, because one of their developers ended-up leaving their EC2 ports open to public that resulted in a hacker breaking into their system wreaking their business.

The subtle but critical thing that is often overlooked is the team's ability to say, "I don't know but will learn it". Technology is hard and demanding. AWS as cloud platform is evolving as radical pace surprising its customers with newer capabilities that was requested for. So what impossible in AWS last year could well be possible in the present year. Their platform evolution is a manifestation of their customer-first attitude. I was talking to a couple of AWS Solutions Architects the other day who were in disbelief when I stated that it has been a few years since AWS made it possible to have cross-region VPC peering. Please do prepare to know your destination well enough, when you got opportunities for it.

What is more riskier is when enterprises miss opportunities to learn their current landscape, its strengths and weakness. One of the key things that help cloud migration is to learn and document your key business requirements as it stands today. This should be a living document that binds the application development team and the operations team. In my consulting endeavors, I build DevOps capability and maturity by bringing the Dev and Ops teams together in the preparation of such a living document in consultation with the Business stakeholders. Do you see how subtly I am aligning the teams to the business goals? This worked well for me thus for and hope it serves you too. Take it, put it to practice and thanks me later ;)

One other red-flag that I have encountered in the past is this practice of attempting to chew more than what you can at a point in time. Cloud migration is a tech endeavor that often has big positive impact to your business. Doing this needs proper preparation and focus towards mitigating risks. And the worst thing you can do in this endeavor is to do things big bang coupled with attempting your architectural tech-debts. In one business use-case that I have been in, an enterprise chose to do cloud migration of legacy applications deployed on-premise and at the same time to also modernize it. Phew!

Lastly offshoring cloud migration work COMPLETELY to third-party vendor is an anti-pattern in my humble opinion. It gets even worse when you pool in a couple of vendors for whatever reason and they end up not work together in your business interests. People problem is subtle but deep for long time until it manifests itself as a beast you can't control but only kill, costing you dear. As protip, I would strongly recommend you have a technical interface from your end on varied fronts to oversee, guide and learn together. You destination may have gold but it is your lessons learned along the way that gives you strength and ability to survive for long time to come.

Do feel free share your cloud migration experience that worked or caused you pain you can't forget. Eager to learn lessons from your experience...

My Popular Posts

Ten Commandments of Egoless Programming

We are nothing but the values we carry. All through my life thus far, I tried to influence people around me with the virtues I value. Thanks to some good reading habits I had inculcated, and the fortune of being in good community of peers and mentors alike, I managed to have read some real good books. This post is about the 10 commands of egoless programming in Weinberg's book. I shall explain the commandments based on my experience here. So very many decades ago, Gerald M. Weinberg authored  The Psychology of Computer Programming . In it, he listed The Ten Commandments of  Egoless Programming , which remains relevant even today for us as not just programmers but as team-members. Weinberg is regarded as a pioneer in taking a people-centric approach to computing, and his work endures as a good guide to intelligence, skill, teamwork, and problem-solving power of a developer. When they appear to inspire and instruct, we find that they can apply to just about every business area, and e

Should I buy refurbished laptop from Amazon?

This post is based on my experience with amazon.in and guess it to be true on all other platforms as well. At least you can check out and verify for these pointers before you make that decision to buy renewed/refurbished laptop on Amazon with your hard earned money. I see this question propping up in several forums and on many different occasions. In the recent past, I had my 5 year old dell laptop that gave up because its motherboard failed. One of the options that I had in my mind was to re-use the HDD and the 16GB DDR4 RAM of that old laptop in the one that I purchase next as secondary.  I had come to a conclusion that it is not worth buying a refurbished/renewed laptop at all. Why? For the following reasons, most of which I see as BIG #RedFlags: You got to remember that Amazon provides a platform for 3rd party sellers to sell their products as well. So in your search for refurbished laptops you wouldn’t want to choose some random 3rd party seller who Amazon doesn’t endorse. You cou

Multi-tenant Architectures

  Multi-tenancy Application Deployment Architecture could be modeled in 4 broad ways: Separate Apps & Separate Databases Shared Apps & Shared Databases Separate Apps & Shared Databases Shared Apps & Separate Databases There is no right or wrong here. It's about choice and consequence that you should consider taking into your business context and constraints. In this post I intend to jot down a some key points to keep in mind for each of these multi-tenant architecture. These are more of quick notes for my quick reference, a cheat-sheet of sorts when I have to make choices. And I guess this can come handy to you too in your wise decision making. Separate Apps & Separate Databases Easiest to implement from development and deployment stand-point. Just automate the deployment infrastructure for every tenant for quick set-up. Most expensive of all the models from infrastructure cost stand-point. Relatively longer deployment t