Using AWS solutions to accelerate customer-led migrations

Rodney: Good morning everyone. How are you doing this morning? Good. We can't see you. Awesome. That's right. That's what we need. We need enthusiasm. So, on behalf of Lynn and Jonathan and myself, we would like to introduce you to S202 - Using AWS Solutions to Accelerate Customer Led Migrations.

Now, my name is Rodney Grill and I'm a product manager in AWS Support. But back in 2010, just like many of you, I was a customer, I was struggling trying to define my strategy to move my customer to AWS to modernize applications and build net new applications. And back then, there was not a lot of guidance for individuals, but it also wasn't as complex. AWS didn't have the hundreds of services that it had today. And luckily, legends like Adrian Cockcroft who was developing and migrating Netflix to AWS to go all in was very generous and he was publishing everything out on YouTube about the challenges that they had and the solutions they used to solve those. So I had that with me and fast forward to 2014, I joined AWS as a Professional Services consultant. And over the next eight years, I spent helping customers just like you to transform as they modernize and migrate to AWS.

And there's so much more that we have available today to help customers than we did back then. And I continued on into my current role as a product manager, but there's many service teams and other solutions teams that we've been collaborating with for years and you're gonna hear more about that today. So with that, I am going to hand it over to them.

Lynn: Good morning. I think it's morning for, for some of you. It may not be morning. How's everybody feeling, staying healthy, taking the emergency? This is a wild week, but uh it's so great to be here. Thank you for your time and attention.

Um Lynn Jones, I'm a senior product manager with AWS support and today we're gonna go through a couple of different genres. So we're gonna start with talking about business drivers and why you may be making your journey to AWS on the cloud. We spoke to a couple of you in the line and it sounds like you're in various stages of making those decisions and various stages of that journey.

And then once you start to make those decisions and know your why we'll identify some common obstacles that you may encounter. And then we're gonna finally give you the solutions that we have to offer to help you overcome those obstacles, help you come up with a plan. What I'm really excited about is we actually have a few experts in the audience as well. So they'll help us with q and a at the end. So make sure that you have those questions ready. We are going to allow time for that.

We're gonna walk through an imaginary example. And then at the, at the very end, we're actually gonna share a real life customer testimonial so that you can believe it from him and not us with orange badges. So with that, see if I can figure this out. Ok, so your business drivers, uh a lot of these kind of top couple that we're gonna go over have probably been in your strategic plans for years.

Um these are the ones that we like to tell our executive staff that we're trying to achieve, but we all wanna move faster and transform our customer experiences, deliver on those digital transformation goals, reinvest the cost savings and innovations into future business models and, and new innovation, uh improve security and resilience.

We've probably, we heard a lot about that this week where rodney and i've spent the last year or so is with customers wanting to lead their own migrations. We've learned a lot with them. They're trying to do things like exit data centers, reduce the cost and fees associated with different licenses from an on prem model. And then um customers who are trying to upgrade differents services like r ds, they're looking for help with these things they wanna do this themselves, but they just need that little bit of added assurance from aws.

So we're gonna share some ideas that we have around that. And then this week especially, we've heard a lot about machine learning and a i and, and i'm sure a lot of you wanna know more about that and how you can use that to help your businesses. So these are reasons why folks are moving to the cloud and then common obstacles.

Once we make those decisions, really come around, who has the right cloud skills? Do you have enough folks inside your organization that know these services inside and out and then you may have them, but there may not be enough bandwidth to help actually operationalize and then execute these migration changes. So that's really the number 1 26% of migrations that we've studied over the last five years really fall into this category.

And then migration planning, really making sure you have the right tools, assets, time resources, money. All of that is is another common obstacle, people and culture issues. This has been really interesting in the last several years with people moving to home, moving back to the office, uh attrition, leaderships changing, maybe you have leaders who are all in on aws and then that person leaves. So this is another common obstacle.

