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

🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

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 CIO at Live Nation Ticketmaster, shares his methodology for successful cloud migrations based on his experience migrating to AWS in 17 months with no budget and frozen headcount, achieving nearly 50% cost reduction. He presents six key principles: having a compelling why, utilizing constraints to force innovation, investing in people over outsourcing, embracing simplicity, building momentum, and strong leadership. Burns challenges conventional approaches like the seven Rs framework, advocating instead for "Minimal Viable Refactoring" (MVR) and separating migration from modernization. He emphasizes insourcing transformations to upskill existing employees rather than hiring external consultants, creating meritocracies within teams, and using a loosely-coupled, non-blocking migration pipeline. Burns argues that migrations often fail from over-planning and excess resources rather than constraints, and that momentum is the critical KPI for predicting success.

; 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

Good afternoon, everyone. My name is Jake Burns. Today we're going to talk about migrations. This statistic is interesting because it hasn't changed much in the past few years. Cloud computing generates over $100 billion in annual revenue, yet still 85% of the global IT spend is still on-premises. So the question is why? 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 I've worked with are not having an easy time with it. They're struggling in some way.

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. In the past 12 months, I've really focused on understanding why migrating is so difficult. 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.

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

Before this, I was with Live Nation Ticketmaster and I led an all-in migration to AWS. I had a 12-month deadline, largely legacy systems that were not born in the cloud and not meant to be run in the cloud, no budget, and frozen headcount. The team 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, which was the stone age when it comes to cloud. We didn't do it in 12 months; we did it in 17. However, 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%, which is a result of having no budget. It was 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. A lot of the questions I get are how did you do that? Well, the cloud is very elastic, so it's very easy to find the bottlenecks. 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.

Six Pillars of Successful Cloud Migration: From Compelling Why to Strong Leadership

Now I've identified six things that are different between the experience I went through and the experience I see on an almost daily basis and hear from customers on an almost daily basis. 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. First is they have a compelling why. This can't be because we want to save money or because the CEO said so. It has to be something that the people you're depending on, hopefully your own employees, are going to really care about. This should be your company's mission, 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 with a 12-month deadline, no budget, and frozen headcount, and then still was able to be successful, I sometimes say that's why we were successful. A lot of the migrations 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.

Investment is completely key to building momentum in a migration or any transformation, and a lot of this applies to AI transformations as well. Things tend to start off slow, and then as you start winning, that compounds. Inertia can compound as well, or you could just keep going slow.

Embracing simplicity is the next principle, and I would say this is probably the biggest one that I see violated. I see excess complexity, and in my opinion, it is the root cause of failed migrations and failed transformations in general. Most of the things that people do when they migrate are simply not necessary, or the ones that are necessary are far too complex. Last but not least, and this is a hard requirement, is having strong leadership. You have to have somebody who is accountable and has the authority to do things. It does not 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: Why Cloud Migration Is Simpler Than You Think

For the past seven years, I have been talking to hundreds of executive teams on the topic of migration, and I hear the same objections over and over again. I will talk to an energy company and say that what worked for Live Nation Ticketmaster would never work for an energy company. We are special, right? Or the scope is too big. We migrated an eleven billion dollar revenue 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.

The third most common objection, and it is almost always these three, is that we have unique regulatory requirements, so the cloud will not work for us or it is 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 is really just moving your applications and data from one place to another. Sometimes it is a virtualized environment in your data center to a virtualized environment in the cloud. Yes, maybe it is a different technology, but most of us who are doing cloud migrations have done data center consolidations in the past. It is very similar and does not have to be that much different.

I can say this with confidence because I have done it, but I can say it even more with confidence now because I have helped so many others do it as well. It really is this simple. Now there are workloads that are difficult to migrate, such as mainframes, for example, that require a full refactor, but those are unique edge cases. Those are not the most common. A more generalized approach is a better approach. Let us manage by the exceptions as exceptions, and let us take the complexity out of the ninety-nine percent that could be easy.

A good migration framework is universal. It will work in every industry because your servers do not care what industry your business is in. It is effective at any scale because a good framework is a scalable one. You take something that works and you scale it up, and this has been proven with this methodology as well. 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

