AWS re:Invent 2025 - A leader's guide to accelerating large-scale migration (SNR301)

🦄 Making great presentations more accessible.
This project enhances multilingual accessibility and discoverability while preserving the original content. Detailed transcriptions and keyframes capture the nuances and technical insights that convey the full value of each session.

Note: A comprehensive list of re:Invent 2025 transcribed articles is available in this Spreadsheet!

Overview

📖 AWS re:Invent 2025 - A leader's guide to accelerating large-scale migration (SNR301)

In this video, Jake Burns, AWS Executive in Residence and former Live Nation Ticketmaster CTO, shares insights from successfully migrating to AWS in 17 months with no budget and frozen headcount, achieving 50% TCO reduction. He identifies six pillars for successful cloud migration: compelling why, utilizing constraints, investing in people, building momentum, embracing simplicity, and strong leadership. Burns advocates insourcing migrations to upskill existing employees rather than outsourcing, separating migration from modernization, and using a Minimum Viable Refactoring approach instead of the traditional 7 R's framework. He emphasizes that constraints drive innovation, momentum is the key KPI, and excess complexity is the primary cause of failed migrations. The presentation includes practical frameworks like loosely-coupled non-blocking migration pipelines and minimal viable landing zones to accelerate cloud adoption across any industry.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The Cloud Migration Challenge: Why 85% of IT Spend Remains On-Premises

All right, good afternoon, everyone. My name is Jake Burns. Today we're going to talk about migrations. So this stat is interesting because it hasn't changed much in the past few years. Cloud computing generates over 100 billion dollars in annual revenue, yet still 85% of the global IT spend is still on premises. So the question is why? And it's been my observation that this is not a choice. Most organizations want to be in the cloud. It's just that most of the ones that I've worked with are not having an easy go at it. They're struggling in some way.

And so I've spent probably the last 10 years analyzing this in some shape or form, either migrating personally or talking to and advising executives on how to do it, and in the past 12 months really focusing on this. Why is this the case? Why is migrating so difficult? And so I'm going to attempt to answer that here, and I'm going to try to leave a lot of time at the end for Q&A because some of the things I talk about start off very simple, but a lot of it can be counterintuitive, so I want to give you an opportunity to ask me questions.

So I have a very interesting role here at AWS. I'm part of the Executive in Residence team. We're a team that's comprised of former CIOs and CTOs and other senior leaders who have all led large-scale transformations using AWS Cloud in our prior roles, so we've been on the customer side and we've all successfully led a transformation. And so on top of that, we have a lot of these conversations with senior leaders across all industries globally on various topics, but I tend to talk about the ones who want to talk about migration. I get to talk to those, so I've had hundreds of those conversations in the last seven years, and so I've got to see the good, the bad, and the ugly.

So before this, I was with Live Nation Ticketmaster and I led an all-in migration to AWS. Now I had a 12-month deadline, largely legacy systems, things that were not born in the cloud, not meant to be run in the cloud, no budget and frozen headcount, and the team that I had at the time had no experience with the cloud. And cloud wasn't really cool at the time. It was back in 2015. It was the stone age when it comes to cloud. Now we didn't do it in 12 months, we did it in 17, but we were able to get some impressive metrics out of it, so impressive that we still talk about this migration a decade later.

We reduced our total cost of ownership by nearly half after optimization. Before optimization it was about 18%, so that's a result of having no budget. It's either do it cost neutral or fail, and we weren't willing to fail. Our availability got better, our resiliency got better, and all of our performance issues got resolved. And so a lot of the questions I get are like how did you do that? Well, the cloud, I think most people know by now, is very elastic and so it's very easy to find the bottlenecks. So the key is really matching your capacity and your utilization. So you can reduce your costs while reducing or eliminating your performance bottlenecks at the same time. That's basically the key.

Now there are six things that I've identified because I've looked at a lot of migrations since then. What's different between the experience that I went through and the experience that I see on an almost daily basis and I hear from customers on an almost daily basis? And to be clear, some of them are successful, but not all of them are, and it's my goal to make all of them successful. So what do the successful ones have in common? We've identified these six pillars.

Six Pillars of Successful Migration: From Compelling Vision to Strong Leadership

First is they have a compelling why. Now this can't be because we want to save money or because the CEO said so. It has to be something that the people who you're depending on, hopefully your own employees, are going to really care about. This should be your company's mission. This should be something that drives them because when things get hard, they're going to need to be able to push through that. Second is utilize constraints, and this is one that could be counterintuitive. When people hear about my story, you know, 12-month deadline, no budget, frozen headcount, and then still was able to be successful, I sometimes say that's why we were successful. A lot of the migrations that I see fail are the ones that have too many resources, and we'll get into that a little bit more later.

Third is invest in people, and this one should be a no-brainer. The more skilled your workforce is in cloud, the better they're going to be at migrating to the cloud and at operating in the cloud.

