As an AWS consultant, I’ve had the opportunity of working with dozens of organizations ranging from small start-ups to enterprises among the Fortune 500. As I look back on some of the experiences I’ve had helping customers migrate to the cloud or adopt more cloud-native architectures, I’ve seen a lot of recurring patterns and obstacles that have made these efforts much more difficult than they needed to be. There is much more dysfunction and chaos out there than I would have ever imagined.
At 1Strategy, we often make the observation that people are frequently the blocker more than the technology itself. When a client asks whether something can be done, often the answer is: Yes! The technology is adequate and will meet your needs, but will your organization be able to pull it off?
While I could probably list more than a hundred of these, I’ve chosen to write about eight things that frequently present themselves as organizational obstacles throughout the course of a cloud migration:
1. Not Knowing Why
You want to move to the cloud? Great! But why? If you can’t answer that question, maybe you shouldn’t.
Bad reasons:
- Because that’s what people do these days, including our competitors.
- Because we want to modernize things a bit.
- Because we heard we might be able to save some money.
Good reasons:
- We need the ability to scale our e-commerce application 100x during peak seasons and events.
- We’d like to reduce our operational burden by leveraging managed services that allow us to focus our efforts more on what we’re best at rather than wasting our time patching servers and learning how to setup database replication for increased availability.
- Because features such as auto scaling would allow us to right size our servers and save 30% over the course of a year.
The good reasons often involve increased agility, scalability, availability, disaster recovery capabilities, and an enhanced security posture.
At the same time, it’s important to know HOW to migrate in order to achieve that goal. If you’re picking up everything in your data center and just dumping it in the cloud expecting to save some money without making any alterations to your workloads, you could end up actually spending more in the cloud (this happens more than people realize). You’ll want to choose the right migration strategy to support your objective. The cloud should not be treated as simply another data center.
2. No Buy-in From the Top
Assuming you know why you want to migrate, you need buy-in from senior leadership. Without that, the effort is doomed to fail. Migrating on a large scale is often a much larger endeavor than people realize. In a lot of cases, it requires an entire organizational transformation—and I’m not exaggerating.
What’s needed is one person at the highest level possible of the organization who will own this initiative and who has the authority to remove the roadblocks that will inevitably come your way. Identifying one person also prevents a “diffusion of responsibility” scenario and results in holding someone accountable for making the migration successful.
You also need alignment from the top down, including middle management, where the signal tends to degrade. They need to be on the same page and support the effort. This can be challenging. AWS has, at times, referred to this phenomenon as the “frozen middle,” where middle managers often slow or block efforts to transform the organization. It’s often at odds with other agendas or a complete conflict of interest for them. Beware!
3. Insufficient or Blocked Executors
Who are the hands-on executors of the migration? Do you have enough of them to support the endeavor? Do they have the right skill set? Are they sufficiently trained? Is ongoing training being provided? Have they had the opportunity to learn best practices or will they be picking it up along the way and later regretting how they architected things before they had a good sense of how the cloud worked?
I have seen engineers who are months into a migration and still struggling to understand the difference between an AWS region and an availability zone, something that could have been learned through a basic AWS course beforehand. Ramping up your team on technologies—that didn’t even exist until very recently—will cost you less than the amount of rework required later on.
Assuming you have the right team and skill sets in place, get out of their way! I can’t tell you how many companies I’ve worked with that seem to strap handcuffs on engineers, eating away at their productivity every day. One example: in order to learn, experiment, test, and build things in the Cloud, engineers will need access to some sort of “sandbox” environment within which they can tinker and break things until they get something working. That is how one learns. What shocks me is how often this environment is locked down by a security team to the point that it’s essentially useless. This environment should be as wide open as possible. People often grant a narrow subset of services or allow everything but identity and access management (IAM) functions, but guess what? IAM Is required by nearly every single thing in AWS.
If we think through some of the concerns of granting engineers or developers broad access to a sandbox environment, they often come down to security and cost. Those are easy problems to solve. Disconnect your sandbox accounts from production networks and customer data, and create automated billing alarms to keep an eye on costs. Many tools also exist to tear down these environments nightly, where appropriate, which cuts costs even further.
4. No Technical Leadership
While it’s great to have buy-in from the top and strong leadership to push things forward, some kind of technical leader or cloud architect is still necessary. Thousands of questions will come up, requiring complex decisions to be made so far as architecture, standards, integrations between different systems, and what technical strategy to pursue. For most organizations, these needs simply cannot be met by most people in senior leadership positions who either don’t have a technical background or are unfamiliar with the new world of cloud.
If it isn’t clear who will serve in this position, often times it is partly fulfilled by some sort of group or board, such as a Cloud Center of Excellence (CCOE). This group, however, must have enough cloud experience in order to really support the needs of the organization and point others in the right direction.
A big part of what this technical leader or group will do is define standards. For example:
- What kinds of architectures do we want to use? Virtual machines? Containers? Serverless?
- How do we want to deploy databases? Are we using managed services such as RDS? What flavor of database do we want to move towards over time?
- Are we building our infrastructure with code? If so, are we using CloudFormation? Terraform?
- What will CI/CD look like?
- What security policies and standards should we create? What will we encrypt? How is data classified?
These are some of the questions that everyone will be asking, and without answers they will simply decide on their own and build things how they see fit. Over time, you’ll find that each team is reinventing the wheel and increasing the burden of operating, monitoring, and securing workloads due to the dozens of approaches that emerge.
It should be clear what standards exist, what is left up to individuals to decide, and what is still being decided.
5. A Broken Organizational Structure
This is perhaps the most challenging aspect of cloud migration and readiness. As mentioned earlier, migrating often requires a complete organizational transformation, which can be very difficult to pull off. The larger the organization, the harder this is to do.
Before migration, core departments may be structured like one of the following:
- Laterally: developers on one side and systems teams on the other.
- Top down: architects, engineers, and then those in operations.
- Matrix: individuals reporting to multiple people.
And, of course, many are using a combination of these as well as any number of additional functions such as network designers, DBAs, security and compliance, data & analytics, and so forth.
Thought should be given to how the existing organizational structure will evolve to support the end state of migration where technology will be developed and maintained using an entirely different paradigm. What does that end state look like and how are teams structured leading up to that point during the migration process? Will the same departments continue to exist? How will overlapping functions be resolved? Often the question comes up as to whether the organization will embrace a “DevOps” culture as it moves forward, but the definition and specific application of this buzzword is often debated.
Conway’s Law is an “adage stating that organizations design systems that mirror their own communication structure.” If your technology is transforming, it’s likely that your organization will too. Navigating these changes can be extremely painful and it’s been my experience that it often results in the loss of good talent along the way that simply didn’t know what their new home would look like, often due to: a breakdown in communication.
6. A Breakdown in Communication
With so many moving pieces and a constant flux of people, ideas, and information, it is critical that communication flow constantly in all directions.
First, communicate the WHY. I have had customers that found out months into a migration that the reason for moving to the cloud was scalability, yet none of the migrated applications were designed with this consideration. No auto scaling, no CDN, nothing.
Keep it simple. You don’t need to form a committee that approves another committee that puts together a “communication plan” and revises it three times and ultimately buries the most important information at the bottom of a newsletter that gets scheduled to be sent out once a week and links to a password-protected portal with subsequent navigational menus to simply tell someone that all S3 buckets must be encrypted or that CloudFormation is a standard. Just put together an email distribution list with everyone working on the migration or create a Slack channel and drip…drip…drip. Communicate everything and do so often, especially the challenges that you’re encountering.
It may be necessary to create a safe environment where people feel free to express their ideas and collaborate on things across departments and up and down the chain of command. Remove expectations like having to come prepared with a fully vetted slide deck in order to talk to an aloof executive whose time is precious. There are a lot of unknowns and it takes time to hash things out and get to the right answer.
If you don’t know something yet, tell people. Silence can result in a lot of fear as people wonder what the future holds for them once the migration comes to an end.
7. Underdeveloped Project Management
Tactical execution from week to week requires a solid project management capability. We see a lot of variation out there in how projects are managed, tracked, and reported. Some companies find that migrations are a good time to finally embrace more agile methodologies. This can mean not only learning a new approach to IT (cloud), but a completely new approach to work itself (e.g. Scrum). It can be a lot to learn at the same time.
Here are a few things I’ve seen organizations struggle with:
- Having no project manager, scrum master, or product owner whatsoever.
- Having all of those roles plus five others with all sorts of complicated reporting structures and redundant paperwork.
- PMs that act more like a babysitter and exist solely to report updates to project management offices rather than helping steer the team in the right direction, stay on task, and resolve blockers.
- Lumping all the work into a small handful of large tasks in Jira that represent days worth of work and don’t provide any visibility into progress.
- Not identifying who is working on what.
- Obsessing over tickets rather than the actual work behind those tickets. I’ve seen people get upset because more work was done than expected because it resulted in additional tickets getting created in Jira during the middle of a sprint, which throws off their lovely burndown chart.
8. Lack of Prioritization
It needs to be clear what the organizational priorities are, and time needs to be allocated for each. If you can’t seem to get enough people together on a consistent basis to talk through cloud standards, architectures, and migration strategy details because they have “day jobs” taking care of what they were doing before the migration started, or they’re distracted by production issues, then it’s going to take a lot longer than you think and you’re going to make decisions without sufficient buy-in from all involved.
If you form a CCOE, ensure that everyone has availability to give it the attention it deserves.
What To Do About These
Much could be said about how to resolve these kinds of obstacles, but I think it’s more important to first figure out which ones your organization will struggle with. Often you simply won’t know until you get started. What can help, though, is dipping your feet into the Cloud and seeing what happens.
In many cases, we help customers get started in AWS with a proof of concept (POC). We like to think that not only does this help people try something out and see whether it’s technically feasible, but it also serves as a litmus test for the organization itself, revealing the potential obstacles that may surface during a full blown migration. If you’d like some help putting together a POC or are struggling to overcome some of these obstacles, feel free to reach out at info@1Strategy.com and we’d be happy to help you navigate them.
Conclusion
Migrating to the cloud is a significant technical endeavor, but it’s often these organizational pieces that require the most attention to ensure a smooth and successful transition. Best of luck!
