Cloud Migration and Modernization

Jonathan Allen:
Welcome to Conversations with Leaders. My name is Jonathan Allen, I'm a director in the enterprise strategy team at HAQM Web Services. I'm joined today by my colleague, Jake Burns. Today we're discussing cloud migration and modernization. Jake, do you want to introduce yourself?

Jake Burns:
Yes, thank you, Jonathan. My name is Jake Burns. I'm an enterprise strategist here at AWS, and I've been in this role just over six years. I've engaged with over a thousand customers in that time, and many of those engagements have been on the topic of migration. So I'm really excited to have this conversation with you Jonathan, and share some of the lessons learned throughout the years.

Jonathan Allen:
That's amazing, Jake. And I think combined, I think we've had the privilege of working with over 2300 customers, and I know both of us were obviously customers ourselves who handled large migrations and modernizations before we joined HAQM Web Services. Now, both you and I have been leading in this space now for over 10 years, and I don't want to dwell on so much of the reasons why customers migrate. I think that's very, very proven now, millions of customers using AWS. I want to jump straight into the lessons learned in this conversation, Jake.

And you and I are very privileged to have those conversations. People ask us for those lessons learned all the time. And if you think now back, both from your own time as a customer, but also your time working at HAQM Web Services now for a number of years, what are the top three things that leap out of you? I want to cover those. And then I want to sort of move into this practical advice on some of the myths that people have around migration. So what's the top three things that sort of leap into your mind?

Jake Burns:
Yeah, if we're talking about migrations and transformation in general, I think this applies as well. If we think about what I did leading a successful migration back in 2015, 2016, and the customers I've worked with since then that have been successful, one of the things that surprised me in the beginning in this role was really how few engagements it took to see these clear patterns emerge. In other words, they're not as unique as I imagined and as most customers imagine that they are. Their situations are all quite similar in terms of what works and what doesn't work. So I'd say the biggest thing, and it's really hard to pick a number one, but I'll say getting started before you feel ready. I would think is really the one thing that most of the customers that have been very successful, myself included, and I think in your case this was also true, was we didn't wait until we had a perfect plan in place to start migrating.

The customers that do that, they end up wasting months, sometimes years in those planning phases. And then once they get started, they realize that they need to throw the plan out anyway because they learn their expectations and their plans meet reality and they learn by doing how to actually get it done. So my suggestion is to kind of just skip that planning as much of that planning as possible and really get started. And there's ways you can do that in a very safe way that hopefully we'll get into a little bit farther in the conversation. I'd say number two is really investing in your workforce. And that includes getting buy-in from them. So the customers that are most successful, the ones that actually use their own employees and get their employees invested in the migration and the transformation. And then when it comes to number three, I would say simplicity. Keeping it as simple as possible. So going fast, which is major theme and kind of the methodology that I advocate for. And in order to go fast, you need to make things simple because complexity slows you down.

Jonathan Allen:
Love it, love it, and stop before you're ready in particular really resonates with me. I think one of the things that I do ask though customers and from my own time is, does your leadership team understand why you're doing this? I think if there's a relatively junior team that just think, “Hey, let's do this.” And that conversation with their executive team hasn't occurred, then you're going to get some friction. So for me, I think I love start before you're ready. I love the simplicity, but also, do you actually understand your why? And we said right at the start, we're not going to go deep into it, but there's so many good why's.

What's your North star why? Is it time to market? Is it cost reduction? Is it availability? Is it reliability? Is it you're refreshing your contact center footprint? For me, that crushing why is really important. And then the second thing is absolutely love your get going one, but are you actually leaning into some of the fear and certainty and doubts that is natural from engineers that might not be directly involved in that getting going phase? How are you going to make it approachable, friendly, engaging for them without scaring them bluntly in that get and go? What's your thoughts?

Jake Burns:
Yeah, I agree completely. I think that ties in very much into the second answer that I gave, which was involving your employees and specifically getting buy-in from them. And I have a very specific way that I advocate getting buy-in and a big part of that... In fact, the number one part of that is them understanding that big why. And to your point, it can't be because we're moving to cloud or because we're modernizing or because even the CEO said so. It can't be vague reasons like that. It really needs to be something that they really understand so they kind of understand why they're being asked to change and why they're being asked to put in this extra effort and work. But also something that they could be proud of. So it's hard to be proud of we're moving a cloud to save costs or we're moving... Which may be a real driver for you, but we're going to revolutionize the fan experience.