So the investment is totally and completely key. Building momentum in a migration or any transformation, and a lot of this applies to AI transformations as well, is super key because things tend to start off slow and then as you start winning that compounds. Inertia can compound as well, and you could just keep going slow.

Embracing simplicity is the next one, and I would say this is probably the biggest one that I see violated. Excess complexity, in my opinion, is the root cause of failed migrations and failed transformations in general. What this means is most of the things that people do when they migrate are simply not necessary, or the ones that are necessary, they're far too complex. Last but not least, and this is a hard requirement, is having strong leadership. You have to have somebody who's accountable and they have to have the authority to do things. It doesn't have to be a lot of authority, but they need to be accountable for those things that they have authority for and they need to have a little bit of guts.

Debunking Common Objections: Cloud Migration is Simpler Than You Think

So for the past seven years, like I said, I've been talking to hundreds of executive teams on the topic of migration, and I hear the same objections over and over again. Live Nation Ticketmaster, we were, Live Nation is an entertainment company, right? So I'll talk to an energy company and I'll say, well, that would never work for an energy company, right? So we're special, right? Or the scope is too big. We migrated, you know, we're an $11 billion revenue runway business at the time, much more today, but there are companies that are much bigger than that, and they can very easily say it would never work at our scale. And the third most common, and it's almost always these three, is that we have unique regulatory requirements, so the cloud won't work for us or it's hard for us to migrate that quickly because of that.

But the thing is, when you strip away all the assumptions of complexity, cloud migration is really simple. It's really moving your applications and data from one place to another. Sometimes it's a virtualized environment in your data center to a virtualized environment in the cloud. And yes, maybe it's a different technology, but most of us who are doing cloud migrations, we've done data center consolidations in the past. It's very similar and doesn't have to be that much different. So I could say this with confidence because I've done it, but I could say it even more with confidence now because I've helped so many others do it as well. It really is this simple.

Now there are workloads that are difficult to migrate, you know, mainframes, for example, that require a full refactor, but those are unique edge cases. Those are not the most common. So a more generalized approach is a better approach. Let's manage by the exceptions as exceptions, and let's take the complexity out of the 99% that could be easy. So a good migration framework is universal. It'll work in every industry because your servers don't care what industry your business is in. It's effective at any scale because a good framework, any good framework is a scalable one, right? You take something that works and you scale it up, and this has been proven with this methodology as well. And it should have compliance built in. A good framework should not violate compliance. It should be flexible enough to handle compliance.

The Power of Constraints: How Limited Resources Drive Innovation and Success

So there's some lessons that I've learned through this process, and some of them can be a little bit counterintuitive. This is one of them. You're more likely to fail from too few constraints than from too many. This is one that people find surprising. It's like, wait a minute, you're going to take resources away from me and I'm going to be more successful? Yes, that's usually the case. Most cloud migrations are overfunded and their deadlines are way too long in the future. You know, I had a 12 month deadline and it took me 17 months. If I had a 17 month deadline, I think it would have taken me two years. If you give me two years, maybe I never would have done it at all, right?

So some of you may be familiar with Parkinson's Law. Basically, it explains why in college when your homework is due, you do it, you start the night before instead of like a week when it was assigned. We typically have too much time and too many resources to do things. Now you can take this too far, but work will expand to fill up that time that you have. So if you give yourself five years to do a migration, it's going to take five years minimum. Nobody sets out to do a five year migration that takes two years, right? But you could set out to do a one year migration and take one and a half years. That's a much more common pattern.

So what this does is when you set these seemingly unrealistic goals, it gives you a sense of urgency. And if you don't have that sense of urgency, if you have too much time, you never get started.

If you have too much time, say you have 100 things to do. Most of us we're gonna pick out of that 100 which one to attack first, the easiest one, right? Let's just take the easy one off the list. But if you had to pick only 10, you're gonna pick one of the most top 10 impactful ones, and that's what the sense of urgency does, the constraint. It forces you to focus on what matters.

And innovation. Why innovate if you don't have to? As human beings we're lazy. This isn't a bad thing. It's efficiency, right? So if it's worked for us in the past, it's probably gonna work for us in the future. So if we've been doing migrations like this for this amount of time, why not keep doing it that way? Well, the reason is because we can't, and constraint forces that. So you're more likely to succeed with constraints than you are without.

This is one of my conclusions. Nobody wants their budget taken away from them. Nobody wants to be under an unrealistic deadline, but this is where the innovation comes from and this is where the efficiency comes from, and it makes for a much more interesting story when the odds are stacked against you and you succeed anyway and you'll be surprised. So instead you put constraints into motion and then you find a way. So a deadline forces you to find a way.