And then technical blockers really kind of goes along with the cloud skills segment. But um just really getting that help when you need it. And the the this is i'm sure a lot of these resonate with you all, rodney.

Rodney: Excellent. So as I said earlier in the early days, there wasn't a lot of prescriptive guidance. But today with our service teams and our solution development from our builders, we think we have a really good story to tell for customers just like you that are choosing to lead your own migrations.

Now, the way we organize these, you've probably seen a version of this slide before we organize customer journeys around three phases, the assess mobilize and then migrate and modernize and, and then we drill in deeper in that. So w during the assess phase, it's really important that you use tools to get an accurate inventory of what you have today.

Now, we were talking with a few of you out in the lines as we, as you were prepping to come in here. And one of the things that was brought up was trying to figure out what you have today on prem. So we have tools to help you do that. So then you can feed that as input into your business case because your business case is going to identify and set how much financing you need to gain from your organization in order to move forward and achieve those business outcomes.

Now, after you get past that and you got your business case, then you, we need to deep dive deeply and you need to understand details about your applications, security requirements, capacity and scaling requirements and how those impact the way you move those applications to AWS. So do they fit into a lift and shift or do you have to do lightweight uh relat or do you have to do more heavy lifting, refactoring and modernization?

So once you have that, then we need to understand the dependencies and relationships between those applications and components because you need to build waves. We have a customer that has multiple thousands of servers to migrate. And in those situations, if you're there, you need to put these together into waves. So you have an orderly safe progression of migrations of workloads into AWS.

Now, where are you migrating them to? You have to have a solid foundation in AWS that meets your security and compliance requirements and that's the landing zone. So now you have all this together, you figured out how to move a couple of applications. Now you have to do it at scale, right? Because you want to reduce your cost and you want to reduce the time it takes to migrate.

And so during the migration and modernization, it's all about that automation and orchestration and we have tools and solutions to help you do that. So you can achieve your outcomes in the shortest amount of time and the lowest cost.

Now, based on that there's other, so many things on this slide that we have grayed out and there's so many sessions and so many things that we can talk about during q and a. But right today, we're only gonna focus on a few of them. And then that way we can drill in deeper as uh we go into the following q and a. So with that, oh, this is still me because now it's here.

Lynn: So before in the landing zone, when we were talking about the landing zone earlier, one thing that customers do a lot of times is they want to start building a solution and they wanna start figuring out how to do a landing zone for example, but they haven't figured out what operating model they want to use first. So always remember you have to source things before you can design them.

And in the sourcing model, we have three main ones. Now, most of you are here because you're it's customer led migrations. So we're assuming that you want to self lead, you want to be able to learn how to do it, learn how to build a landing zone and deploy it and operate it. But in many cases, we see customers over the years that really want to do it themselves. But they run into struggles because as they're trying to maintain the landing zone across multiple regions and accounts, they slow down on their migration and modernization because their small tech teams are so focused on just making maintaining operations.

So we have aws managed services that starts to take some of that load off. It allows you to ensure you have a compliant, secure landing zone and environment to migrate. And then in the future, you can always shift back to self managed once your teams get skilled up and ready for it.

Now, the third is if you're on prem today and you're using partners to manage, you're using si s or uh g si s global uh systems integrators, you might want to do more of a partner managed solution and we have lots of uh a pn partners that are managed services providers. But since you're here in this session, i'm assuming that that's not what you're looking for, but we can also in the q and a session, talk about more about that, but it will impact your decisions on landing zones and other things.

So now lynn is gonna talk about our scenario that we're gonna use.

Lynn: Great. So this company is unicorn company because i have daughters and they like magical things. So this company is magical. Hope you enjoy that.

So unicorn company is facing a variety of conditions. So they are wanting to shut down a data center during covid, they decided that they needed to get out of those data centers and, and move to the cloud and they wanted to be able to quickly do this so that they could innovate and continue to serve their customer needs.