We're going to make it... Fans who come to concerts to live events are going to have a much better experience. They're going to have an easier time getting tickets. They're going to actually get the seat that they want. They're going to be able to enjoy all of these things that this technology is going to be able to bring. That's something that you could be really proud of. And if you can tie the migration work in your employee's minds to that outcome, which is it's not a fabrication, it's real. It just needs to be communicated. It's just so very rarely communicated, then they'll be proud to do that work. And when things get hard, which they always will, they'll have that extra reason to kind of push through that because the work that they're doing has a purpose and it has meaning to them.

Jonathan Allen:
One of the things I always tell my engineers is rather than being in the data center at 3 o'clock in the morning and to some sort of weird change control, doing some sort of maintenance, wouldn't you rather be much closer to the actual outputs that you are delivering, making that experience really real for customers?

Jonathan Allen:
Let's move on to some of the myths that exist in migration and modernization in particular. And I think there's definitely this world of mythology that has grown up around it. And I think for all good reasons and bad reasons, there's a number of things that swell around it. You and I are pretty privileged to see what works. What are some of the myths that you think are out there which we need to dispel?

Jake Burns:
Yeah. So I think one of the myths is that this has to be difficult or it has to be complicated or it has to take a long time. I think all of those are self-fulfilling beliefs. If you believe it needs to be complicated, you'll make it complicated. And if you believe it needs to take a long time than it will, but in reality, it doesn't. And in my experience, the more successful a migration is generally the faster it gets completed. So I would say that speed actually reduces risk as long as you're doing all the other things right. And increases your odds of success and forces you to decomplexify the entire thing. In other words, make things simpler. And I like to start from first principles, go back and instead of doing what I kind of call the migration rain dance or the cargo cult where you're just kind of checking a bunch of boxes like, "Company A did all of these things and they were successful. So I have to do all of those things and I don't necessarily have to understand why, but if I just check all those boxes, I'll be successful." That rarely works. There really is no kind of shortcut to understanding the steps needed in order to be successful with the migration. But the good news is it is really simple if you go back to those first principles and you think about what are we actually doing? And at the most basic level what a migration is you're taking servers on-premise and you're rebuilding them in a virtual environment in the cloud. It may even be in a virtual environment on-premise as well.

So when you think about it in those terms, it's not a very difficult thing to do. It's not a very difficult thing to understand. And if you kind of work backwards from that very simple, basic understanding of what we're doing and say, "Well, what needs to be true in order for us to be successful to do that?" The whole thing becomes a lot simpler than if you take migration guidance from people who perhaps haven't done it before or perhaps are incentivized to make it more complicated because they make more money by making it more complicated and drawing it out.

I think you could be more successful if you really understand what it is and start from there and then maybe bring in help as needed and you may be surprised at how little help you actually need.

Jonathan Allen:
Yeah, I agree. I think definitely surprising. I think what's interesting though is some customers absolutely do need a little bit more help, and I think there's definitely a myth out there that any provider can help you do this, and that's just not true at all in my experience. It's interesting, AWS has thousands and thousands and thousands of partners, but actually very few that are a map migration acceleration programs certified to help customers because there's such a high bar we put on this that have got those lessons learned of that know how to migrate that are there to help you. We're counting those organizations in the hundreds now.

And I think if I may add the other fallacy is that we need to go through this huge, huge training program to get everybody trained on this. And as you get going you just don't, right? That is going to come. I think developing your mechanism of what is right for my engineers on re-skilling. Is that pair programming? Is that online training? Is that incentivization to pass the exams? Is that… I've even seen many customers use their AWS solutions associate's exam is like a driving license to using the cloud. So there's a lot of myths here that we can sort of burst around.

I think another good one is everybody's really busy doing what they're doing at the moment. They haven't got any time to help migrate. What's your thoughts on that one?