For me I had to begin before I felt ready. This is something that I was told, begin before you feel ready, right? So I was given the mandate to migrate in December. I started the beginning of January. Why? Because at 12 months I'm not gonna waste any days, right? I had to focus on what mattered. I couldn't get distracted by things and I had to work backwards from a goal. It's easy, 12 month deadline, we're gonna be done by Christmas and work backwards from there.

A budget and, more specifically a budget that's smaller than you would like it to be forces you to become lean, forces you to invent and simplify as we say at AWS. You have to find a new way of doing things because the old way we just don't have the money to do it anymore and that's where new things get invented. In my case, a limited headcount, what it did, it forced me to motivate my existing team. So I talked about in the beginning how I had a frozen headcount, no budget, so I couldn't hire cloud experts to come in and do the migration.

So, I had to develop a skill. In order to be successful, I had to develop the skill of motivating my team, getting them upskilled very quickly and enabling them to be successful. Now, it's not an easy thing to do. I'll give you the playbook and I'll answer your questions and I'll tell you exactly how to do it, but once you do that, it is like having a superpower when you can take people who don't have the skill that you need, and this is applicable to AI right now too.

Everybody's looking for AI talent. Good luck hiring those people, they're in high demand, but you could take the people you have and if you can get them interested in it and you can get them able to learn it and then you can get them able to use it in a meaningful way within your organization, you could have an endless pipeline of talent and that is as a leader, it's one of the most liberating feelings you can have.

Separating Migration from Modernization: A Strategy for Faster Results

One of the other things that I see, I would say anti-pattern, is conflating, and this one's a little controversial, conflating migration and modernization. The way you look at it is this, migrating, if people are having a hard time migrating and people have a hard time modernizing, if you combine both of them, it's like complexity times complexity, so your odds of success go down. And then the common objection is, well, a lift and shift gives you no value.

Well, first of all, I'd argue that because your data is in the cloud and you can use that for AI workloads and you can do other things as well, but I'll largely agree with that. But I'll also say that you are more likely to migrate or modernize more quickly, like your apps will be more modern at a date sooner than they would be if you were to migrate, then modernize, separate them, decouple them, do separate the complexity into different stages. Your modernization will be done sooner than if you try to do them both at the same time. So migrate so you can modernize sooner, so you can be in the cloud and you can use all the great cloud services.

Building Cloud Engineers Instead of Hiring Them: The Insourcing Advantage

This is a quote. This is me from way long ago. I don't hire cloud engineers, I build them. This is what I would say because that's how I felt about it. I was building, it's kind of a weird way to say it, but I was building a pipeline of cloud engineers. I didn't hire a single cloud engineer ever. I created them out of people who had IT skills, but they didn't have cloud talent.

I think we could do this with AI as well, with any skill. If they have competency and motivation, you can build a pipeline from existing employees. And so, this is the strategy that I recommend, insource your cloud transformation.

If you outsource it, which is the default that people do, it's going to be seen as a threat, and why wouldn't it? Because you're basically telling your team that you have no confidence that they could do it and that you're bringing in others to do it for them. It also has a problem in that the people who you bring in to do it are being trained and given experience, and then they take that knowledge with them when they leave. So in my experience and in my opinion, they should be paying you for that experience. That experience is very valuable, so you're robbing your team of that experience. And then it also incentivizes short-term thinking because if you think about it, if you have some hired guns that come in and build it and they're going to leave and they don't have to maintain it, they might cut some corners. But if you know you're going to build something and you know you're going to have to maintain it, you're more likely to do it in a way that is going to have higher operational excellence, let's put it that way.

So my thought process here is insource the migration and let your own team do it. You're going to bring in external help. Partners are an excellent resource, and AWS itself is an excellent resource, and you bring them in, but their goal should be to become irrelevant. Their goal should be to upskill your people because your people are the ones who are going to have to maintain this. And so in DevOps you say you build it, you run it. I think that's true and that should be true for just about everything. You build it, you run it with the cloud as well. Bring in the experts to transfer the knowledge. Bring in lower-cost resources to kind of free up their plate so they can work on it, and do your best as a leader to allow them to focus on it.

So it has a lot of advantages when you do this. Just being purely selfish, the people that work for you or all the people in your organization already know each other and they already know how to work with each other. When you bring in new people, there's onboarding and there's complexity with that. They know how your organization works. Every organization has bureaucracy, the way of doing things, and that's a delay. Think about it: if you have to onboard a bunch of people in the beginning of a migration, then learning how just to navigate your organization is extra time that it's going to take. And not having to hire them is great. The fact that they already work for you makes it a lot easier.

So even just being purely selfish, because a lot of times it sounds like I'm saying invest in your employees as if it's charity. No, I'm saying do it for selfish reasons. It's going to make your migration more successful, and you're going to be able to operate it more successfully in the long term, and it's going to make your life easier. So it's easier to teach cloud skills to your existing workforce than how your organization works to external people. That's the key point there. And if you think about that, it makes total sense. Cloud skills are a relatively easy thing to learn, especially if you're giving them the opportunity to use it, which you should be doing. Learning how your organization works, for some organizations, this could be very difficult.

