Video Series: The Cloud Migration Journey

Introduction

In this new video series from Levvel, our industry experts discuss where organizations should start if embarking on their first migration journey, ways to get unstuck, and how to gain buy-in when faced with internal resistance. We share relevant stories from the field and how we’ve helped businesses overcome their biggest challenges.

For more videos from our experts on cloud adoption, check out Levvel’s The Enterprise Value of Cloud Migration and Challenges and Solutions to Successful Cloud Adoption series.

Episode 1: Where Should I Start if Embarking on My First Migration Journey?

Episode 1 Transcription

Srinivas Coimbatore: It’s very important as you formulate your cloud migration journey that you answer two very simple questions. The first question obviously is, why? Why are you looking to migrate to the cloud? And typically, this could be for any number of reasons.

Some may be motivated by the fact that the cost model is very different when you look at on-prem versus cloud. Certain others may be interested in the elastic nature of cloud and others may also be looking to use the cloud because they’re expanding into markets different from where they were set up physically.

All of these motivations may be why you’re looking to migrate to the cloud. But again, it is very important to understand that there are many different teams involved in any sort of an endeavor and quite possibly, most of these teams are going to be impacted by this decision. So take the time to go and talk to those teams, understand what are their challenges in the current environment, and what they hope to address by migrating to the cloud.

Now, by doing this and collating all of this information, you have a more cohesive business argument that addresses many different angles. And therefore, when you present it to the management team, it seems more complete in that sense. So now that you have a good “why” you now have to understand the “how”. How are you going to realize that outcome of migrating to the cloud?

Samantha Rafalowski: A lot of people, when they are first visiting cloud migration, the logical first question they ask themselves is, where do I start? The first two pieces which really play off of each other are education and the migration plan itself. So obviously in order to come up with that migration plan, you have to back that with education for yourself. First of all, you need to know about what platforms currently exist as your options for migrating. These typically come into three categories, which I’m sure at this point, most of us have heard of. IaaS, PaaS, and SaaS.

So, that’s Infrastructure-as-a-Service, Platforms-as-a-Service, and Software-as-a-Service. Infrastructure-as-a-Service is going to be giving you the most low-level access and control over your actual resources and infrastructure. So, this is going to be something like Amazon’s EC2, where you can manually configure all of the resources yourself. Or Amazon’s S3, that’s a storage service.

Again, it is managed in the sense that it’s on Amazon servers, but you get control as to who has access, where those buckets are, et cetera. For Platforms-as-a-Service, this is going to be a little bit less low level. If managing all of that infrastructure and resources is not for you and that seems like more machinery than your company needs to handle, that’s totally fine. And this is a great option.

So, Platforms-as-a-Service that are most common are AWS Elastic Beanstalk, or Heroku, where you can upload an application, and then behind the scenes, that platform will automagically configure your infrastructure for you. And then, finally, Software-as-a-Service is going to be a managed software service, just as you would expect. This is something like Splunk, a third-party service that offers logging, managed logging, for you and your applications.

Understanding the platforms that exist, the difference between IaaS, PaaS and SaaS is super crucial to coming up with this migration plan. You need to know what your needs are and what makes the most sense for your team. That also includes educating yourself on the team dynamic and what processes currently exist within the software development life cycle process, if any. This is a great opportunity to find where the roadblocks are and some of the issues that are not working as well as they could be for your team.

Understanding exactly how the software and applications that you currently run are being managed is super crucial piece of the education portion. Just because something is a best practice or a super ideal solution, doesn’t mean that it’s going to be a great solution for your business, depending on how it runs and what the team dynamics look like. So the first piece is, educating yourself on what exists out there and what strategies are going to work best for this kind of team, for this kind of workload, specifically.

Srinivas Coimbatore: There are many areas that you need to address when you think about “how”. First and foremost, what does your roadmap look like? Set up some realistic timelines. What do you plan to achieve by when? And a lot of this, when you look at a roadmap, you’re thinking of so many different factors. One is, how are you going to enable this environment in the cloud?

Think automation all along. And therefore, you need to understand that if you’ve used certain automation stacks for your on-premise infrastructure it may or may not work in the cloud environment. So you need to understand how you’re going to address any sort of skills or knowledge gaps, if there were any in that space. Now, you have a roadmap and some timelines. You have to incorporate certain committed business guidelines. For example, there may be security and compliance related challenges.

