🦄 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 - Agentic AI for VMware migrations with AWS Transform for VMware (MAM202)
In this video, Sean Lewis, Rajesh Rathod, and Harpreet Virk present AWS Transform for VMware, an agentic AI solution designed to accelerate enterprise migrations. They explain how the service addresses both technical and organizational challenges that typically extend migrations to 1.5-2 years. Using a fictitious customer "Ultimate Bank" with 4,000 VMs across 4 data centers, they demonstrate the multi-agent system that handles discovery, assessment, migration planning, network conversion, and server migration. Key features include human-in-the-loop collaboration, support for NSX, Palo Alto, Fortinet, and Cisco network topologies, automated infrastructure-as-code generation with CloudFormation and Terraform, and multi-account/multi-region capabilities across 8 regions. The demo shows the chat-based interface for importing inventory, creating wave plans with business context, configuring target accounts, and executing migrations. Real customer examples include CSL achieving 30% operational cost savings while migrating 5,000 VMs from 29 data centers, and Vector reducing TCO by 35% with 34% faster migrations. The service is available at no cost and integrates with AWS Application Migration Service (MGN).
; 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
Introduction to MAM 202: Agentic AI for VMware Migrations with AWS Transform
Good morning everybody. Welcome to MAM 202, Agentic AI for VMware migrations with AWS Transform for VMware. This is a silent session. You all have the headphones in front of you. Just a quick audio check. Can everybody raise your hand if you can hear me okay? Alright, looks like folks are working. If you have any audio issues during the session, you can grab another set of headphones near you or go in the back, and our crew will help you out. Thank you for making the time today.
We have an hour to walk you through what we're doing with AWS Transform for VMware, helping customers accelerate their migration journey with the power of agentic AI. My name is Sean Lewis. I'm the Director of Infrastructure Migration and Modernization here at AWS, and I'm going to be joined today by a couple of my colleagues, Rajesh Rathod and Harpreet Virk, who will come up and drive part of the session as well.
We're going to walk you through some content on Transform, and we're going to give you a hands-on demo of Transform for VMware. We also have some follow-up sessions that we'll talk you through, including workshops. I know folks are very eager to get hands on with the new service and the offering. So we're going to walk through this in a couple of chapters for you. I'm going to start by teeing up the challenge that customers are facing when it comes to migrations. At AWS and Amazon we always work backwards from our customers. We hear what you say, ask what you're asking for us to build, and then we go attempt to solve those problems for you.
Then Rajesh will walk you through the solution, what we built with AWS Transform, particularly for VMware. And then Harpreet will do a technical deep dive where he will walk you through the service and we'll actually get some hands-on experience with it. You'll get an in-depth demo and then we will close with a couple of customer stories and some resources for you to take next steps around Transform.
The Current State of Enterprise IT Migration and Ultimate Bank's Challenge
So the current state of enterprise IT migration, optimization, modernization, and the broader transformation landscape that we're seeing really paints a picture that customers are asking for a lot of help on how to go faster and how to significantly migrate more workloads to AWS. A couple of stats: Gartner says 70% of all IT workloads are still on premises. While AWS has grown tremendously, you heard Matt talk yesterday about the $132 billion annual run rate business that AWS has become. Thank you for being customers of ours. We still have so much more opportunity to help customers migrate workloads to AWS.
70% of legacy IT software that Fortune 500 companies run was written over 20 years ago according to McKinsey. This is software that may no longer have the developer at that organization any longer. There may not have been good documentation or notes in the source code to indicate why design decisions were made. The software may be tied to older infrastructure platforms or have other dependencies that make it more difficult when it comes to security, modernization, performance, resilience, and other challenges that customers are facing with these legacy enterprise apps.
1.5 years is the average time to migrate from start to finish according to IEG. When you think about these challenges where customers are starting a migration and then working through the different waves associated with the migration, what we heard consistently was faster time to value and a better way to be able to execute migrations at scale using automation and the power of technology.
Today we're going to walk through a fictitious customer example, but this is a compilation of different customer elements that we've heard as we've engaged with customers to assist in their migrations. The name of our fictitious customer today is Ultimate Bank. Ultimate Bank is a financial services organization with 4,000 VMware VMs distributed across 4 different data centers. They have a lot of different technology components and this is probably starting to sound like some of the organizations that you work with or you've worked with in the past.
There's mainframe workloads inside of Ultimate Bank, Windows workloads, analytics, disaster recovery, high performance compute, and lots of different aspects of their business are represented across those 4,000 VMs in those 4 data centers. The application teams that support those apps are sometimes connected into core IT, sometimes they're not. Sometimes they report into the line of business, and they are distributed all around the world.
The customer also has a lot of security infrastructure that they've built up to be able to harden their on-premises infrastructure. They've worked with partners like Palo Alto. They have VMware NSX in place. They are working on their cloud transformation. They've built a team that's comprised of IT leadership, app owners, and their infrastructure teams, a partner called Lotus Consulting, also a fictitious partner and a Premier AWS migration partner, and then our AWS team.
AWS Migration Pathways: From Relocate to Refactor
We partner with Premier AWS migration partners and our AWS migration specialists and ProServe teams to assist. When we talk to customers about their migration journey and their strategy, we often discuss migration pathways. AWS offers flexibility and choice for customers. We know that you don't want to be pushed down one particular pathway. We've heard that loud and clear from customers. You would like to look at the different options available to you, and multiple pathways may be the right solution depending on the workload.
When a customer is looking at something like an infrastructure migration, we typically start with a couple of these pathways. The first is the relocate pattern with Amazon EVS, our Elastic VMware Service. This provides VMware in AWS running on bare metal AWS instances. You get VCF and all the components of the VCF stack running in AWS. You can migrate VMs into EVS using native VMware tools. Management, reporting, and orchestration are all available as part of your VCF environment running on EVS.
Rehost involves taking virtual machines that are on-premises and rehosting them into Amazon EC2 Elastic Compute Cloud. Re-platforming to containers means customers are taking on-premises VMs and moving them into some of our container offerings such as Elastic Kubernetes Service, EKS, or Elastic Container Service, ECS. Re-platforming to managed services could include offerings like Relational Database Service, Workspaces, our virtual desktop infrastructure, or FSX, our managed file systems. These offerings allow AWS to manage the database for you or your VDI infrastructure so that you can focus more on delivering business value to customers.
Then of course there is refactoring, which involves taking a monolithic application, breaking it down, and rebuilding it using serverless, microservices, and other components that will allow the application to run in a more cloud native fashion. For this migration, our customer Ultimate Bank chose rehost, and they're going to use AWS Transform for VMware to rehost those 4,000 VMs into EC2. Now I'm going to hand over to Rajesh who's going to walk us through the AWS Transform for VMware content.
Understanding Technical and Organizational Migration Challenges
Thank you very much, Sean. As Sean articulated, this is a big opportunity, but you know this represents the kinds of challenges our customers face. We took the example of Ultimate Bank, which is representative of many other customers that we've talked to. When we started working on agentic AI solutions, there were many use cases, but we wanted to dive deep and understand the reasons why it takes 1.5 to 2 years for doing large scale migrations. What is happening with those customers, and what we found is there were two types of challenges: one was technical and the second was organizational.
Technical challenges are well understood. These are old systems, monolith systems that are not well documented. There are complexities and dependencies all around, and there are no good sources of truth. There is also a lack of automation and testing. Customers generally worry about touching those systems if they can't really test them well. But what we learned is that along with technical things, the challenges that we had to solve with agentic AI are also organizational.
With different ownership and different lines of business, many people have to say yes or approve and review things that slow you down when you want to migrate. There are also prioritization issues where the resources who have the right skills have already left, or they don't have access to the systems, or they are busy with other projects. How can you address the scarcity of resources? We also learned that none of these projects can be done by just one team. You end up bringing a partner, bringing AWS professional services, or different parts of your organization, and then collaboration between all of the stakeholders and having one source of truth becomes the key requirement.
Because of this, projects that could be completed in months were going to take years. Projects were getting stalled, innovation was slowing down, and business growth was not happening for many of our customers. So we said this is an important problem for customers, and hence we introduced AWS Transform for VMware to start with the VMware migration journey and see how we can address some of these challenges that customers are facing.
AWS Transform for VMware: An Agentic System with Multi-Agent Architecture
AWS Transform for VMware is part of a bigger service called AWS Transform. Collectively, the service has capabilities for migrations and modernization for Windows, as well as mainframe and SQL Server databases. What we launched on Monday was custom capabilities, so you can transform from any state to any state. These are now all part of AWS Transform, and this is our agentic system.
To understand what an agentic system really means, I think we need to collectively level set on certain definitions. When generative AI started, people were building AI systems where you ask a bunch of questions and AI will generate code and give you specific answers. That was good for solving certain problems. But then came AI agents. Those agents were achieving a singular purpose. You tell the agent to convert from CloudFormation to Terraform, and it will just do that part. Then you invoke another agent which will do a second part, and you can address a lot of things but execute them like in a workflow.
We realized that migration and modernization involves a ton of tasks and a ton of things that you need to do. Bringing that together and tying it to a business purpose is the right strategy. Rather than you stitching together this whole experience, we provide a multi-agent system. That agentic system is going to take your business goal and start modernizing or migrating your applications. We had two choices: one is to make it fully autonomous, and the second is to have humans in the loop. We realized that 70 percent of our migration and modernization projects have a partner involved. Multiple specialists have to come in, validate, and then only you make those critical decisions. So human in the loop was a big part for us, and that's why we wanted this agent to not come across as replacing humans who are doing their task, but rather become a team member. When you are doing a transformation project, this agent is part of your team.
So it has increasing autonomy and business impact, and that is the system. So how does that come together in the case of VMware? Think of VMware as a set of distinct tasks which have its own domain. You discover and assess, which is where you create your business plan, identify all the dependencies, and create your migration strategy. That is a domain in itself. So we have an agent as part of a bigger VMware migration agent which takes care of that functionality.
Second is migration planning. You don't want to just look at the technical dependency. You also want to look at your business factors, some constraints that you have, ownership, and business priorities. Bringing all of those things together in migration planning is the second agent. Third is network. Sean mentioned network topologies, and what kind of ultimate bank has so many different security systems. For you to mimic all of those things and bring it into AWS is a big undertaking, and a lot of the time you end up doing those work manually. So how we can bring network conversion and migration as an agent is a capability. Finally, you need to deploy all of these resources into AWS. So how do you migrate those servers? These are things that we collectively brought together.
Technical Architecture and New Goal-Seeking Workflow Capabilities
Initial launch from our side had specific considerations on technical architecture which we have seen that customers really like. Any such systems where you are giving your metadata or data to an agent to perform certain tasks, you always want to have the right security boundaries. So what we have is a bunch of tools that we provide for your on-premises environment. Those could be for exporting your NSX rules, getting data from your vSphere environment, or a replication agent which goes and takes your VMs and actually replicates them to AWS. Then we have an account where AWS Transform functions. It orchestrates everything, provides the security provisions, right access, and supports your multi-account setup.
So that's one account. Then you bring in two accounts: your own account, which is where you want to import all your inventory. Any data that you want this agent to know for your migration, we want to give you control. You define the account, and in that account you can bring the inventory. Finally, you define the destination account, the account in which you want to migrate all your servers and networks. That could be one or many accounts. This is the architecture that we followed. It has that separation, it has the governance, and it can scale even for large data center exits.
New things that we launched on top of this architecture this Monday is a goal-seeking workflow which combines migration assessment, server and network migrations all in an agentic manner. You can start with any specific task, add other things, or remove things, so you have full control and flexibility on how this planning is happening. In that large-scale migration planning, we brought in business context. Your business context is not always some CMDB data. It might be a wiki page, a document, your rules, or internal guides. You can provide all of those things to transform. When a plan is created, it accounts for all of those things that you want in the plan, which reduces the manual work that you have to do later on.
Another thing that we realized is these are long-running agents. Some of these tasks will probably complete in a few weeks. You don't always want to read documentation and figure out what the next things are that you need to do. These agents are constantly guiding you, telling you that I need input here, I'm stuck here, or these are some of the choices that I have—how do you want me to make decisions. The agents will always tell you what the next steps are. While it is in automated execution, it allows you to do parallel execution. If you have twelve migration waves happening and you want to start with migration wave one and four because of your business priorities, you can do that. Or while it is doing migration planning, you want to start setting up your connectors to target accounts. You can do things in parallel. There is a lot of optimization that we have brought in, and this is how the new experience looks.
Collaboration Features and Migration Assessment Agent
This is a new experience where you will be starting with chat. You can ask AWS Transform to summarize the progress and give you all the artifacts that it has generated. You can download them and inspect them. There is a common approval process, so critical tasks which require approval, you can go and track what approvals you are providing. All the artifacts which agents are generating are available for you to inspect.
When we started looking at the scenarios that you know a partner coming in with AWS ProServe and customer together, we wanted to bring that into AWS Transform where there is one shared workspace in which everybody is collaborating, so there is a single source of truth. The administrator of the workspace is going to define different roles and give people access on what they can do—who is a contributor, who is an approver, who is an administrator, all of those things. This brings collaboration together and all those silos that you have in your organization who needs to approve what data they need, everything is sorted out.
Another thing that we did is a lot of the time you need help from support or shared organizations, so we brought in our AWS support also into here. With chat you can say that hey, I'm stuck here, I need help, and if you have premium support, then our premium support team will get invoked and they will go ahead and help you with those migration projects or any issues or troubleshooting that you need. All of those collaborations bringing stakeholders together is something that we have done, and this is how it looks in the system. If you go to the workspace in this example, I have a lot of consulting folks who are going to help me with the migration projects in the same workspace with a specific role given to them. Our AWS team, including Harpreet, is there. The customer CIO is part of the same workspace, so they can all collaborate and work on that particular project.
Now looking at how you should progress, one thing that I have seen in all these migration projects is that it is sometimes very hard to get started
and figure out which application to migrate first, how much it will cost, and where to provision resources. The migration assessment agent in AWS Transform is a good starting point. You can provide whatever metadata you have for your VMs, your storage, and other resources to the assessment agent, and it will create a business case for you. It will handle right sizing, provide the target infrastructure you need to deploy, show you how much it will cost, and give you information about savings plans and other pricing details.
Once the agent generates an artifact, it also provides a good summary of what it generated. You can download this artifact as a PowerPoint presentation to get approval from senior leadership. You can get a spreadsheet if you want to inspect which VM is getting mapped where and what instance is being used, or you can chat with this artifact. In AWS Transform, you can ask any questions. Why is my cost this much? If I move from a one-year to a three-year plan, how much will it cost? What licensing assumptions have you made? All of those things are readily available.
What used to take three or four weeks for creating your initial plan and having meaningful discussions can now be done in two hours, and you can be ready to think about how to get started. I recommend that people always start with assessment. What we also added is that once you are happy with the assessment result and want to start migration, you can directly click a button and say, use the same context and start my migration project. You do not have to do the discovery and data collection again. It is a continuous flow from assessment to your migration agent.
Flexible Migration Scope and Enhanced Planning Capabilities
When you start doing migration, it will ask you to give a scope of what exactly in VMware migration you want it to do. Earlier, these were set workflows. If you selected network migration, it would do X, Y, Z for you, and once you started that job, you could not get out. You would have to create a new job. Everything changed on this Monday. You can start anywhere. You can say, let us just do discovery and server migration. It is not going to include anything related to network. You start doing migration and say, hey, this is good. I actually want to provision my network also with that. You can tell the agent to include network migration as well.
Or you started with end-to-end migration and you say, my network people are kind of busy right now. I want to skip that part, or I have already provisioned certain resources or I have a plan, just use the plan from another job. All of those things you can do. You can take artifacts from a different workspace, a different job in the same workspace, and reuse them here. That is the agentic capability that we have brought in here.
One more thing which we got a lot of feedback about is that customers wanted control on what kind of data is shared with AWS Transform. They did not want live data sync because a lot of the time you have a big footprint on premises and you do not want to migrate all of it. What we did is we built a discovery tool. This discovery tool you can run in your vSphere environment in the source. It collects all the data. It does not have any internet connectivity. It does not send any data to AWS Transform. You have visibility of the data it collected. Then you inspect and decide which things are relevant for your migration project. Then you go ahead and import that into AWS Transform. So it is self-contained, secure, and you have full control on how this discovery data will get used.
I said, okay, this solves the problem where people want to discover resources on premises. But then I said, hey, I have already done a lot of discovery with some other tools. I had to use Cloud Demise. I have Modelized IT. I have done some other assessment. So what about that? Why should I even use this tool? So we said, okay, we are going to give you flexibility. Import anything. You can import things that you got from your discovery tool. You can import from any third-party tools, RV Tools, your migration evaluator, even simple Word documents or spreadsheets that you have in any format. Earlier you had to stick to a specific format in which you provide the data. Now, no. This is all LLM-driven. You give data, we will synthesize it.
We tell you what we found. We create a wave plan based on that analysis, and you approve whether you like it. The system also provides a confidence level for each recommendation, so you know how confident we are that we have mapped everything correctly. This allows you to take actions based on that confidence level. These are the new capabilities we added to the platform.
We also worked on migration planning. We realized that for cases like Ultimate Bank, where they have 4,000 servers and need migration planning, you cannot simply wait for an agent to figure out all network dependencies and return results. It would not scale. There are many different parameters now that the LLM can understand based on the inputs you provide. We now have a migration planning agent that can scale for more than 1,000 or 2,000 VMs and will give you a plan that considers both technical dependencies and business context.
The best part is that the agent also summarizes everything for you, including what considerations were used in creating the migration plan. If you want to alter any of those considerations, you can do so. For example, the agent might have prioritized travel expense applications, prioritized Linux over Windows, or prioritized reducing data center costs. If you want to change and flip some of those priorities so that you prioritize for speed instead, or if you need to exit a data center quickly and do not want to wait for fully optimal solutions, you can tell the agent all of this in clear language. The agent will understand and revise the plan for you accordingly.
These planning improvements provide you with a summary that you can send to other stakeholders for approval before moving forward with the plan. At any point in time during your migration project, you can ask the agent to summarize things or do things differently. For instance, if your business priorities have changed from the second wave onwards, you can ask the agent to revise your wave plan, and it will do that for you. There is a lot of control available to you as practitioners with all of these agents.
Network Conversion, Server Migration, and Multi-Region Support
We then started looking at network conversion. This was one part that was very tedious and required a lot of skills. Network experts who understand VMware often do not understand AWS, and if they understand AWS, they may not understand VMware and how everything maps. Getting people with hybrid skills across both platforms is not easy. We evolved this capability to start adding more topologies and more source environments. Initially when we launched, we accepted VMware, RV2s data, and NSX. We found that many people use Palo Alto, Fortinet, and Cisco, so we prioritized those three and provided support for them as well on both mainly used target topologies.
We support hub and spoke and isolated VPC architectures, and we have an agent that reads all the source data and translates it into AWS equivalents. Your VPCs, subnets, and elastic IPs all get created automatically. However, we knew that our customers and partners needed control. They wanted to see whether AWS Transform should automatically provision these resources or if they wanted to provision them themselves. So we started working on providing you with a summary of what we have identified so you can review it. If you feel comfortable with AWS Transform provisioning everything, we will provision all these resources for you.
If you want more control, you can provide specific requirements. You might want to retain your IP addresses, change your IP addresses, or change your CIDR ranges. You can provide all of those specifications and ask us to create infrastructure as code for you, which you can then manage yourself. We have CloudFormation support and Terraform support, so you can decide whether you want to deploy by uploading the CloudFormation template back into our service, or whether you want to use your own deployment tool to deploy those resources and continue. Once you are done and resources are tagged, your rehost agent can continue migrating with that infrastructure. This setup can also work with multi-account migrations. Earlier, it was single-account migration where one job could migrate to one account. Now one job can migrate to multiple accounts.
So if you want to use different accounts for different applications or your accounts are different, all of those things you'll be able to do now with AWS Transform. A big part where a lot of time gets spent in multiple waves is our server migrations. We realized that when customers are running these VMs, not everything is virtualized or their applications are not everything is virtualized. For VMs we have Windows servers and Linux servers supported, but we started supporting any X86 architecture with VMware vSphere, Hyper-V, or Nutanix and bare metal. So any of those systems now we will be able to migrate with AWS Transform.
The way you can see this agent is kind of becoming more of a general purpose migration agent with special domain knowledge around VMware networking and wave planning. You get the wave by summary. You can set up the application agent. It uses AWS Application Migration Service technology to start moving resources to AWS your target account and everything you can track from one tool. AWS Transform is going to give you end to end tracking of what progress you are making.
And finally, once it is migrated, AWS Transform will have that context if you want to modernize and support. A few things on server migration that I would highlight is it has a web-based approach with built-in functionality for rollback. While migrating a particular wave, if a few things change and you want to deprovision those resources, you'll be able to do that, or if it gives an error and you want to resolve that error, you can ask the agent to provide you guidance on how to resolve it.
With the AWS Transform chat, now it has knowledge of all AWS services. You don't have to go to any documentation. You can ask questions. Hey, what is Elastic VMware Service? Tell me more. Or how is IPv4 and IPv6 supported in VPC? What are the subnet groups? While you are here in AWS Transform and you're inspecting, you can ask those questions. It also has knowledge of all our prescriptive guidance that AWS has created based on 19 years of experience of migrating and modernizing many data centers.
So it is going to give you all those best practices readily available here. You don't have to go and do any search or read a bunch of documentation. It has full knowledge about our user guide. You don't need to read 500 pages of user guide. It is going to give you all that context here. So throughout your migration project this becomes one place where you go and execute your entire project.
Regional Expansion and Transition to Technical Deep Dive
Other thing that we added is this multi-region support where initially we were in just two regions. Now we have expanded that to eight, and I'll talk about that in the next slide as well. And finally we realized that if you are a customer engaging a partner or you are a partner and you need to report your status to customer, it is very important that you have accurate reporting of what the agent is doing, what your team is doing, and where are those guard rails.
So with work logs, all those artifacts, you have everything documented, and you can go ahead and share those artifacts to make sure that you are comfortable with the decisions that the agent is making. You can also summarize at any point in time, say what are the decisions the agent has made, what are the things which require attention from my side? Why is this agent taking longer? Is there anything that I need to do? All of those things you will be able to do. There is a lot of flexibility built into it.
We had a lot of feedback from our Asia Pacific and Europe customers. They wanted more region expansion. So now AWS Transform is available in these eight regions covering Americas, Asia Pacific, and Europe and the target regions. Once you have, you can run AWS Transform in these eight, but you have a choice to migrate to 16 regions, and there are more coming. So that's the cross-region migration functionality which we have here.
There are a lot of things that we discussed. In terms of what challenges customers have, both technical as well as organizational, how agentic AI can help in solving those problems from organizational collaborations to automation, human in the loop, and how it can be agentic so you have flexibility, you have security.
Everything is now ready and generally available for you to use. I can't wait to see how you start using this capability and begin your migration journey. To give you the first glimpse, I'll invite Harpreet to come here and provide you a demo and go over many of those use cases, how it shows up in the product, and then we have your hands-on sessions planned in a lot of workshops as well.
Hands-On Demo: End-to-End Migration Workflow with AWS Transform
Hi, good morning, everyone. My name is Harpreet Virk. I work with global financial services customers, and I help customers in their modernization and migration journey, solving their large migration challenges. This demo is a recorded demo where I'll go over different steps that we perform as part of this migration. Now, this is recorded, but we do have a virtual immersion day, so talk to your account teams, which offers a much more hands-on experience to do real migration in our controlled lab environment from one region to another. It will show you all the capabilities.
The first step when you actually log in is the unified web experience, because large migrations are complex. You'll see here that there are different agents. We have mainframe migration experience with acceleration, and we'll talk about our migration, which is VMware migration. So I'll click on that. In VMware migration, you have two options. One is assessment, and the second is migration. Rajesh did touch on the assessment that before your migration, you can actually cover the assessment part.
There are five different things which you could do. If you already have pre-existing network in your accounts or everything is pre-done with VPC subnets already there, you can choose discovery and server migration. For this demo, we are doing end-to-end migration, so that will cover your discovery, your web planning, and then your server migration from on-premises. So I'll click on the end-to-end migration.
Now this is the chat experience. When you go talk to the agent, within this job there are different agents, so you'll see the context actually switching. If there's an assessment, it'll show you that assessment agent. If there's a discovery, every agent, when your context is switching, you should see that in the chat. Here, I'm actually giving an input, start, and then you submit by clicking on the submit button.
This is my import inventory, where I can actually provide RV tools. You can provide our discovery tool or any other tools which you may have on-premises. You can actually use that. File upload is where you're actually uploading the file, and at every step it'll show you what it is actually doing. It'll either give you a prompt or there will be a button which you can actually interact with. Here I'm actually uploading a file which is from our discovery tool. I'll do a submit, and this is where it'll actually identify all my inventory and give me a summary of everything it actually discovered.
We have a discovery tool that has the capability to look at the network traffic between your servers. On the first tab, you see the servers with all your IP addresses and everything, operating system identified. The second tab, if you see the network communication, because one of the common challenges which we see with customers is dependency mapping. Some customers are more mature and may have a CMDB where they know how these applications talk to each other. The discovery agent actually helps solve that problem. It knows how these servers are actually talking to each other, which helps in building the waves. A wave is actually a combination of servers that would comprise one application. Multiple applications can go into one wave. Dependent applications that you want to actually migrate together, so this gives you pretty good visibility of how the servers are talking to each other and the ports.
Post-discovery, we actually provide the next step, which is actually building the migration plan. This is the summary of whatever we have processed.
We discovered 48 total servers. It gives you pretty good output in terms of how many Linux servers there are, what their operating system is, what their CPU utilization and memory are, and everything else the agent could discover. Rajesh did talk about providing more context. Let's say the CMDB agent discovered some things. You may have other application dependencies and business dependencies. You can provide more context to whatever we have or the agent has discovered. You can provide context like saying this is other context, and there are certain tags I want to use in planning these waves together, planning all these applications that need to go together.
What we are doing here is we have different server names and we have tags associated with them. For example, for dev and test, the agent will read that context, club those applications together, or group servers into applications and applications into waves. So you can use any information you have to feed it or provide more context. In this one, we are doing the grouping based on network traffic, but as I said, you can have other contexts and you can augment that with any information you have. What it tells you is that I have these two applications, four servers, and they are dev, test, stage, fraud, and a total of seven applications. So that's a pretty good summary.
Now you can interact. You may say no, I want this test and dev to go together. So you have the ability to chat with the agent. You can say I want this together, I want this prioritized, maybe dev over test, or I want to do the test migration first before I start with the dev. So you have that capability to interactively chat and provide more context. This is all the grouping in terms of post-inventory. This is your migration plan grouping and how it actually came up. So you can read that information again and go back and change it, but if this is good, you can go ahead with your migration planning here. So it's human in the loop. It will ask you if this is good. Does it look good? So you can say approve, yes, it doesn't look good, let me change it, or I need to make changes to this plan. That is possible. So here I'm all good with whatever results I got, so I'm approving that.
Move Group is how this would go together. Move Group is a logical group of servers, so they would move together. Underlying it still uses MGN. How many in the audience have used MGN for their migrations? This actually reduces some of the complexities. In MGN, you have to change the launch template and all that. So this is one easy way you can chat with it. You can say I want to change this subnet, I want to add this security group. Everything is possible. You can do it through the chat experience. So it makes it pretty easy compared to having to flip over different screens in the MGN console. So I confirmed with my move group and I'm all good. The move groups are correctly loaded. It will give you a pretty summary that these are my move groups, this is the environment, these are the applications, and again, you could combine those as you wish. So slice and dice the way you like it.
Then there are operational and optional questions. Like how do you want sequencing? I talked about wanting to prioritize test over dev or wanting to prioritize maybe dev over some other environments. Many customers do have multiple stacks, stack A, stack B. I come from an environment where we had five stacks, so we had the ability that for development we have three different stacks. So you can use this chat capability to prioritize anything you want to do. So your planning is complete. You can look at the summary. You can download this and share that because this is across your organization. Maybe you met with your application owners and your infrastructure team because migration is not something one person would click a button and it will be done. It has to be planned. So everybody should be aware of how we are planning and then everybody's on the same page. That's something you can share across the teams.
Risk level is another thing you can define. You can actually define whatever risk tolerance you need. As Rajesh mentioned, if your priority is to get out of the data center or exit a VMware contract, for example, we can work with customers who have those kinds of complexities. You can actually adjust your risk parameters and make the migration much more aggressive. We talked about target regions. Now, how do you actually connect to your target account? This is where AWS Transform needs to communicate with your target account, which is where your MGN workload or these servers would be migrated. You need to have a role in place for that configuration. You can click on "Proceed to connect to my target account."
We have two capabilities. Rajesh already touched on that: single account versus multi-account. Most applications would go into a single account in a wave. It's very rare that you have different dev environments where you want to go cross-account. Most use cases, especially in large complex migrations, have any application in a single account, but we do have the ability to do multi-account here. In this demo, we are doing a single account configuration, so I'll click on "Configure my single account connector."
The connector is our security context or the creation of roles and policies for AWS Transform to actually talk to that target account because it needs to communicate with MGN to make API calls for cutover, testing, and so on. Here you will provide your account number and the region where you want to migrate these servers, then click next. You can use your default encryption for S3. S3 is actually an intermediate service that AWS Transform talks to. This is where it places all the artifacts. If it needs to talk to MGN, there will be MGN import and export. That's where you will see all the artifacts, and this S3 is managed by the service, so you don't have to do anything.
If you want to use CMK, custom managed keys, you can choose your own keys here. You have that ability. So copy the verification link, and it will generate a URL for you. Once you click on that URL, this is the screen you would see. Here you're asked to save and approve. If you look here at the service access, you can see all the policies and permissions that it creates. The service adds filters, including the workspace ID and other tags that are created by AWS Transform. Those are the filters it uses to interact with your target account. So if you have 1,000 servers in MGN, it will only be able to take action on those servers that have these tags.
You can apply these policies to your pre-existing role because sometimes your security team may not want you to create a new role. That ability is there, and you can assign these policies to your existing roles. My configuration is now completed. I'm ready for at least my target account configuration. Everything is done. You'll come back on your AWS Transform screen and submit here. I'm telling the system that all my setup for my target account is complete. The role and policies have been configured, so I can proceed to the next step.
Network migration is one of the biggest areas in terms of complexity that we see with customers on the migration journey. This is the most complex thing. AWS Transform makes it simple to read your RVtools and SX files or your other constructs. There are other capabilities coming as well. It will generate AWS artifacts for you, including your VPCs, subnets, and even security groups if you have an SX output file. I'll go to the next tier. Here I'm providing an NSX input file. You submit it through the same interface. You would say "Map security groups" because NSX has that kind of granular information about how these VMs talk to each other, so it has the ability with NSX files to generate your security groups.
This is a summary that was generated from that. It will generate your output in terms of the CloudFormation template on S3. You can download it, or you can use AWS Transform to deploy directly in your environment.
It does have other capabilities. You can use Terraform, download it, and approve it with your security team if they are security architects. They can view it. Those capabilities are there, and it will give you both options. I can click on that and look at my CloudFormation output. You can view your VPC and network configuration here.
One thing, if you want to change your CIDR ranges on-premises, let's say in this example we have 192.168.0.0/16, you want to map it to 10 or 16 or whatever your CIDR range is, you have the ability to do a kind of mass translation for you. In this example, we are sticking to the static IP same CIDR range. But here, if you wanted, you could move that to 172. You can generate Terraform infrastructure code and use that for your VPC constructs or deployment as infrastructure as code.
You can also ask it to generate your landing zone accelerator, so that can be generated as an output of this. Once you're done with your VPC, you can use CDK as an output, CloudFormation, Terraform, everything is possible. Here is your Terraform output generated in this example. It will give you the README and your documentation for this accelerator of all the output. This is the output you get from this in terms of your output as an YAML file.
In terms of approval, we did talk about how you can have approval here. On the left-hand side you can go to any action that needs approval and click on that. If you're an admin, you can approve it, but if someone else in your organization is the admin, they can approve it and would see this in their AWS Transform workspace. Here's the summary of all the information I did. I press approve.
I'm done with my approval, and it will do a deployment. Now I go to the step where we actually do the actual migration for your EC2. This is where we execute those migration waves. In EC2, you can use the utilization because the collector does have information about your CPU and memory. You can use your average or your peak, or you can provide additional information from your monitoring tool.
Here is the output for my waves. There are four waves: development, test, staging, and production. As mentioned, you can pick one wave you want to prioritize, such as dev over others. I'm going to click on Wave 0. Another security consideration is that anything AWS needs to connect to or create those resources requires some tags. You can automate that or use the URL provided here. It will generate those tags or add those tags for your network resources so it can work on those.
That is in your day-two operations, as I said. We do have emergent day for this with much more detail. This will show you the flow from your wave. You can do testing of your connectivity. You can do a test launch. Once you're done with your testing, you can do your actual production cutover, the same workflow that is already in MGN. I'll hand it over back to Sean to talk about some real customer examples. Back to you, Sean.
Customer Success Stories and Next Steps for Getting Started
Great job, Harpreet. Thank you. Okay, so you heard Rajesh walk through AWS Transform for VMware. You saw Harpreet demo the workflow of how we're helping customers ingest data, execute wave planning, do the network configuration, and then migrate VMs.
I'm going to briefly cover a couple of customer stories where we've seen large success early on in the life cycle. We only have a few minutes left, so I'm going to move pretty quickly through these. The first is CSL. They selected Transform for VMware and AWS to migrate their workloads. You can see some of the cost savings here: 30% operational cost savings. They ingested 4.6 million records of on-premises data to help inform planning and prioritization of what to move and when as part of their migration out of 29 data centers for their 5,000 VM estate.
There's a session at 11:30 this morning with CSL talking much more in depth about their story, so I'll show that in a second here. You can attend if you want to learn more. The second is Vector. Vector is a utility company in New Zealand. They used Transform to accelerate their migrations 34% faster and they reduced their TCO by 35%. You can see there's a great quote here about using Transform to continually refine and improve their migration process as they went to continue to go faster and faster.
A couple of launch partners here that we wanted to make sure we highlighted with you. These are partners that have come with us along the journey for Transform for VMware, and they've been integral in the development of the product in terms of working with us on private preview and working with us on customers as they started their migration. So thank you to these partners, a selection of partners. This will grow larger and larger as more partners come on board with Transform for VMware.
So what are the next steps here? As you wrap up and think about what you want to do in terms of your migration, we hope you'll consider AWS Transform for VMware for your migration. It is available to you at no cost, so we really want you to get your hands on it and experiment and try it. Rajesh did a really good job of covering assessment and discovery and the different phases of the process here, so I'm not going to go in depth there.
I will just ask you to think about our experience-based accelerator, or EBA. This is a cloud party that we can host with you on your premises, virtual, hybrid, however you'd like to do it, where we can bring different folks from your organization together and actually get Transform set up and running and help you get some VMs migrated and get hands-on experience.
A couple of upcoming sessions: I mentioned the CSL session. We have some other sessions over the next couple of days that may be of interest to you. MAM 305 is our Elastic VMware Service deep dive. We talked about the relocate pattern a little bit earlier. We've got some sessions about modernizing VMware workloads. We've got our ProServe team tomorrow talking about the cloud migration factory that they've built, which is leveraging Transform, and then we've got some other sessions here that touch on migrating, optimizing, and modernizing VMware.
Please come stop by and see us at the expo. We have a couple of booths in the migration modernization section that may be of interest to you, VMware workloads and Transform in particular. You can come talk to us about Transform for VMware as well as .NET mainframe AWS Transform custom that was announced on Monday. We're wrapping up now, so thank you so much for your time today. Please fill out the session evaluation. We're really eager to get your feedback. Rajesh, Harpreet, and I will be around for a few minutes if you want to come over and ask us questions. Have a great rest of your re:Invent. Thank you very much.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)