Okay, so I'm making this sound so easy, right? There are some problems, but I'll give you some solutions. So the first problem is, yeah, they're too busy. Every single time when you say we're going to let you do the migration, they say we're too busy. They're telling you the truth. So my answer to that is, well, what are you so busy doing that you can't do a cloud migration or cloud adoption or building this new app in the cloud or whatever the case may be? Whatever that answer is, outsource that. That's undifferentiated. That's stuff that you can outsource at low cost. That's just keeping the lights on. Free up their time and they'll appreciate it.

Now the next one, they're much less likely to vocalize, but it's typically true: they're fearful. What are they fearful of? They're fearful of the unknown. They're fearful if I do this, can I even do this? Am I going to succeed? I've never done it before. For most people when they do a cloud migration, it's the first time doing it, so it's natural to be fearful. They're fearful, will I have the skills to maintain this new cloud environment? Am I engineering myself out of a job? There's a lot of things that they have to be fearful of, so we need to address that.

So give them a safety net. They may not vocalize it, but they need the safety net. So give them training, lots of training, with a goal. They need to know going into the training that they're going to be the ones that are going to drive. Bring in experts: AWS Solutions Architects, professional services, partners, all these people who can help them and guide them in the beginning. And you really just need to get buy-in from them. And this kind of speaks to the last point: they may not even care. So we need to get them to care.

If you're the boss and they work for you, they may want you to be successful, but I think if they have ownership of it, they're going to be a little bit more receptive. So outsourcing to enable solves those first two problems: too busy and fearful. Now let's talk about how we solved this last one of them not caring.

Because outsourcing itself is rarely the problem. It's what we choose to outsource that's the problem. We outsource the fun stuff, the cloud migration, the building of the new agentic AI system. We're outsourcing that to people because we see the skills gap in our organization. We should let our employees do that and we should outsource the boring stuff they don't want to do to make time for it.

Getting Buy-In: The Three Ingredients for Team Enthusiasm and Upskilling

So how do we get buy-in? Because that's really what we're talking about here. Well, I talked about a compelling why. You have to have a compelling why. It has to be something they actually care about and should be related to your industry. What does your company do? What does your organization do? Most leaders have this advantage and they don't use it because they just don't know how to articulate it. So for a live entertainment company, it might be we're making the fan experience better. We're going to make it easier to buy tickets, and when you go to a concert, we're going to have this interactive experience. All these things that the cloud will legitimately enable you to do. You just have to tell that story because when they're asked what they're doing at work, what are they going to say? Well, I'm doing stuff in the cloud, or I'm doing IT stuff. Let them tell a good story.

Speaking of stories, there's a story of JFK going to visit the NASA Space Center in 1962. He encountered a janitor and asked him, what do you do here? And the janitor said, I'm putting a man on the moon. This is the kind of mentality you have to think of. The janitor was not telling a lie. He's helping put a man on the moon. He had a part to play in this. Everybody has a part to play in the mission of the organization. And when you instill that mentality in them, then they will be enthusiastic. At least that's part of it. That's one of three parts of it.

Second is sharing the how. You'd be surprised how many leaders keep their plans a secret. If you don't share your plan, then your team might just assume you don't have a plan, and you might not actually have a plan, so this will force you to create one. But the other thing you need to do is solicit feedback. Allow them to, look, it's not a free for all, but if you have a better idea, tell me. We have what we call tenets at Amazon, and it always says, you know, these are kind of principles, leadership principles for projects and teams. It always says unless you know better ones, these are our tenets unless you know better ones. And every single time it says unless you know better ones, that should be the mantra. Here's the plan unless you got a better one. This is not my idea how to do it unless you have a better one, so listen to them.

Now, even if you don't incorporate all of their feedback, just the fact that you're asking for it creates a sense of ownership, and the fact that you're sharing what you're going to do gives them confidence that it actually can be done. Because I could see the plan, I can see how this could be done versus we're going to the cloud and how we're going to do it is just a big question mark. So make it our plan. They might care about your plan, but they're going to care about our plan, their plan.

And then finally, what's in it for them? And this is I think an easy one with cloud. You know, with the cloud, I said you could transform people's careers. I like to reframe we're engineering ourselves out of a job into we're engineering ourselves into a better job, and this is the truth. It's just a reframe. And so when they understand that, when they understand that if you're the type of organization that's going to give them training, get them certifications, allow them to actually be hands on and do the work, that's rare, and you happen to work for a company like this, at the end of this, you're not going to care about job security. I'm going to be fighting to keep you, and you should ask me for a raise. Doesn't mean I can give you one, but you should definitely ask for one. I wasn't able to give many, but I encouraged them to ask.