Second, they had uh they needed to move key applications and a w not aws knowledge um to help them with availability, scalability and business agility. Um they wanted to lead their own journey and so they needed to upskill their staff. They needed to make sure that they knew what they were doing, that they had a plan, they had a tight timeline to achieve these goals and they also needed to ensure that they had to protect their customer data. So this is another just essential component of their overall plan and they were, they didn't wanna rely heavily on a partner.

So talking about what rodney was just saying that they, they really wanted to do this themselves. Um but they were starting to stall out. So we're gonna walk through uh a plan that their aws team helped them with. So first of all, uh we, the team identified this customer's gaps and they developed kind of a four pillar approach starting with end to end prescriptive framework and tools.

They decided that they were gonna leverage a tool that's actually in preview right now called aws migration journey have. We're gonna talk a little bit more about that in detail in just a moment, but what this does is really identifies the plan and it's a place for folks to collaborate together, identify those tasks and stay in a single platform to really work those things out. We'll show that to you.

Um the second is around augmenting and building their cloud skills. So for this, we actually helped to ask them to subscribe to a product that was released on monday called countdown premium. And what this does is give an account designated access to a support engineer who could help augment their team with technical skills. This is a different role than their tm their account manager, their cs m. It's someone who sits in inside support, engineering has direct access to support engineering tools and experts. So that was how we're augmenting the cloud skills.

And then we wanted to help them secure cloud foundations and break up their internal silos. So with that, um and the the critical piece around security and compliance, uh we help them work through an experience based accelerator and then the solution landing zone and then the fourth pillar is really around automated solutions so that in time as they're doing these things themselves, that they're able to repeat this process with the framework that we've helped them build.

So really getting into this, we talked about the end to end framework and tools. I'm just gonna jump right ahead. So we actually have the product manager in the room. So if you have specific questions about this, uh we can deep dive a little bit later, but this product is in preview right now.

My name is Jonathan Hutchins. I'm Director of Engineering Services at LegalZoom. Our company does business formations, financial planning tools and easy legal document generation. My team handles developer operations, site reliability engineering, as well as identity at LegalZoom.

About me, I've been working with Amazon AWS since about 2007. This was my third AWS migration and all of the migrations were fairly large.

Some of the biggest challenges that we had were:

• We had a fulfillment system that was designed for accuracy and not efficiency. When it comes to legal documents, it's very important that everything is accurate, but it doesn't matter how long it takes. So we had a bunch of disjointed systems all connecting into each other, very sensitive to shifts and latency.

• It was highly complex because the company has been around since the early 2000s. Most of the subject matter experts who actually designed the system have long since moved on to other jobs and we're left with a system that we're not really sure - is this supposed to do with this or was this an error here? So multiple interdependencies in our systems.

• We had a small migration window of two years and two years seems like a lot of time. But when you have two data centers and you have to shut them down, you have to get rid of all the equipment, shift loads back and forth, it does add up and in two years is actually a pretty small window.

• There wasn't really enough time to refactor everything, but we wanted to be able to refactor what we could and then plan the migration and execute it very, very safely.

• We had a really skilled team. We weren't looking for someone to come in, a set of contractors to come in, do the migration for us and leave us with a system that once again, we didn't know exactly what it was doing. So our team was willing to learn, they wanted to get the training and go along with this actual migration.

Why did we choose AWS?

• It was the ease of integration with our tech stack. We were moving in the direction of Kubernetes. EKS was a simple solution for us to be able to migrate.

• We also have trust in the AWS services and support. Our enterprise support team has been phenomenal. Our technical account managers have been able to help us with finding out what we thought we knew that we didn't really understand.

• So once again, we had full confidence in our team, but we wanted the AWS expertise in case we ran into issues.

We had really large databases that were interdependent using proprietary SQL Server features. Back in the day, the best practice was running your database servers on bare metal hardware. Moving to virtualization requires a mindset shift. You have to actually sell your team on that virtualization has changed and it's actually better and it will simplify things and open you up to be able to do more things.