How are you going to incorporate that? When are those teams going to be included into your process? Typically, to include them, right at the start is always a good idea. If they have gaps in terms of experience or knowledge, it’s always good for them to be involved right up front so they can understand what is the ask and therefore find a way to address it. So you now have a roadmap and have enrolled the appropriate teams.

You also, through these conversations, possibly understood what some of the knowledge and experience gaps might be. Be it amongst the development teams, the test teams, the infrastructure teams, the production teams, and so on. So, find a way to address that. Sometimes it may be organically by organizing your training sessions.

There may be certifications that the team members can take, but also try to augment that with some external help. That is usually a good way to kind of jumpstart this whole journey. Remember that no matter what all of this looks like, depending on the organization and its structure, you are going to succeed only when you secure the necessary buy-in. And that buy-in is not just from your manager or your management team, but it may be also their peer managers. So be ready for that journey as well.

Samantha Rafalowski: And once you have a better understanding of that, you can start creating your migration plan. In the migration plan, you want to keep in mind everything that you’re going to have to end up implementing. Ultimately nothing should be an afterthought. This should be as detailed as you can possibly make it. You’re going to include a security analysis of anything that really needs to be locked down in your infrastructure.

How are you going to lock that down? How are you going to make sure that your data and your workloads are protected from the public? And then next, you’re going to look at the management planning itself. So who is going to be the owner of these services? Who’s going to make a change, if something fails? How are you going to make these changes if your application fails?

You need to consider all of the possible scenarios that can happen once you do migrate and figure out how you’re going to address those. And that’s the best way to avoid getting stuck when you’re migrating, is to go in with a really firm plan.

Another piece of the migration plan is a risk assessment, which falls into what I just said. So with risk assessments, you are going to want to think of all of the possible pitfalls, everything that could possibly go wrong with your migration and how you’re going to address it. That way you already have a plan. And finally, you want to think about your budget and you want to think about your rollouts.

The budget is pretty self-explanatory. This is probably going to be a number that you’re going to get from either someone higher than you. Or maybe it’s a number that you know, because you are the person in charge of finances, which will be great in helping you figure out exactly what strategies you can use.

What’s going to be overkill in terms of services, but also what’s going to be the bare necessities. So balancing what you need with what’s possible within the budget. And then lastly, the last part of your migration plan is when everything goes well, you’re going to ultimately have to roll out the new cloud migration.

If your application is something that’s super business critical and is used every day, you need to think about how is the best way that you can roll that out? I like to suggest blue-green deployments. This basically means that you’ll have your old applications still in use and slowly over time. As you become more confident that your new application migration is working just as you expected, you can roll over traffic until eventually all of the traffic goes directly to your new application.

It is possible to do all at once deployments for less business-critical features, but there are different options depending on what your workload is, how often it’s being used, et cetera. But that is the last and arguably most important piece of the migration plan. Once your application is up and running, how are you actually going to get it into commission? Those are the things that you need to be thinking about when you are educating yourself and coming up with a plan on how to migrate.

Episode 2, Part I: What Are Ways Organizations Get Stuck While Migrating to the Cloud?

Episode 2, Part I Transcription

Srinivas Coimbatore: A cloud migration journey can be a challenging one for many organizations. When you’ve worked with quite a few, you start to see a certain pattern emerge. I would say the top five challenges we’ve encountered are typically around selecting the right workload that you want to start migrating to the cloud. That might be one area that you’re challenged with. In terms of workloads, what we typically encounter is they pick a workload that is critical to the organization.

There are possibly certain commitments already made by the business to the outcomes, and the workload is being constantly enhanced. Now the development, test, and deployment teams have to figure out where to deploy these updates to. Is it going to be on-prem? How are you going to move this? And therefore, as you attempt to migrate, you’re going to face challenges in sort of a moving target, if you can see that.

Another area that relates to workloads is they pick a workload with many dependencies. So maybe there are multiple systems that the workload has to connect to, to complete a transaction. And if you’re going to pick that up and migrate to the cloud, you have to understand that all of these other systems that it has to connect to, to complete a transaction, are still on-prem. And therefore, there’s a lot of back and forth. They can be performance-related challenges and so on. So when you talk about workload, that is typically the two areas that we’ve seen teams face challenges. So that’s challenge number one.