So these are the three ingredients, and you can use this not just with your employees but with your peers and with your management, whoever you need to get buy-in from for transformative change. Then you upskill, but the upskilling, there's some very specific things that I recommend you do with upskilling. First, you have to get buy-in, which we just talked about, because if they don't care, then it's just a paid vacation you send them to training. Get the timing right. Do the training, for me I had to do the training while I was doing the migration, so I actually had to get so much buy-in from my team that they were willing to do three jobs at once: training in the morning, migration in the afternoon, and in your free time just try to keep the business running. So that was a lot to ask.

Now you don't necessarily have to do them at the same time, but the next best thing is to do the training immediately before the migration. If any interval that you have in between that, knowledge tends to get forgotten. So putting it into practice as quickly as possible is super important.

And there's the other things here as well. Use all available means. AWS has a lot of free resources that we can give you for training, solutions architects, our partners. There's a lot of people who will come in and help you get upskilled, and don't ever stop doing it. It's a continuous process.

Strategic Hiring: Attracting Top Performers Through Organizational Transformation

So now you may have to hire. After you've given everyone in your organization a chance to fill new roles in the cloud, you may need to. But please give everyone a chance first. This is super important. Now you may have gaps, hire for those gaps. Now it's going to be hard to find people who are qualified, so you may need to do a couple of things like adjusting your requirements.

One thing I found that works here is, has anyone here noticed how many Agentic AI engineer job postings there are, and they all want like three years' experience, five years' experience? It's like, yeah, this technology hasn't been around that long, right? So hire people who are motivated, hire people who want to learn. That is a higher indicator of success than existing skills. Now existing skills is a good base to have, of course, but do you want to pay a premium for that?

So this is kind of a cheat code. Get people who are early in their career but are sharp and smart and want to learn, or maybe they're later in their career and they just don't have, they give a solid technical foundation, they just don't understand cloud and no one's giving them a chance, right? These people you can get for, it's an incredible deal, let's just put it that way, right? And you upskill them and then you have those people, you have that pipeline that I was talking about.

And lastly, you have to become an organization that attracts top performers, right? You may have heard the quote, become the person that attracts success, right? It's kind of a similar thing. Are you the type of organization that top performers want to work at? Top performers want to work with other top performers. They want to work on interesting problems. They want to be hands on. They don't want to work for an organization that just outsources the fun work, right?

They want to work for an organization that's going to allow them to become more valuable over time through hands-on experience, through training, and all those things. So become that type of organization, work on interesting stuff, and as a leader, care about making your team more valuable. I'd much rather have the problem of retaining valuable people than the problem of having people who are not valuable and can't do the work, right? So you don't get to choose whether you have a problem. You just get to choose which of those problems you have.

So talent is something your organization attracts by what it becomes. Spend less time on recruiting and more time on becoming that type of organization. Think of the top five companies in the world. They don't have to do a lot of recruiting, right? Recruiting for them is sorting through all the resumes that get sent to them. So be attractive to top performers and the talent will come to you. All of these help a little bit. None of them are going to get you all the way there.

Simple Structures and Meritocracy: Organizing Teams for Migration Success

Okay, so another anti-pattern: elaborate committees and org structures. I don't think that this helps very much, so I advocate for a very, very simple structure, and it's three parts, and it's very easy to set up. First is your cloud team. They're the people that do the migration. You can call them whatever you want. I call them the cloud team. They're usually infrastructure. In my case, they're a former infrastructure team. I rebranded Cloud Services. This could be DevOps folks, but these are the people who are going to do it hands on.

You got an advisory board. I like to call it Minimal Viable CCOE, Minimum Viable Cloud Center of Excellence. Very lightweight, very informal. You got finance, you got HR, InfoSec, you got one person from each, one leader from each of those, just to agree on policies and how we're going to do things, but not to micromanage, and it shouldn't take very long to set up.

And then stakeholders, which are everyone else in the organization, right? These are who you serve as a cloud team. So these are application owners or business unit owners if there's no application owner, right? Typically it's application owners, it's the app folks. So yes, infrastructure people, you have to answer to app people just like always, unfortunately for the infrastructure folks, but now the app people have to answer to the business, so it all ends up kind of working out in the end.

But this is a very simple structure and this is really all you need. This is all I used, and this works at any scale, and this could be set up in a day, really. It's not that difficult to do. Now, the stakeholders.

We're going to ask as little from them as possible and we're going to give them as much as possible. So all we're going to ask from them is agree to this cutover date, agree to this cloud architecture if you even care about how we architect it, and just give us permission to migrate it to the cloud. Then do however much testing you think you need to do at the end of it to ensure that it works, and it's going to work because, as you'll see in a minute, we're not going to make very many changes in the migration phase. I kind of alluded to this earlier. Another benefit of doing it that way is that the migration tends to work. The migrations tend to not have to be migrated back because we make very little changes.