There are some lessons that I have learned through this process, and some of them can be a little bit counterintuitive. This is one of them: you are more likely to fail from too few constraints than from too many. This is one that people find surprising. It is like, wait a minute, you are going to take resources away from me and I am going to be more successful? Yes, that is usually the case. Most cloud migrations are overfunded and their deadlines are way too far in the future. I had a twelve month deadline and it took me seventeen months. If I had a seventeen month deadline, I think it would have taken me two years. If you give me two years, maybe I never would have done it all.

Some of you may be familiar with Parkinson's Law. Basically, it explains why in college when your homework is due, you do it the night before instead of 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 the time that you have. If you give yourself five years to do a migration, it is going to take five years minimum. Nobody sets out to do a five year migration that takes two years. But you could set out to do a one year migration and take one and a half years. That is a much more common pattern.

When you set these seemingly unrealistic goals, it gives you a sense of urgency. If you do not have that sense of urgency, if you have too much time, you never get started.

If you have too little time, you never get started. If you have too much time, say you have 100 things to do, most of us are going to 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 going to pick one of the top 10 most impactful ones, and that's what the sense of urgency does. The constraint forces you to focus on what matters.

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 going to work for us in the future. If we've been doing migrations this way for this amount of time, why not keep doing it that way? Well, the reason is because we can't, and constraint forces that. 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. It makes for a much more interesting story when the odds are stacked against you and you succeed anyway. You'll be surprised. Instead, you put constraints into motion and then you find a way. A deadline forces you to find a way. For me, I had to begin before I felt ready. I was told to begin before you feel ready. I was given the mandate to migrate in December and started the beginning of January. Why? Because at 12 months, I'm not going to waste any days. I had to focus on what mattered and couldn't get distracted by things. I had to work backwards from a goal.

It's easy—12 month deadline, we're going to 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 and 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. That's where new things get invented. A limited headcount, in my case, forced me to motivate my existing team. I talked about in the beginning how I had a frozen headcount and no budget, so I couldn't hire cloud experts to come in and do the migration. 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.

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. That is, as a leader, one of the most liberating feelings you can have.

Insourcing Your Cloud Transformation: Building Internal Talent Over Hiring External Experts

One of the other things that I see as an anti-pattern is conflating, and this one's a little controversial, conflating migration and modernization. The way you look at it is this: 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. The common objection is that 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. Your apps will be more modern and dated sooner than they would be if you were to migrate and then modernize separately.

Decouple them. Separate the complexity into different stages. Your modernization will be done sooner than if you try to do them both at the same time. Migrate so you can modernize sooner, so you can be in the cloud and you can use all the great cloud services. This is a quote 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 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 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.

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. Why wouldn't it be? Because you're basically telling your team that you have no confidence they could do it, and you're bringing in others to do it for you. It also has a problem where the people you bring in to do it—you're training them and giving them experience—and then they take that knowledge with them when they leave. In my experience and opinion, they should be paying you for that experience. That experience is very valuable, so you're robbing your team of that experience. Additionally, it incentivizes short-term thinking. If you have hired guns who come in, build it, and then leave without having to maintain it, they might cut some corners. But if you know you're going to build something and you're going to have to maintain it, you're more likely to do it in a way that has higher operational excellence.

My thought process here is to 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. 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. In DevOps, you say you build it, you run it. I think that's true and 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 free up their plate so they can work on it, and do your best as a leader to allow them to focus on it. This has a lot of advantages when you do this.

Just being purely selfish, the people that work for you and all the people in your organization already know each other. They already know how to work with each other. When you bring in new people, there's onboarding and complexity with that. They know how your organization works. Every organization has bureaucracy and a way of doing things, and that's a delay. If you have to onboard a bunch of people at the beginning of a migration, then learning how to navigate your organization is extra time that it's going to take. 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. It's going to make your life easier. It's easier to teach your cloud skills to your existing workforce than to teach external people how your organization works. That's the key point there. If you think about that, it makes total sense. Cloud skills are relatively easy 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.

Getting Buy-In: Addressing Fear, Creating Ownership, and Articulating What's In It For Them

