The enterprise cloud migration path – there’s more than one way to make it
Dvir Shapira
8 min read
As part of our innovation processes at ET&I, we get to talk to many customers, partners, and industry disruptors. With the support of this growing community, we are getting exposed to innovative approaches across industries and geographies.
I wanted to take this opportunity to share some of what we’ve learned with regards to the different approaches that large companies are taking towards cloud migration, because it often felt very siloed. Each company is doing its own thing and it doesn’t feel like there’s a lot of knowledge sharing going around. I personally believe there’s an obvious value in learning from each other in this somewhat nascent space, as everyone is dealing with more-or-less similar problems and the innovation that’s taking place can help all of us move much faster.
In this blog I am going to share some of the best practices and innovation that we’ve seen across our customer base to help you find the best approach (or a combination of approaches) for you and your organization.
The cloud presents an lucrative opportunity for companies to accelerate their product delivery, to focus on their value adding technology more easily and not on the infrastructure, and sometimes even to completely reinvent their entire technology stack. At the same time, it also presents some major challenges with regards to people, processes, and technology that are holding many companies back from implementing the change that is required.
Based on the conversations that we’re having, to a certain extent it feels like, after over 10 years of public clouds becoming the mainstream, many large companies are still struggling with the right approach to be taken towards the adoption of cloud and cloud native technologies, as they are trying to find the right solutions to the challenges that the cloud brings with it.
For example, the impact on “people” can be in the form of entire teams that need to be removed or re-aligned. The impact on “processes and technology” can be in the form of having to reinvent development and deployment processes that have been used for years and having to replace existing tools with new ones. This is daunting change management process that can create a lot of internal friction as well as slow down adoption significantly.
The cloud providers usually put their customers on a maturity scale that starts with a “lift and shift” motion and ends-up with the complete adoption of cloud native technologies.
Figure 1: An example of the cloud maturity model(LinkedIn)
While this may be the case at times, when talking to cloud leaders of large companies across verticals, we’ve seen a few different approaches emerge. Some of which do not necessarily align with this model.
One of the major factors that impacts how organizations are moving to the cloud is whether there’s mostly a bottom-up pull, where developers demand to use the tools and processes that industry leaders and big-tech are using, or a top-down push, where BoDs and executive teams are demanding faster TTM and sometimes actually forcing cloud migration on their teams (in many cases both apply).
In many of the companies that we've talked to most of the applications are still these on-prem monolithic applications. In addition, much of the company's focus is on managing the infrastructure, while supporting its legacy apps.
In parallel, we are seeing teams developing new apps in the cloud, using micro-services-based architectures, and leveraging containers and cloud native technologies such as Kubernetes, serverless functions, relational cloud databases, etc. These teams tend to operate almost autonomously, figuring out the infrastructure and the processes as they go. For example, they might go out and look for a container security solution by themselves and the security team might only be lightly consulted or even just informed. This might be a step in the way to full cloud migration once the company hits a certain “critical mass” of cloud native applications, but it’s hard to tell, as these teams sometimes don’t get a lot of exposure or support internally.
This is the exact opposite side of the migration spectrum. Some companies make a company-level decision to migrate everything to AWS/Azure/GCP and optimize for the cloud using cloud-native technologies. In many cases this decision also involves a strategic partnership with one of the cloud providers and a multimillion USD commitment on the company’s side to a multi-year partnership.
In many cases, such a commitment is required since the company is investing a lot of resources in cloud-specific technologies, such as AWS RDS or Lambda functions. This investment can usually pay off through significantly accelerating development and deployment but, on the flip side, the result is a vendor-lock that is put in for years to come.
Additionally, we’ve seen companies rearchitecting hundreds of applications with the intent to launch them all at the same time. This obviously requires a herculean effort in development, testing, operations, CI/CD automation, etc. It also requires the team to put together a whole new set of processes and tools, some of which are being delivered directly by the cloud providers themselves, but some are either open-source or 3rd party. This is the most challenging approach, but it takes the company from zero to a hundred in a predictable time frame.
This is a more toned-down approach compared to the full-scale approach and might be more digestible for many organizations. This approach is usually also top-down, which means that the BoD or the executive team decides to “force” cloud migration, but they are willing to accept a phased migration where many apps might not eventually be migrated at all.
Taking this approach, usually all new apps are developed on the cloud of choice (might be single or multi-cloud), optimized through using cloud native technologies, but legacy apps are not necessarily migrated. If they do get migrated, this might be in the form of “lift and shift” or a complete re-architecture, depending on the application’s importance and complexity.
In most cases, there would be a chief cloud architect who would be making the final decision on what gets migrated and how. The chief cloud architect is also in charge of implementing the new processes, tools, and the organizational changes required to support the cloud native deployment.
This is probably the most innovative approach that we’ve seen, that somewhat serves as an alternative to the limited top-down approach. Taking this approach, a dedicated team builds a “cloud migration infrastructure” that allows application teams to connect their legacy applications and gain some of the benefits of a cloud native environment. Such benefits might include improved visibility, higher development and deployment velocity, better logging, etc. This infrastructure also serves as a way of standardizing the interfaces for dev managers and executives, while abstracting the actual application layer below.
In addition, this approach allows the organization to migrate at a controlled pace while getting some of the benefits of both worlds – the investment is significantly lower, as the company doesn’t have to re-architect all of its legacy apps, and, at the same time, they get some of the key advantages described above across all of their apps, legacy or cloud-native. This approach is starting to show up in organizations that have hundreds of legacy apps and are looking for ways to lower the investment without giving up on being able to move faster in the cloud-native era. That being said, we should bear in mind that building and supporting such infrastructure might be hard and there needs to be a clear incentive for teams to get engaged in the process, as there’s some effort that’s required on the legacy app team’s side to get integrated into this new infrastructure.
So Which Approach Should My Organization Take?
It depends on the many factors that impact cloud migration. Such factors might include:
There is no textbook solution to this problem but considering all the above factors and approaches might lead you to design the right approach for your organization.
We at Cisco ET&I would love to get your feedback and learn about some of the approaches that your organization has taken (and potentially share them with our readers here). Finally, we are always looking for new design partners to test our innovations and help us build the right products for you going forward.
Come check out our innovations at Cisco's Emerging Technologies & Incubation or join our design partner community.
