Do you want to know why AWS migration projects fail? This is not so obvious If you read the AWS website or attend the annual re:Invent conference. There you will hear lots of stories about big companies migrating huge systems with mind blowing stats. Well, this is not one of those stories. Instead, If you do one or more things in this blog, your migration projects will not only fail but fail slowly causing maximum misery. This is especially true for large organizations migrating big systems.
#1 Confuse Stakeholders
Stakeholders are people in your organization who are responsible for big decisions that affect large departments like IT, finance, product and business. Your AWS migration project has good chance to fail when these people 1) don’t understand or 2) don’t agree or 3) don’t even know about it. Even a slight confusion at this level can have huge ripple effect and doom your migration project.
Here is a real story. A large company decided to go all in on AWS with a goal to migrate all of their data centers to AWS in 2 years. The initiative was spearheaded by CTO with clear and compelling vision. However, the business units were not aligned and some didn’t even know about it. As result, when the migration was rolled out, the business units asked, “how can our existing team absorb this new work?” The obvious problem was that business did not commit to the scope, timeline or resources required for the AWS migration. This confusion caused massive churn throughout the organization and many migration projects stalled.
“Clear Migration Strategy that stakeholders can understand and commit”
The key is to avoid stakeholder confusion. You need a clear migration story that stakeholders can understand and commit. Otherwise, your AWS migration project has good chance to fail.
#2 Analyze Analyze Analyze
Next thing you can do to fail your migration project is over analyze everything. This is easy to do if you are migrating large monolithic systems with little or no documentations. You can start analyzing at a high level like data centers then deep dive into servers, platforms, databases, applications, integrations and on and on and on. This type of analysis can take you a lifetime involving everyone in your organization. Once you run out of steam doing this, then you can debate every combinations of the migration strategies (aka “R” strategies).
- Retire
- Re-host
- Re-factor
- Rewrite
- Repurchase
- Retain
- Re-architect
- Every combination of above
Don’t forget to throw in some financial models. Finally, build a 3 year waterfall project plan.
You will find yourself in meetings all day with lots of spreadsheets and PowerPoint decks. Weeks and months or even years will go by. Meanwhile, you have not actually migrated a single app. Everyone will get tired of even talking about AWS. This is how you slowly burn out an AWS migration project.
“Bias toward action… Learn By Doing, not by analyzing”
Well, what is opposite of analysis paralysis? Action. Organizations who successfully migrate large scale systems starts with a small migration. Then they learn something. Then they take another action. Then repeat. It’s not that successful migration projects don’t analyze but try to avoid over analyzing. Instead, you should have a bias toward action. Learn by doing, not by analyzing.
#3 Culture Doesn't Matter
If someone asks you “What is your organization’s culture?” how would you answer? If you ask 5 people in your organization this question, how would they answer? If people give you blank looks or try to dig up some mission vision statement from orientation 10 years ago, then you’ve nailed this step. Bonus is if your leadership believes culture is just some fuzzy HR mumbo jumbo and believes best way to get things done is to drop decisions from a central command, then you got double points.
Culture is a set of beliefs and more importantly how people behave based on those beliefs. Long buzz worded mission vision statement is not your culture. Real culture sounds more like how you describe to your friend what it’s like to work at your organization. Sometimes there are cultures that nobody writes down but are very real like “Don’t trust leadership” or “Tribal knowledge is job security”. If this type of culture is prevalent in your organization, then be ready for a long and painful AWS migration.
“Culture is set of beliefs and behavior based on those beliefs”
The reason why culture matters in a large scale AWS migration is that it will be a major change to your organization. It will test your trust in others and question your own identity. Many will find themselves outside of their comfort zone. Your real culture, good or bad, will show its face and it won’t change overnight with a fancy kick off party. Because AWS migration is as much about change in people and process as it is about technology, you cannot underestimate the people transformation. As saying goes, culture eats strategy every time.
#4 Big Bang
A sure way to fail a large AWS migration project is to do it all at once as a big bang cutover. This strategy will maximize your risk. If you ever get to the big day and flip the switch, you will probably have to roll back. The team will lose all its mojo and may never want to try again.
Successful organizations chunk up the migration into smaller pieces. Often there is a period of time when your systems are running in a hybrid mode where some systems are on AWS while others remain on-prem. First, small and low risky systems are migrated. Then as teams mature, more critical applications are migrated to AWS. This strategy is less risky and allows you to course correct as you mature.
“Iterative strategy, not big bang cut over”
To use a golf analogy, a big bang strategy is like trying to hit a hole in one. Nearly impossible. Even if you have a perfect plan, you can rarely pull it off exactly as you envisioned. AWS migration is like starting with a putter and hitting a short but sure shots. Then as you gain more experience, you can take a riskier shots. AWS golf doesn’t penalized you for number of shots so take advantage of iterative strategy and try to avoid big bang cut over.
#5 DevOps Sucks
There are two types of people in this world. Those who write software code and everyone else. People who do production support, hardware and generally keep the lights on are all beneath the higher order species call software developers. They are solely responsible to write beautiful code that only works on their laptops then throw it over the wall to the operational team to take care of the rest. If this describes your organization, then your AWS migration project has good chance to fail and start an IT war at the same time.
DevOps is methodology that combines software development with IT operations to deliver solutions faster. The way you achieve this is often through automation of testing, build and managing infrastructure as code. In the DevOps model, one scrum team may own the whole stack throughout the life cycle including production support. The reason why DevOps is important for AWS is that the combination of development and operation is a very natural fit and sometimes even required.
For example, a scrum team wants to use a Lambda, S3 and DynamoDB in AWS. Who will build the environments and services? Who will write the code and how will they be deploy? What does code even mean in AWS? You will find that the traditional development and operation tasks are blurred especially if you are building a cloud native solution. Your current roles and processes may not make sense in AWS.
“DevOps matter and takes time to adopt”
You can also fail AWS migration trying to achieve too much of good thing. Here is a real story. An organization was operating in a very not-DevOps way with a proverbial wall between the development and operations. Software release was infrequent and complicated. Virtually nothing was automated in the infrastructure either. Software developers complained that it took forever for even to get a simple server. Operations team complained that the software developers were building applications that were impossible to support. The culture was toxic and things just crawled
So, when AWS initiative came to this group, leaders took it to an extreme and mandated that anything built on AWS should be “100%” automated or no way. They cited how other well known tech companies were deploying software continuously and iteratively. Great goal but challenging to say the least. First, team members didn’t even know what DevOps meant. Second, the teams, especially the software developers, didn’t have the skills to automate. Even when they tried, the monolithic applications had too much technical debt. It wasn’t even clear who is doing what in the new AWS environment. People were pressured from the top and felt uncomfortable stepping outside of their comfort zone. Many secretly wished that the AWS project would just go away. Given this reality, people started to bloat the estimate for even the simplest AWS projects. As result, anything that involved AWS become synonymous with “never going to happen” option. Migration failed.
DevOps matters in AWS. Be realistic about training and how quickly you can ramp up or acquire needed skill set. People changes take time and is not easy for large a organization. However, if you want to be successful in AWS, don’t underestimate the importance of DevOps.
#6 Technology Rules
There are so many services in AWS that it’s hard to imagine what you couldn’t build on it. You have virtually unlimited compute and storage. There are databases to fit every situation. There are machine learning and IoT solutions, the possibilities are endless. As you learn about AWS, you can just imagine your monolithic application transforming to a beautiful auto scaling cloud native architecture. You are so excited, you start telling everyone in your organization and next thing you know, you are migrating your systems to the cloud. Technology rules baby!
Then someone will come and ask some simple questions like, “What’s the return on investment for migrating to AWS?”, “Do I get new functionality or is it going to be the same clunky app in the cloud?”, “When do I get the features I asked for 3 months ago?” The point is, while AWS does have amazing capabilities, shiny technology alone should not be your reason to migrate to AWS. You should have a solid business case that shows real value to your organization. Otherwise, your migration project will probably be deprioritized and never get off the ground.
“AWS has limits”
Another trap is when you get too excited and ignore the realities of AWS. There are limitations and even downtime in AWS. These can be real problems depending on your solution. Also don’t assume everything will be cheaper in AWS either. Your monolithic application lift & shift to AWS may actually cost more because it can’t take advantage of auto scaling and other cost saving strategies. It’s good to be optimistic, but be sure to understand the limits of AWS services.
Summary
Well, there you have it. 6 sure ways to fail your AWS migration project. If you do one or more of these things, you are well on your way to a long and miserable journey ahead. I hope you learned something useful and wish you best. Thank you for reading.
Credit
Special thanks to following artists for royalty free images from freepik.com
- Designed by Pikisuperstar
- Designed by Rawpixel.com
- Designed by Iconicbestiary
- Designed by katemangostar
- Designed by Yanalya
- Designed by macrovector
- Designed by Freepik