Our team recognized this. We got a contractor in to help us design our database architecture in AWS. It wasn't as simple as migrate all of our databases to RDS. We did need to run SQL Server on some EC2 instances because we do use a number of proprietary features that only will run on EC2.

But we did receive detailed documentation on what our new architecture is gonna look like, step by step details for us to migrate. And it was a huge confidence boost for our team because we had the plan presented to us, but we didn't, we had a say in it. We were able to actually execute the plan ourselves. So the team gets to learn as we go along.

So uh what were the solutions that we used?

Um well, we used overall, it was Countdown Premium uh which provided a designated engineer um who became familiar with our unique architecture.

Um this also enabled us to have an around the clock team in order to support us during our migration window.

Um AWS Control Tower, uh Rodney and Lynn were talking about that before. Um we followed the Well Architected uh design in order to build our our Control Tower environment.

Um and it's made it really easy to separate workloads. Um we have over, well, I think now over 100 separate AWS accounts all managed with Control Tower. And any time that we switch our a monitoring provider, we can create a um a um we can create a script within Control Tower in order to be able to deploy updated monitoring, updated end points.

Um and it, and it really makes it simple for us to manage our giant environment. Another thing that is really important for compliance for our team is IAM credential restriction. We don't want to have a bunch of IAM um credentials sitting around. And so we made it really hard to generate credentials that way we were um forced to use IAM policies wherever we can.

Um we also, we're in the process of uh containerization. Um our team used Backstage to create scaffolding in order to generate um your GitHub repo for um deploying an application. So the team can go from, take their code, press a button and then uh pods will spin up in all of the environments very easily.

Um and this enabled us to have a new way of deploying applications. So we were able to have all new in all new services that we launched, launch on containers while we were planning on moving our databases.

Um uh behind the scenes. Um and containers, obviously, it simplifies monitoring in the data center. Logs were the bane of our existence constantly filling up disks in EKS. The logs can go to the aggregator and then off to our log uh provider and so very, very simple and security can be standardized.

Um our artifact store is the only uh service that um you can actually pull containers from within our environment. There's a, there's a lot of very cool um features that you can install within EKS um data replication. This was a big one. We had again, a bunch of proprietary databases, limited knowledge on some of the older components. And we had to move terabytes of data to AWS.

Um we had to ensure our downstream data syncs were not impacted. And uh this isn't always popular, but we needed to have a way to fall back to the data center in the event that we did have run into a problem. And so um we had to design our entire migration plan with the plan that we will fail back if we need if we absolutely need to.

Uh we used DMS, it's Database Migration Service, uh native replication and backup restore of our different databases in order to in order to move it.

Um we ran into some hiccups here and there. Um but our Enterprise Support team, as well as um uh the Countdown team was very helpful in the process.

Um so as, as it was coming, coming to a head, we were getting very close to our um to our migration day three days before cut over teams feeling the heat, tensions are really high across the team. And so we had our support team, our AWS Countdown support team brought up to speed by our Technical Account Manager and they were able to coordinate all issues.

Um we validated the roll back roll back plan for like the 20th time and we discovered some last minute issues with the Database Migration Service. We encountered some bugs that weren't expected, but our Countdown team was able to take the issue, work with it around the clock even while we were sleeping. And eventually we were able to resolve the issue, which meant that we were able to meet the date of our migration.

Um and so the round the clock support was absolutely critical. So how did we, how did everything end up? Well, we ended up with five hours of minimal downtime. Uh our plan was to take the site offline at 9 p.m. bring it online at two a.m. I think it was 2:06 a.m. when, when we actually lifted our turn down page.

Um we ran into afterwards 18 p one issues that mostly revolved around downstream data syncs thing since we shifted from native replication to DMS, some things were not working as we, we had planned just due to the difference in the architecture.