Okay, so create a meritocracy. Now what I found is that within the cloud team, your team members will fall into one of three categories. This is usually the smallest category. It's the early adopters. These should be your new leaders. These are people who are enthusiastic about the cloud, and they may not be your senior level people. They may be, but they may not be. In my case, one of them was very senior level, one of them wasn't. But put them in leadership positions that enable them, right? They're going to be the ones that prove that this could be done to everyone else.

You've got the passive majority, right? So obviously that's the most amount of people because it's got majority right in the name. But they're usually just going to go which way the wind blows if we're being honest, right? If this thing looks like it's going to be successful, I'm going to support it. If it looks like it's going to fail, then I'm going to have no part of it, right? So they need to be won over, which means we have to start winning quickly, and that's, as you'll see in a minute, part of the strategy. We've got to start winning very quickly.

And then you've got active resisters, and most organizations have these, right? And the thing is, don't fight them. My suggestion is embrace that because think about it. The early adopters and to some extent the passive majority, they're the ones who are complaining we're too busy, okay. The resistors, the ones that we lovingly call server huggers in the cloud migration industry, you know, let them manage the servers. Let them keep the lights on. Let them do, someone has to do it. Let them manage the outsourced team that's doing the quote unquote boring work. They love doing that kind of work. They will come around eventually.

Other things you can do here within this meritocracy is create new career ladders. You know, I did something funny. You have your career, you have your technical track, your manager track, and then I added a cloud track. And you know, it sends a clear message when the cloud track actually has more rungs on the ladder than the other two tracks. So create incentives, right? You want to get promoted, you want to get a higher level in this organization, this is the path to do it. Give opportunity to everyone equally, right? So one of the things that's going to happen is people are going to complain. They're going to say, how come that person gets to be on the cloud team and I don't?

So the way you get around that is to say, okay, cloud team, you get to set the rules of who's on the cloud team, right? And now you live with your own rules. So we're trying to make this as fair as possible, again, not to be charitable, but because it works. When you create a meritocratic system, you get better results because what ends up happening is the results, however you define them, those who produce more of them get more responsibility, right? And those who get less, so it creates incentive structures that work, and it also gets the right people involved. And then be transparent about all of this, right? Let them own it, and there's no hidden qualifications. All the qualifications are there, and I don't care if you're the most senior engineer on the team, you still have to get that certification if you want to be a senior cloud engineer, you know, if that's the rule that you make.

And I don't care if you're just the lowest person on the ladder, if you're a help desk person taking tier one tickets, if you can get that certification, you could be a senior engineer, right? So create these rules, let the cloud team own it, and apply it to everybody.

The Minimal Viable Migration Plan: Building Momentum Through Quick Wins

All right, so now we're going to cram a bunch of more information in the end here because this is where it gets a little bit more into the mechanics of it, right? How do we actually migrate? I've been talking about culture this whole time, right? Well, 90% of the problems are culture, but let me give you some tips on the actual migration mechanics because this was a little unique how we got this done so quickly, and I've been able to replicate this with other organizations that I've worked with, and so it is universal. I do believe it works for any size organization in any industry, and feel free to challenge me on that. Hopefully we have Q&A at the end, so I'll let you challenge me in front of everyone.

So what we want to do is focus on the goal. We don't want to get distracted. We're going to eliminate all the complexity, all the things that have nothing to do with migration. We're not going to do them, and the things that are necessary but maybe don't make the migration happen quickly, we're going to simplify it as much as possible. So we're going to embrace this minimal viable framework, right?

We have minimal viable committees like I talked about before, we have minimal viable migration plan which we're going to talk about now. I suggest creating a minimal viable landing zone, which is again kind of controversial. It should take days, weeks, maybe at most to create a landing zone. This is what we call a two-way door decision at Amazon. It's a reversible decision. Your landing zone can evolve. It doesn't have to be perfect before you start migrating, so that should be done quickly as well. And then finally, my favorite minimal viable refactoring because that completely gets rid of the seminars. I'm going to go through that quickly.

So we want to make the process loosely coupled and non-blocking, and if you're an engineer, you know what that means. It means one thing does not block the other and each, it's almost like a microservices architecture and that's what you get if you put an engineer in charge of a cloud migration, and it worked for us. So let's go over it in detail. So here's the minimum viable migration plan. You first identify all the in-scope applications, then you identify an owner for each of them. Then you map the infrastructure that belongs to each one of those so you know what infrastructure to migrate. You map the dependencies, if any, and in my experience there's far fewer than what most people think. We're going to determine the sequence and there's a formula for that that's really easy. And then we're going to create cutover dates and we'll just work backwards from the deadline because we're going to have a deadline.