Number two is unanticipated challenges. Whether it be in terms of working through your roadmap, you’ve now encountered a challenge where you have to use a cloud-native offering, a managed service, for example. But you’ve never worked with it. And you’ve worked with its clone, or it’s a lookalike on-prem, but the offering from a public cloud provider is very different. So it is important to understand that they can pose significant challenges. And if you’re hitting quite a few of them, you’re probably working with a team that is not quite there to meet the knowledge and experience asked that is required.

Typically, our guidance has been to work with a good consulting partner. It may be some relationships that you already have in place that you can use. Maybe you can look at your cloud provider and see if there’s a network of consulting partners that can help you. Typically, those are the areas where you’re going to quickly find the necessary talent to be able to continue to commit to your timelines and deliver.

Now, when you get into certain other areas like competing timelines or priorities, that is something that you should anticipate. Whether you encounter it within the first month or the first few months, it’s going to happen. Business is not static. The markets are not static.

Typically, the third way you can get into trouble is you start your journey with some commitments to headcount, to budgets, and so on. But over a period of time, there may be certain opportunities or challenges that need to be met immediately that aren’t quite aligned with your migration plan. And those budgets and the headcount might need to be moved out.

Typically, those sorts of priorities and dependency challenges should be anticipated. So being sure to understand that you have a good plan, a good roadmap that can adjust to these challenges by either trimming down what you can get done within a certain window of time and therefore adjusting your success metrics, as well, would be wise.

The fourth area that we’ve typically seen some challenges with are around licensing. There are certain enterprises that have site licenses for certain products and solutions, and when they go to the cloud, they may or may not apply. Be sure you have those appropriate conversations ahead of time.

So if you have a dependency on licensed software or even support, for that matter, make sure you have the same level of support and that your licenses are valid in a cloud environment. And if they’re not, have those appropriate discussions very early on, so you’re not challenged by it because it involves procurement, budgets, and so on. Therefore, that can be time-consuming and a challenge if you wait long.

The fifth area that we’ve seen teams encounter challenges is security and compliance. Typically, the issue is that the security and compliance postures are very well defined on-prem. Now they’re going to be asked to operate in an environment that they may not be entirely familiar with. So include them right at the start of this entire process, right from the planning stages, so that they can find ways to understand this environment better.

If they need certifications, they can work towards that. If they have gaps, that is another area where you can look at external help to address. And a lot of this takes time. So make sure that you’re very realistic in your timelines and you have the appropriate buy-in from all the teams. That way if you do face any of these challenges they are very supportive and you are able to find a plan that addresses that challenge.

Episode 2, Part II: What Steps Should Organizations Take to Get Unstuck Along a Migration Journey?

Episode 2, Part II Transcription

Samantha Rafalowski: Another question that many people have when migrating their workloads is what are the action steps to take if you get stuck? Getting stuck when migrating is pretty common, especially if your migration plan is not super bulletproof and it’s easy to let some things slip through the crack. What I suggest when people get stuck in migrating is not to completely start over, but to reeducate yourself on what the current problems are because that helps you to find better solutions when you firmly understand what the exact problem is.

The first piece of that is reassessing some of the remaining workloads. You are going to want to make sure that you are focusing on the core foundational workloads that need to be migrated. A lot of people when migrating try to save these big legacy applications for the end, partly as a procrastination piece, partly because they want an example of something that’s a little bit simpler being migrated first. That’s totally understandable and there’s no need to migrate your legacy applications first and foremost, but eventually it does need to happen if you are trying to become fully migrated to the cloud, which is what I generally recommend to my clients.

This is because a lot of times hybrid-cloud scenarios end up being way more expensive than fully cloud-native applications, or any other cloud-native workloads. And even sometimes on-premise workloads. You have to be really careful about assessing your workloads and making sure that the right ones are being prioritized. And in doing that, the questions you should ask yourself are, what do I need to host this in terms of infrastructure, in terms of budget? Where are the current roadblocks? What is going wrong with your application or workload as it is? What exactly is failing? What isn’t working as well as it could be? What is causing inefficiency? Et cetera.