Jake Burns:
Oh man, there's so much you just said. Let me just back up a second on the training piece because there's so much gold there. I think I'm a huge proponent of training, first of all. In fact, I attribute my success in large part to utilizing the AWS training, which I think is really underrated. I think the caliber of the trainers and the caliber of the training and the effectiveness of the training, when done right by the customer, meaning in the right context, the customer can make all the difference. And it did for me for sure.

So to your point on the training, I think the timing of training is super critical. So I make this joke, I say, "If you want to kill the morale of your organization, send your entire organization to training and then outsource the migration." They're ready to do it and then they didn't get the chance to use it. So the best case scenario is you give them the training, give the right people the training at the right time. And they go into the training knowing, having been bought into this transformation and this migration, so they know why they need to pay attention. So it's something they care about. There's something they're bought into. They know that they're going to drive, that they're going to be in the driver's seat, they're going to be the ones actually doing it, so they pay attention and then you let them put it into practice immediately.

And to your point, it has to be equal theory and practice. You have to let them get hands on keyboard and it can't be all theory, right? They need to actually test it out. And when you do that, I think it could be extraordinarily effective.

Jonathan Allen:
Yeah, there's some well-known research that if you go on a training course and don't immediately use it, you're only going to retain 10% of that. Whereas if you've go on a training course, and immediately have to use it, you're going to leverage 100% of that training. That's a scary figure. I've seen that play out time and time and time again.

Jake Burns:
Absolutely. So to address the, "They're too busy." I think that's a fantastic question because when you get buy-in from your employees or even before then usually I'd say almost without fail, the first excuse they're going to give you is, "We're too busy. We have a day job. We're busy maintaining all these systems and doing these things. Where are we going to find time to do this?"

And so I think that comes from a couple of root causes. One is that they actually are too busy. I think you should take a look at what they're currently doing and how much of that work is actually necessary. And in a lot of cases, a lot of it isn't necessary. A lot of it is just kind of make work for lack of a better term. But there is going to be legitimately work that they're doing that that's taking up a lot of their time. Let's look at that and look at how much of that is actually helping them grow. How much of that is actually helping move the ball forward in terms of your overall transformation and your migration? And typically very little of it, if any, is actually building the future. Most of it's maintaining the past, maintaining the on-premises systems that they have there or doing just work that could be very easily outsourced.

So I get this reputation for being against outsourcing because I am a strong advocate for utilizing your own employees to do a migration, but I'm not against outsourcing. I actually think you should just do it in the kind of inverse that most of us, our first instinct is. So rather than outsource the migration, which could be a terrible idea in most cases, outsource everything that isn't the migration, outsource the undifferentiated work, outsource the work that your employees are doing that they're too busy doing that they can't participate in the migration.

That gives you a whole bunch of benefits, including one, it does actually free up their time so that they can participate in the migration. And two, especially if you communicate it as a leader, the intention behind it, you tell them, "I'm freeing up your time because I want to invest in you because I want you to learn this new technology and I want you to be building the future of this organization." And so it could have a huge morale boost on top.

Jonathan Allen:
Yeah, great thoughts there. One of the things that I always sort of coach leaders and engineers from is sort of two lessons from my own time being hands-on with technology. And the first one was… The worst mistake I've made as an engineer, and I still fall into this trap today, is optimizing something that should not exist. So I'm still maintaining that thing in the data center. I'm trying to make it a little bit better. Do you know what? That thing doesn't need to exist anymore and actually I should be working to actively reduce it to free myself up to go and do something, frankly, far more interesting.

And the second thing is when you put teams together, and I've seen some phenomenal sort of six, seven-person teams phenomenally engaged, and typically four or five of those folks are head down doing something and the sixth and seventh person in that team are like, "Huh, what am I doing right now? I know, I'm going to start a new project or a new optimization thing for this thing," rather than going, "Actually, let's declare our priority as cloud." Coming back to that why lesson learned, let's give permission to people to re-skill themselves actively and work on that. And there's just sort of two quick things that can instantly kind of reduce the cognitive workload that I think engineers just have a habit of taking on. What are your thoughts?