So here are applications or mock applications. We're going to just go over a very simple example here. These are our applications. We're going to order them from easiest to migrate and least business critical and most stakeholder support. Those three dimensions are going to go first, and then the most difficult to migrate that are most business critical and have the least stakeholder support. Remember stakeholders are application owners, so they're the ones we have to satisfy. We're going to put them towards the end. Now the idea is that we want to get some quick wins here because we've got to win that passive majority.

So now we're going to turn that into a migration plan. And we can only be sure of two dates, the first one, which is immediately, and the last one, which is the deadline, so that's quite easy. So here's why I do it this way. The importance of momentum. You find when you talk to people who've done successful transformations or migrations, it's always this very happy story and the story is that everybody was a supporter from the beginning, everybody helped plan it, everybody was a sponsor. Because of survivorship bias, you're talking to the successful ones. You don't talk to the people who did failed migrations, there's no owners of those.

So how do we do this? The problem is in the beginning you haven't done anything, so why should anyone in your organization support you? Well, the way you break the cycle, the way you get it started, is you start with a small, very small, maybe like comically small, like a single web server. And then you build off of that, you build a series of wins. Once is a fluke, twice is a coincidence, three times is a pattern. At some point it's like, okay, this thing is successful and you start getting people on board and you make a lot of noise each step of the way. Say we just migrated like a simple file server. I'll throw a party over that in the beginning. I want everyone in the organization to know, I want those passive majority to know that this is working so that they come on board so that it becomes this kind of self-fulfilling prophecy which by the way can go in reverse if you have some disasters in the beginning, so we have to avoid that.

And then, yes, so here's the quip. You get all the support you need after you need it. That's the thing. At the end you have a perfect migration plan and everyone's a supporter of your migration, but in the beginning what most people don't see and maybe some of you in this room are in this situation, you're usually all by yourself. You usually don't have a lot of support in the beginning. My suggestion, once you're successful is let them take credit for it. It doesn't matter, you won.

All right, migration planning process, a minimal viable landing zone. Not going to spend a lot of time on this except to say that I could fit everything you need in a landing zone on one slide with room to spare. So do it quickly, you can add to it. You do not need every single feature that landing zone offers. You can use the ones you like. You can spend as much time or as little time on it as you want, but it's not migrating. So I suggest you do a minimal viable one that has the primary components you need and then migrate and then add what you need afterwards.

Beyond the 7 R's: Introducing Minimum Viable Refactoring

Okay, 7 R's. Yeah, this is the simple 7 R's. I'm going to go through this quickly like I said because I feel like I'm beating a dead horse with this, but I wrote it, so you're going to listen to it. So what are the 7 R's? Can anyone even name three of these? I mean, I can't, so I won't raise my hand.

They all start with R though, which makes it extra confusing, so I'm going to break them down. Repurchase means that we're not migrating. Replacing with SaaS, okay. Retain means that we're not migrating, right? It means we're keeping it on premises, okay. Retire means we're just going to shut it off, so we're not migrating that either. That's out of scope by definition. So these three Rs do not represent migration strategies. They represent decisions not to migrate.

It's funny, I was talking to an LLM about this the other day, and what was the joke? It's like deciding where not to go on vacation or something like that. But yeah, they don't help us now. They might be useful portfolio management strategies, they certainly are, but they don't have anything to do with refactoring and migration, right? So they don't need to be made up front. We can make these decisions incrementally, or we can just not. These decisions have nothing to do with refactoring anyway.

Now if we talk about the things that are refactoring, we have a couple of choices and none of them are really good, right? So we have a full migration. Refactor in the seven Rs language means we're going to change the entire application. This is the mainframe, right? So I'd say that's one of the very few examples where you really have to do that. But otherwise it's kind of a bad idea. That's a lot of changes to make while you're migrating, a lot of things that could go wrong. You could do it afterwards and do it with all the tools in the cloud.

Then you have replatform, which is a partial refactor. Okay. Rehost, which is no refactor, known as a lift and shift, and then this really oddball one, relocate. I think this was maybe the most recent one. I guess they wanted another R. It's also a no refactor but from hypervisor like VMware, right? The thing is people could say well those two are different, but it doesn't represent a choice. You don't get to choose whether the application's on hypervisor or not or if it's physical, so it's not a choice, so you don't need another R for it.

So if we remove the Rs that have nothing to do with migration and remove the redundant R, right, we have three Rs left. You see now we have a three Rs model. We've already simplified this. But if you look at this, something becomes very clear. These three Rs are not useful. One is like a complete extreme refactor which you can do if you have to, but otherwise it's probably a bad idea. But it's a valid choice if you want to do it. You have a rehost, right, a lift and shift which really doesn't exist because you're not moving your server to the cloud. Migrate is a misnomer, right? You're going to rebuild it. There's going to be some changes that are necessary.