I'm making this sound so easy, but there are some problems, and I'll give you some solutions. The first problem is that 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. My answer to that is: what are you so busy doing that you can't do a cloud migration, cloud adoption, or build this new app in the cloud? Whatever that answer is, outsource that. That's undifferentiated work—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 that if they do this, can they even do it? Will they succeed? 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 about whether they'll have the skills to maintain this new cloud environment. They're worried: am I engineering myself out of a job? There are a lot of things that they have to be fearful of, so we need to address that.

Give them a safety net. They may not vocalize it, but they need the safety net. 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 this. Bring in experts, AWS Solutions Architects, professional services partners—all these people who can help them and guide them in the beginning. You really just need to get buy-in from them. 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. Let's talk about how we solved the 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.

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. 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 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 he does there. 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. When you instill that mentality in them, then they will be enthusiastic. 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 and allow them to look at it. It's not a free for all, but if you have a better idea, tell me. We have what we call tenants at Amazon, and it always says these are kind of like principles, leadership principles for projects and teams. It always says unless you know better ones, these are our tenants. 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 for 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. The fact that you're sharing what you're going to do gives them confidence that it actually can be done. 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? I think this is an easy one with cloud. With the cloud, you can 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. 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. If 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. You should ask me for a raise. That 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.

Upskilling Strategy: Timing, Training, and Becoming an Organization That Attracts Top Talent

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 has 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. That was a lot to ask.

You don't necessarily have to do training and migration at the same time, but the next best thing is to do the training immediately before the migration. If you have any interval in between, that knowledge tends to get forgotten. So putting it into practice as quickly as possible is super important. Use all available means. AWS has a lot of free resources that we can give you for training, solution 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.

You may have to hire after you've given everyone in your organization a chance to fill new roles in the cloud. Please give everyone a chance first—this is super important. You may have gaps, and you'll need to hire for those gaps. 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. I've noticed how many agentic AI engineer job postings there are, and they all want three years' experience or five years' experience. 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. Existing skills is a good base to have, of course, but do you want to pay a premium for that?

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 cloud experience, and no one's giving them a chance. These people you can get for an incredible deal. You upskill them, and then you have that pipeline. Lastly, you have to become an organization that attracts top talent and top performers. You may have heard the quote: become the person that attracts success. It's 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.

They want to work for an organization that's going to allow them to become more valuable over time through hands-on experience and training. So become that type of organization and work on interesting stuff. 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. You don't get to choose whether you have a problem. You just get to choose which of those problems you have. 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. For them, recruiting is sorting through all the resumes that get sent to them. Be attractive to top performers, and the talent will come to you.

Organizational Structure and Meritocracy: Creating a Minimal Viable Center of Excellence

All of these things help a little bit, but none of them is going to get you all the way there. Another anti-pattern is elaborate committees and organizational structures. I don't think that this helps very much, so I advocate for a very simple structure. 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 that I rebranded as cloud services. This could be DevOps folks, but these are the people who are going to do it hands-on. You have an advisory board. I like to call it the Minimal Viable Center of Cloud Center of Excellence. It's very lightweight and very informal. You have finance, HR, infosec, and one leader from each of those just to agree on policies and how we're going to do things, but not to micromanage. It shouldn't take very long to set up. And then you have stakeholders, which are everyone else in the organization. These are who you serve as a cloud team. These are application owners or business unit owners. Typically it's application owners—the app folks. So yes, infrastructure people, you have to answer to those 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 working out in the end. This is a very simple structure, and this is really all you need. This is all I used, and this works at any scale. This could be set up in a day, really. It's not that difficult to do.

Now, regarding the stakeholders, we're going to ask as little from them as possible and give them as much as possible. All we're going to ask for is agreement on the cutover date, agreement on the cloud architecture if you even care about how we architect it, and permission to migrate it to the cloud. Then do however much testing you think you need to do at the end to ensure that it works. 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 alluded to this earlier. Another benefit of doing it this way is that the migrations tend to work and don't have to be migrated back because we make very little changes.

Now, let's create a meritocracy. 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: 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, and one of them wasn't. Put them in leadership positions that enable them. They're going to be the ones that prove this could be done to everyone else.