Jake Burns:
Absolutely. I couldn't agree more. And actually in that specific scenario, which happens a lot, I've seen that as well. I think it's the duty, and I think this needs to be communicated clearly by leadership, it's the duty of the more senior people on the team and the people who've kind of bought into the transformation and migration earlier to mentor the other folks on the team so they don't go get distracted by other projects and other work. Or to your point, optimizing the existing status quo, which I agree is a huge mistake and waste of time.

It's kind of like, we talked about the moving from economies of scale to economies of speed. The economies of scale thinking is the steady state status quo, thinking we keep optimizing and trying to make our unit costs cheaper, whereas the economies of speed is more disruptive. It's, how do we actually transform and think about better things that we could be spending our time on?

Jonathan Allen:
Right.

Jake Burns:
And so I like your economies of speed way of thinking here. But to that specific question, if you have those people as part of their normal day-to-day operations and what they're incentivized and evaluated, their performance is evaluated against is mentoring new people on the team or even recruiting new people to join the team and mentoring and onboarding them. It helps first of all, it creates that sense of teamwork and that morale boost, that we're all in it together, and that inclusivity and meritocracy component of it, which is super important. But it also helps avoid that trap that you described, where they get distracted with other work.

Jonathan Allen:
Cool. I'm going to move on to some of the more technical sides. Now, you and I have both seen the tooling go through, I'd say, multiple evolutions of improvements during the last 10 years. Certainly from when I was moving workloads all the way through to where we are right now with the Database Migration Service. Migrated well over 1 million databases with the Schema Conversion Tool. We've seen AWS MGM actually doing bit-level encrypted copies of workloads, vastly improving the partner ecosystem. What are your thoughts on bursting some of the myths that people may have in the tooling space right now?

Jake Burns:
My position on this is that I think that one of the myths is that there's a tool to solve your problem. Tools very rarely are going to solve your problem, if ever. Tools are force multipliers, so you should already have a solution to your problem and you're using the tool to make that solution more efficient.

They're not going to be a panacea. They're not going to be a skeleton key that unlocks every door. Usually the tools that you have today are sufficient in order to get the job done. You should be looking for existing tools in order to optimize and speed things up. And avoid the trap of over-relying on tools, because a lot of times it's kind of a form of procrastination, in a sense, where we're just looking for the right tool to do our cost optimization or whatever migration of the specific workload when in fact, halfway through that evaluation of that tool, you could've been done migrating that workload already or you could have already been cost-optimizing using free tools like Cost Explorer, which is amazing.

Are there tools out there that have more features than Cost Explorer? Absolutely. Could they potentially be better? Absolutely. But can Cost Explorer cover 99% of the things that you want to do? Yeah, usually it will. And it's right there in front of you. So my advice is to use the tools that AWS gives you, which are in fact very good, especially today. And then if there are gaps, always be evaluating new tools and seeing if there's anything better, but don't expect those tools to significantly accelerate your progress. They're going to give you incremental improvements, and you should utilize those, but I think the bigger trap is that customers have this over-reliance on it and too high of expectations as to what those tools are going to do for them.

Jonathan Allen:
Agreed. One of the things I have seen, though, in the last year really accelerating the journey for customers is an acknowledgement that spending too long deploying new tooling that's going to give them the insights might be one of those fallacies, where actually so much of the information they've already got that's in .CSV files, in CMDB, in some of those things. If they can bring that back together, actually, and put it in a data mart and query it, actually that gives them so much of that information to get going sooner than they think about.

Jake, I want to move on and just probe a little bit more on the technical side. Now, you and I both have diverse perspectives on migration and modernization, which I love. I love diverse opinions. You and I have debated long and hard in the different variations, but I want to dig into your side a little bit more. So let's go into a little bit more depth on the technical side. I've heard you talk about a unique migration methodology that can help simplify the process. Tell us about it.

Jake Burns:
In a nutshell, two parts of it. One is what I call minimal viable refactoring, which is an alternative to the 7 Rs model.

Essentially what I advocate for is doing pretty much zero planning when it comes to how we're going to refactor these applications ahead of time and take an iterative approach. So in a nutshell, what you do is you take all of your applications and you order them by how easy they'll be to migrate. And you put those in the beginning and how business critical they are. And you put the least business critical at the beginning.