Then you need to figure out, given what I need to host this and what the current roadblocks are, what are the knowledge gaps that I have? What exactly do I need to research next? You want to do your research on your current workloads hosting needs, what the roadblocks are and how you would mitigate those, and then what would make your application or pipeline better or more efficient.

This could be looking back at those platforms we mentioned earlier, IaaS, PaaS, and SaaS, or it could be really just any third-party applications that you hear about. I mentioned earlier Splunk. If you have some sort of an issue that you can’t potentially, if you have difficulty debugging, getting a really granular logging service is going to be helpful for you in the future.

After reassessing your remaining workloads, you’re going to want to go back and adjust your migration plan accordingly. Intentionally migrating to a hybrid cloud environment, as I said before, can result in more complexities and a much higher cost than others. You want to think about where your migration plan is headed according to the current issues.

We’re going to revisit that migration plan and you’re going to think about the security analysis, the people who are in charge of managing and maintaining this infrastructure once it is deployed, the correct environment selection and design, risk assessment, and rollout. Those are the main pieces that I like to consider.

Another portion that people tend to get stuck on when migrating to the cloud is the security and disaster recovery portion. Taking into consideration the security and compliance pieces of the migration pie can really help you get unstuck when you are migrating. A lot of the networking and security pieces that you need to do, so for example, are you going to host your application in a virtual private cloud? Do you need to encrypt your data at rest and in transit? If so, how do you do that? Where are you storing your data? What is the cost of doing so?

All of these very specific questions that we like to often leave out until we get the basic strategy completely lined up or sometimes we’ll start migrating before we even lock down our environment. And this can be a really easy pitfall to avoid if you will just consider these pieces as you are implementing the infrastructure.

And lastly, a way to consider these pieces while you are implementing this infrastructure is to automate what you have currently. Automating infrastructure, while it can be a bit daunting at first, especially if you don’t have as much experience in Ansible, Terraform, or Chef, Puppet, really all of these infrastructure scripting languages, if you don’t have experience in it it’s easy to want to avoid it. However, once you automate your infrastructure, it makes it way easier to make changes later on, to make improvements, and also even to make duplicate environments.

If you want a disaster recovery plan and you can afford a disaster recovery plan, that is a fully replicated environment of your core functionality to your business, then automated infrastructure is the way to do it. Because if you already have that infrastructure deployed, all you have to do is deploy the code that you already wrote again and then you have a fully replicated functional environment of your application.

Automating infrastructure can really help to make your application and workloads more resilient and self-healing. And in doing so, you’re able to find some of these pitfalls, avoid them and make little tweaks to your environment portion by portion while seeing how it affects the whole infrastructure at once.

Instead of having to try to think through everything in the very beginning and make sure that it’s perfect on the first deployment because a lot of times that’s not possible. Automating infrastructure really helps to make it easier for you to successfully migrate your application.

Episode 3: How Do I Gain Buy-In From My Organization?

Episode 3 Transcription

Samantha Rafalowski: Once you have researched your cloud migration plan and you feel good about action steps, sometimes you are still stuck because you don’t have proper buy-in from your organization. In order to get buy-in from your organization, the first, most important part is to diagnose the heart of resistance.

Why is it that people are not interested in migrating their workloads to the cloud? In our cloud management survey, we had about 47% of respondents report that migrating to the Cloud is only a low-to-mid priority for their leadership team. Diagnosing exactly why that is the case, or may be the case for your company, is definitely the first piece of being able to gain some support from leadership in terms of time, money, resources, et cetera, to really kick off the migration process.

Srinivas Coimbatore: Typically, when we talk about buy-in, we think it is buy-in from your manager, maybe your manager’s manager, and somebody further up the organization chart. That is a good place to start. It’s always good to secure that sort of buy-in, but the challenge is usually that any sort of cloud migration journey impacts a whole host of teams. As you engage with these different teams, always try to record what their challenges are today. And as you have those conversations, always try to respond with how can you, by migrating to the cloud, address these challenges.

And be realistic, obviously, about this whole thing. Eventually, as you come up with a roadmap, as you come up with a timeline and probably the necessary asks of budgets and so on, be sure to secure this buy-in, not just from your manager, but also peer managers, as you work through this process. There’s that entire management team buy-in that you’d have to address. And typically, that’s around the macro challenges of budgets, costs, timelines, et cetera.