And then you have replatform, which is something, right? Some amount of refactoring. So what we find is that there's not seven Rs, it's really a spectrum, right? It's an infinite spectrum of how much refactoring we do. Why are we choosing these arbitrary buckets? In fact, these buckets don't help us at all, right? We have rehost on one side, refactor on the other, which are very small edge cases if we think about it. And then we have this giant thing in the middle called replatform, which doesn't give us any meaningful guidance on what to do. It just says we're going to make some changes, but doesn't say what we're going to change. So it's really a one R model. We're going to do something.

And yeah, I think a one R model is good, but I'm going to rename it and call it MVR, Minimum Viable Refactoring, again my favorite minimal viable thing in this presentation. So what we're going to do is we're going to do the right amount of refactoring to achieve our goal, and we're going to do it as we migrate. So we're going to do it iteratively. It's going to be flexible, fast, simple, and safe by doing it this way.

So we're going to start with the lift and shift conceptually, right? We're going to say, if we took this server and we just rebuilt it exactly how it is today in the cloud, what would it look like? And then we're going to realize that's not optimal because some of the things are going to get worse. So we're going to do what I call the Hippocratic Oath of IT, first do no harm, right? We're going to say for security, compliance, reliability, performance, and cost, we're going to do just enough refactoring to make those things not worse, but no more. And then we're going to save the rest of the refactoring for after we're in the cloud because it's just so much easier to do it then and we want to get this migration thing done quickly because the migration is kind of, it should be a non-event. It shouldn't be this long drawn out thing. The key is to get to the cloud as quickly as possible and do your refactoring in the cloud.

The Migration Pipeline in Practice: A Loosely Coupled, Non-Blocking Approach

Okay, so now here's the really animated last slide, well second to last slide, what it looks like in practice. And so what I mean by loosely coupled non-blocking, okay, here's our applications. It goes into stages. So first stage is it gets scoped. So a project manager identifies the app owner, QA tester, the infrastructure, the dependencies, all those other things that we talked about.

They document it. A cloud engineer takes the application and designs cloud architecture for it, which will be really easy because we're going to make it very similar to what we have on-premises. It gets approved by the application owner or stakeholder. It gets built by the cloud engineer, hopefully using Infrastructure as Code, but that's optional. At the same time, you start transferring the data. So it's being built while the data is being transferred.

When both of those things are done, the app owner gets to do their pre-cutover testing and approve it or not approve it. If they approve it, you cut it over and it goes live. Now, we've got to take all of our applications and we've got to put it through this process, right? So this is the one thing I needed help from the agency to help with the animation here. All right, so our monitoring application gets scoped. It gets moved to architecture design while email gets scoped, and you can see kind of how things move through this pipeline. Now this is very simple when nothing's blocked. But as soon as, you know, something's going to get blocked because it always does, right? Let's say, okay.

Approval. We always get blocked looking for approval, right? This is very common. The guy's on vacation or just doesn't want to approve it, doesn't like it. So what are we going to do? Normally what ends up happening here is the whole thing comes to a halt, and web, email, and monitoring will go live, and then everything else waits. But we're good engineers. We realize there's five places where things could get blocked and we're just going to put a queue on there and let things queue up. So then we route around the problem. Hey, file servers can stay stuck in that queue for as long as we want while the payroll application gets moved. And so everything goes through the process. We keep routing around the problem.

This is a simplified version of it. In reality, there's going to be things queuing up all over the place. The key is we want things to move through this pipeline as quickly as possible. Eventually, whatever it is gets unblocked, gets sequenced back in, and then you move it through this process until you're done. This is basically how you can architect the mechanics of a migration in a way that can be done very quickly, and the key is you're not waiting on anyone. Nobody's just sitting doing nothing.

So just the principles as a recap, and then hopefully we can take a couple of questions. If you haven't found this out by now, I'm a fan of going fast. Go slow enough to figure out what you want to do and then go fast. You get your migration done quickly. It should be a non-event. Get to the fun stuff. Simplicity is going to be how you're going to do it primarily. Simplicity increases speed and de-risks things, and it makes things less expensive. You've heard of the migration double bubble, right? Well, I didn't have one because my migration was so quick, right? And so the more you draw it out, the more you're double paying. So make it fast.

Use constraints to force innovation, not just drive it and focus. Invest in your people because that is going to be the make or break detail. If there's any one, that's the biggest one. Momentum is the KPI, so if I talk to a customer who's doing cloud migration, that's what I'm looking for to determine, predict whether they're going to be successful or not. Are they going faster or are they going slower? Momentum is, is it speeding up or slowing down? Doing always beats planning. A little bit of planning is good, but I've yet to see a migration fail from lack of planning. I see migrations fail from too much planning all the time.

It's counterintuitive, but people love planning when they don't want to do the work or they're unsure. Migrate, then modernize. Again, I'm not saying don't modernize. Definitely modernize is the whole reason for migrating. Just decouple them so they're both simpler and less risky. And finally, anybody can do this, but only if they want to do it. Thank you.

---

; This article is entirely auto-generated using Amazon Bedrock.