And so you want to migrate the least business critical, easiest to migrate ones first because, remember, you're using your own full-time employees, and they're probably very new at this. So you want it to be very low stakes and you want it to be very easy. You want to build momentum throughout the migration. So you want to get the easy stuff out of the way first and string together a series of wins so that you can get public opinion on your side, so to speak, and get that forward momentum and build that confidence.

And so what you do is you start with a lift and shift. And in my opinion there's no such thing as a lift and shift to the cloud. There's always going to be some changes that you make but, in my opinion, you don't want to over complicate the migration, so you want to make the fewest number of changes necessary in order to first do no harm. Kind of a Hippocratic oath of IT. So common areas, you don't want to do harm, you don't want to make anything more expensive, you don't want to make anything less reliable, you don't want to make anything less performant, and you don't want to make anything less secure or compliant.

So as long as you're not making any of those things worse, you're going to end the refactoring and just do the minimum amount to not make any of those things worse, and then migrate those to the cloud as quickly as possible. Now, of course you're going to circle back immediately and start optimizing once you're in the cloud and make those things as good as possible, but you don't want to over-complicate the migration.

And so one of the great things about this is it's very simple. You're not fitting things into arbitrary buckets with the 7 Rs. It's just the degree of refactoring necessary in order to safely move the application. It could be done iteratively, so there's very little, if any, upfront planning. So you could just go through all of your applications and decide as you're migrating them what level of refactoring you want to do. And then you get to the migration process. And this is where I need to come up with a better name for this, but currently it's the multi-threaded non-blocking migration process.

Essentially what you do is you break up the migration. My joke is, this is what happens when you let engineer design a migration methodology. We start using the things we learn. In fact, this is where I came up with this idea, was in the AWS Solutions Architect training, which I took along with my team. The idea of loosely coupling microservices or areas of infrastructure or code in order to reduce bottlenecks and make asynchronous processes rather than synchronous.

In other words, we don't want to ever be blocked waiting for something, because that's just wasted time. And we don't want to context switch more often than necessary because that causes us to lose focus. And so the idea, in my attempt to make it as simple as possible for the source of this conversation, is to break up each one of those stages of the migration of each application to a discrete microservice in the migration process, assign someone to that area of activity, and then move all of your applications through those series of loosely coupled components.

And whenever anything gets blocked, because they will. We're waiting for approvals, we're still designing the application, we're still transferring the data, whatever the case may be, that's when you context switch and move on to the next application. And the goal is to keep everyone busy, to keep all the apps moving forward through the migration process, and get it done as quickly and as efficiently as possible.

Jonathan Allen:
Yeah. I love that. And just from my own experience, I remember working with one customer and one of the first workloads they picked was particularly difficult, and they spent six weeks looking at moving millions of write-once, read-many images and they couldn't figure how to do it. They kind of reversed that and started on those easier workloads and by the time they got back to that, the engineers had actually figured out a solution on how to process that one. So they've achieved that momentum and eventually they realized, "Hold on, we've got all these building blocks we can now leverage."

Jake Burns:
Absolutely. And one other thing that you haven't mentioned is I believe you have a new edition of your book out, and I think, really, this is the best book I've seen on this topic. So I really think that everyone should... I'm not just saying this because you're here, I actually say this when you're not here as well. I've given this book to many CIOs in person when I meet with them. It really is that impactful. Could you just tell us a little bit maybe about the book and what's new in this new edition that's just been released?

Jonathan Allen:
Yeah. Thanks, Jake. So yes, Reaching Cloud Velocity Second Edition is out today. Basically updated around seven or eight of the chapters, particularly on the operating model chapters, particularly migration and modernization, particularly some more challenging topics that we've sometimes struggle to talk about, customers struggle to talk about, and I wanted to provide some clarity on those. So yeah, check it out. Thank you, Jake.

Jake Burns:
Awesome. Thanks, Jonathan.

Jonathan Allen:
Good conversation. Thanks, Jake. And to our listeners, thanks so much for joining us here on Conversations with Leaders. We have an outstanding lineup of global technology leaders coming in 2025 that will continue to address vital questions and share unique perspectives at the intersection of business and technology. Be sure to subscribe so you don't miss an episode. Until next time, take care.

Listen now

Listen now

Listen now