Um we also ran into some issues where we decided to keep our on prem load balancer and route traffic back and forth between it didn't work as well as we were hoping. And so we quickly had to create uh load balancers in order to um move the traffic into AWS. But most of the issues we knew we might encounter. So we had a plan in order to solve them terabytes of data were transferred.

Um 450 servers were migrated the night of the migration. All in all, we have hundreds of ser nodes within our EKS environment. So as we were adding new applications and building up our new infrastructure, um that the remainder was 450 servers that um had not been modernized. And we maintained our customer experience.

If you look at the graph behind there with the latency, that was the latency before the migration and the latency after the migration, it the the experience was palpable. The CEO of our company walked in on Monday morning really, really happy because the site was so much faster and you could actually tell it was not uh it it wasn't um it was actually real and so very, very um it all in all. It was a very, very smooth experience.

And, and so uh Rodney and Lynn I to take over. Thank you. Thank you so much. Great. So, thank you for speaking with us. We, we have 24 minutes left, but I wanted to throw up and throw up. Probably shouldn't say that I wanted to display another slide.

Um take a picture of this one because there's a lot of different products that have just released, uh have new updates, go research these because a lot of these, these are coming directly from support, which is where Rodney and I are from. There are product managers in this room. So you guys now have 23 minutes and 45 seconds to tell us what you need. Tell us what you want, ask those deep questions.

We have time, we have the experts in the room. This is your opportunity to tell AWS what you need. Where you have a lot of people in here are are well connected and know where to get more information, get you the right people. But as you can see, these are structured across all the different phases.

We called them a couple of different things today. But we always start with planning and assessment. I talked a little bit about Prime Day earlier when we do those Prime Day events ourselves. Planning is absolutely critical. It's something that we do incredibly well. And now we want to share those tools with you so that you can plan just as well as we do and doing those architecture reviews, uh just so essential AWS Repos Private uh is brand new and we learned a lot about that just a few days ago, I would seriously look into learning more about that. If that's something for you, uh we talked about AWS Countdown.

Countdown comes in two flavors. The first is what you get as part of your Enterprise entitlement. It was called an IEM. It's now just called Countdown. And then the Premium engagement. Is that what you've known as your IEM for a longer period of time and engaging with that designated support expert.

I think I moved too far. Sorry. Um and then as far as AWS Health and Indent Detection and Response, I think I saw the IDR product manager sneak in here at one point. He's hiding. I, I hear him, I feel his smile. He's somewhere in here. So if you wanna learn more about IDR, he's here as well.

And again, as we move further to the side, as we modernize and innovate, and we wanna get you all to that optimization phase. We want you to do what you do best when we can help you with all these things and get you back to your core competencies and where you wanna innovate and grow your businesses. That's success for us. We're all customer obsessed. It's what Amazon does and we're just, we really wanna hear from you so get into the app, give us feedback, stay here, talk to us.

Um let me give you a little more information. So these two first sessions, if you wanna go grab the replay, they already happened. I know there was a customer in here earlier that was interested in the MAP program. So Migration Acceleration Program, we partner with them very closely.

Um they, they have a proven methodology. They, they know how to do this and they just, they're hungry to get better. So absolutely. Go look into that session to learn more.

Um Enterprise 236 the Architecture Led Portfolio Migration. Um again, go grab those on replay. They've already happened and then SUP 313 Tool is in the room. He's gonna be giving a demo of this is in the room who's the product manager for it. So if you have questions about that, again, that's that platform where customers partners internal folks can all collaborate. Follow AWS prescriptive guidance, the things that we've known and done for years.

Rodney used them in Pro Serve. All of that is now packaged up for customers to use. Migration. Journey Hub is free to you. When, when it gets out there, it's still in beta. I know Rooms still taking customers. So if you wanna know more about that, um let's get in touch.

So with that, uh we got one final slide, please complete the survey. Thank you.