Anna Barnett: How can you get buy-in to migrate to the cloud? I think that’s a big issue for companies today, especially across different industries where they might not be as technologically progressive, or digital transformation isn’t a top priority, or maybe they don’t understand it. I think you’ve got cultural issues there as far as how they really see initiatives around technology versus focusing more on the product or the customer experience.

One big thing you can do there, though, is educating everybody on how that all is a holistic issue and very much tied together. The stronger your technology, the stronger your product, the better your customer experience. And when you pair that sort of best-in-class technology goal with best-in-class customer experience and things like that, that’s when you’ll start to really see customer and market success. Illustrating the business value of cloud migration is going to go a long way to gaining buy-in.

I think it’s also important to note that a lot of companies’ cloud migration projects have been accelerated this year so as to enable suddenly remote workforces. So to some degree, I think we’re going to see a lot of companies have kind of forced migration, and you’re probably going to come up with some resistance to continue because it may not have been done in the best way possible because you had to rush it.

Samantha Rafalowski: Once you are able to figure out exactly what is holding leadership back from wanting to go ahead with cloud migration, it’s important to come with support and a plan. This migration plan is a part of it, but migrating your infrastructure is not something that you can do by yourself as an individual.

A lot of times, it’s not even something that one specific team can do because cloud management should really be throughout the entire organization instead of siloed onto a specific team. Make sure you come with support, other people who are invested in the success of your migration plan, who may be able to help you either gain that leadership approval or help you with the actual technical implementation and process of the migration. Both are equally important.

Another way to gain support is to build a POC with really anything that you have a current bottleneck with. So, the best way to show the benefits of cloud migration is to actually build out any sort of proof of concepts that can demonstrate your point. For example, if you’re lacking a software development life cycle methodology, maybe build something out like a pipeline to show how quickly you can deploy code. Also, you can build out a return on investment to show the metrics and cost savings that are possible with a full cloud migration.

Really, the only way to guarantee support is to show hardcore proof just like in most things in life. And that’s totally possible thanks to AWS and Azure. Building out a POC on a smaller scale is something that you can probably do in a couple of weeks and ultimately will help you gain a lot of support and even excitement about the potential your cloud migration can have on the impact of the full company’s business functionality, efficiency, ability to deploy code, make changes for your customers, et cetera.

Srinivas Coimbatore: Also, as you secure your buy-in, you have to understand that the developers, the testing folks, the architects, the security, the compliance, the production support teams, also need to be included. So why do you have these conversations? Remember to have the conversation with the individual contributors, but also have conversations with the concerned first line, second line management teams as well, because you’re going to get a very, very different perspective from both of those areas.

And as you attempt to secure the buy-in, understand that things like timelines, the technology stacks, the ask, the knowledge, the experience might be lacking, and so you might have to have certain kinds of conversations as you start this journey. So there’s this whole buy-in that you’d have to address, not just from the management side of the house, but also the individual contributors from the development, testing, production, and support teams.

Now, it is also important that as you work through these challenges, you’re going to find out that these challenges don’t magically go away once you start your journey. You’re going to have to realize and adjust as you go through this journey. For example, having lunch-and-learn sessions over a period of time or having chapters that bring together folks who are trying to address similar challenges.

Also, the build champions within your teams, as you try to find a way to distribute the knowledge and experience, is going to become critical. So again, there is no simple solution to this challenge, but these are some of the ways that we have found and assisted our clients in securing the necessary buy-in and starting and executing a successful migration journey to the cloud.

Samantha Rafalowski: It’s important to allow leadership and people who are stakeholders in this to see and get excited about the cost savings, get excited about the potential of self-healing environments. No more calls in the middle of the night for you to fix something that’s down. So really just making sure that you can figure out exactly why people are hesitant to migrate and then use that as a reason, show proof why their concern doesn’t need to be as big of a concern as they think it does.

And in fact, their concern is overshadowed by the benefits of the cloud. And then you have proof. And once you are able to deliver those things to leadership, it is pretty difficult for someone to deny the positive effects that a migration can have on your business.

See more from our experts:

• Read: 2021 Cloud Technology Management Insight Report
• Read: Nurture and Realize a Successful Cloud and DevOps Adoption Strategy
• Watch: Digital Innovation and the Cloud