You have the passive majority. Obviously, that's the most amount of people because it's got majority right in the name. They're usually just going to go which way the wind blows. If this thing looks like it's going to be successful, they'll support it. If it looks like it's going to fail, they'll have no part of it. So they need to be won over, which means we have to start winning quickly. That's part of the strategies we need to employ. Then you have active resisters, and most organizations have these. The thing is, don't fight them. My suggestion is to embrace that because think about it. The early adopters and to some extent the passive majority are the ones complaining we're too busy. The resistors, the ones we lovingly call server huggers in the cloud migration industry, let them manage the servers and keep the lights on. Let them manage the outsourced team that's doing the quote-unquote boring work. They love doing that kind of work, and they will come around eventually.

Other things you can do here within this meritocracy is create new career ladders. I did something interesting. You have your career path, your technical track, your manager track, and then I added a cloud track. It sends a clear message when the cloud track actually has more rungs on the ladder than the other two tracks. Create incentives. If you want to get promoted and reach a higher level in this organization, this is the path to do it. Give opportunity to everyone equally. One of the things that's going to happen is people are going to complain and say, how come that person gets to be on the cloud team and I don't. The way you get around that is to say the cloud team gets to set the rules of who's on the cloud team, and now you live with your own rules. We're trying to make this as fair as possible, not to be charitable, but because it works.

When you create a meritocratic system, you get better results because what ends up happening is those who produce more results get more responsibility, and those who produce less get less. It creates incentive structures that work and gets the right people involved. Be transparent about all of this. Let them own it. There are no hidden qualifications. All the qualifications are there. 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. If that's the rule 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. Create these rules, let the cloud team own it, and apply it to everybody.

The Minimal Viable Migration Plan: Building Momentum Through Quick Wins

Now we're going to cover more information here because this is where it gets into the mechanics of it. How do we actually migrate? I've been talking about culture this whole time. Well, ninety percent of the problems are culture, but let me give you some tips on the actual migration mechanics because this was a little unique in how we got this done so quickly. I've been able to replicate this with other organizations I've worked with, and I do believe it is universal. I 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 you can challenge me in front of everyone.

What we want to do is focus on the goal and not 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. The things that are necessary but maybe don't make the migration happen quickly, we're going to simplify as much as possible. We're going to embrace this minimal viable framework.

We have minimal viable committees, as I talked about before, and we have a minimal viable migration plan, which we're going to talk about now. I suggest creating a minimal viable landing zone, which is again somewhat controversial. It should take days or weeks, 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. Finally, my favorite is minimal viable refactoring because that completely eliminates the seminars. I'm going to go through that quickly.

We want to make the process loosely coupled and non-blocking. If you're an engineer, you know what that means. It means one thing does not block the other, and it's almost like a microservices architecture. That's what you get if you put an engineer in charge of a cloud migration, and it worked for us. Let's go over it in detail.

Here's the minimal 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 so you know what infrastructure to migrate. You map the dependencies, if any, and in my experience there are far fewer than what most people think. We're going to determine the sequence, and there's a formula for that which is really easy. Then we're going to create cutover dates and work backwards from the deadline because we're going to have a deadline.

Here are applications, or mock applications. We're going to go over a very simple example here. We're going to order them from easiest to migrate, least business critical, and most stakeholder support. Those three dimensions go first, and then the most difficult to migrate, most business critical, and with 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. The idea is that we want to get some quick wins here because we have to win that passive majority.

Now we're going to turn that into a migration plan. 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. Here's why I do it this way. The importance of momentum is critical. When you talk to people who've done successful transformations or migrations, it's always a very happy story. Everybody was a supporter from the beginning, everybody helped plan it, everybody was a sponsor. That's because of survivorship bias. You're talking to the successful ones. You don't talk to the people who did failed migrations. There are no owners of those.

So how do we do this? The problem is that in the beginning you haven't done anything, so why should anyone in your organization support you? Well, the way you break the cycle and get it started is you start with something very small, maybe comically small, like a single web server. 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. You make a lot of noise each step of the way. Say we just migrated a simple file server. I'll throw a party over that. In the beginning, I want everyone in the organization to know. I want that 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.

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 and a minimal viable landing zone. I'm 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 a 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, then migrate, and then add what you need afterwards.

Rethinking the Seven Rs: Why Minimal Viable Refactoring Is the Only R You Need

Okay, the seven Rs. This is the simple seven Rs. 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 seven Rs? 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. See, that makes it extra confusing. So I'm going to break them down. So repurchase.

Repurchase means we're not migrating—we're replacing with SaaS. Retain means we're not migrating; we're keeping it on premises. Retire means we're just going to shut it off, so we're not migrating that. That's out of scope by definition. These three Rs do not represent migration strategies. They represent decisions not to migrate. I was talking to an LLM about this the other day, and the joke was something like deciding where not to go on vacation. They don't help us now. They might be useful portfolio management strategies, certainly, but they don't have anything to do with refactoring and migration. So they don't need to be made up front. We can make these decisions incrementally, or we can just not make them. 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. We have a full migration. In the seven Rs language, refactor means we're going to change the entire application. This is the mainframe, right? I'd say that's one of the very few examples where you really have to do that. Otherwise, it's 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 with all the tools in the cloud. Then you have re-platform, which is a partial refactor. Rehost is no refactor, known as a lift and shift. And then there's this really odd one: relocate. I think this was maybe the most recent one. They wanted another R. It's also a no refactor, but from hypervisor like VMware.

The thing is, people could say those two are different, but it doesn't represent a choice. You don't get to choose whether the application is on a hypervisor or physical, so it's not a choice. You don't need another R for it. If we remove the Rs that have nothing to do with migration and remove the redundant R, we have three Rs left. We've already simplified this. But if you look at this, something becomes very clear. These three Rs are not useful. One is a complete extreme refactor, which you can do if you have to, but otherwise it's probably a bad idea. It's a valid choice if you want to do it. You have rehost, a lift and shift, which really doesn't exist because you're not moving your server to the cloud. Migrate is a misnomer. You're going to rebuild it. There are going to be some necessary changes. And then you have re-platform, which is something—some amount of refactoring.

So what we find is that there's not seven Rs. It's really a spectrum—an infinite spectrum of how much refactoring we do. Why are we choosing these arbitrary buckets? These buckets don't help us at all. We have rehost on one side and 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 re-platform, 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.

I think a one R model is good, but I'm going to rename it and call it MVR—Minimal Viable Refactoring, my favorite minimal viable thing in this presentation. What we're going to do is do the right amount of refactoring to achieve our goal, and we're going to do it as we migrate. We're going to do it iteratively. It's going to be flexible, fast, simple, and safe by doing it this way. We're going to start with the lift and shift conceptually. We're going to say, if we took this server and 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 things are going to get worse.

So we're going to do what I call the Hippocratic Oath of IT: first, do no harm. 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. We're going to save the rest of the refactoring for after we're in the cloud because it's so much easier to do it then. We want to get this migration done quickly because the migration 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.

Migration Mechanics in Practice: Loosely Coupled Pipelines and the Principles of Going Fast

Now here's what it looks like in practice. What I mean by loosely coupled, non-blocking is this. Here are our applications. They go into stages. First, the stage is scope.

At this stage, the project gets scoped. A project manager identifies the app owner, QA tester, infrastructure, dependencies, and all those other things we discussed. They document it. The cloud engineer takes the application and designs cloud architecture for it, which will be straightforward because we're going to make it very similar to what you have on-premises. It gets approved by the application owner or stakeholder. It gets built by the cloud engineer, ideally using infrastructure as code, though 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 put them through this process. This is the one thing I needed help from the agency with for the animation. Our monitoring application gets scoped. While it gets moved to architecture design, email gets scoped, and you can see how things move through this pipeline.

Now this is very simple when nothing's blocked. But as soon as something gets blocked, because it always does, let's say we get blocked on approval. We always get blocked looking for approval. This is very common. The person is on vacation or just doesn't want to approve it or doesn't like it. So what are we going to do? Normally what ends up happening is the whole thing comes to a halt, and web, email, and monitoring will go live while everything else waits. But we're good engineers. We realize there are five places where things could get blocked. We're just going to put a queue on there and let things queue up. So we route around the problem. File servers can stay stuck in that queue for as long as we want while the payroll application gets moved. 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. 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 figured 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 so you can get to the fun stuff. Simplicity is 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. 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 principle that's the biggest one, it's that. Momentum is the KPI. If I talk to a customer who's doing cloud migration, that's what I'm looking for to determine and predict whether they're going to be successful or not. Are they going faster or are they going slower? Is momentum 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. Finally, anybody can do this, but only if they want to do it. Thank you.

---

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