AWS re:Invent 2025 - [NEW LAUNCH] Bring Your Own Agents and Tools to AWS Transform (MAM208)

🦄 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 - [NEW LAUNCH] Bring Your Own Agents and Tools to AWS Transform (MAM208)

In this video, Tushar Saxena introduces AWS Transform, the first agentic AI service for migration and modernization, comparing it to GPS navigation for cloud migration. He announces composability features that allow partners and customers to bring their own agents and tools into AWS Transform. The session covers three main transformations: VMware migrations, mainframe modernization, and Windows modernization. Saxena demonstrates how AWS Transform uses expert agents, orchestration, and learning capabilities to automate migration workflows. He showcases AWS Professional Services' custom implementation using a delivery agent and Cloud Migration Factory, and mentions partnerships with Bale, Accenture, and Gemini. The composability feature enables users to register custom agents in the agent registry and build personalized orchestrations while leveraging AWS Transform's UI, collaboration tools, and existing agents.

; 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

From TripTik to GPS: Reimagining Migration with AI Agents

This is the lightning talk for Bring Your Own Agents and Tools to AWS Transform. Hopefully you're all here for that talk. Let me get a quick show of hands. How many of you here remember what TripTik was? Back in the day, if you wanted to go somewhere, travel to a destination, you would go to AAA and ask them to print out TripTiks, which are basically maps, and then you would lay out the maps on the hood of your car and figure out how you want to get from Vegas to Grand Canyon. You would be the one making all those decisions, and you'd get in the car and then you'd hit traffic and then you'd have to stop, pull up by the side, and look for alternative paths. So it was a bit of a painful process.

But now we use Apple or Google Maps and get step-by-step directions. It guides us if there's traffic. It reroutes us automatically, so you have an assistant in your pocket that can take you places without you having to worry about how to get there or what turns to take. Sometimes you end up in weird places, but most of the time it gets it right, and it even knows what your priorities are, how fast you drive, and things like that, and it adjusts based on your behavior as well.

Our modern migration and modernization journey is a lot like GPS. I'm Tushar Saxena, and in the last seven years at AWS I've obsessed about building services that make it easier for our customers to move to the cloud. I started with FSx, a managed file service, and helped customers move from their self-managed on-premises storage to a fully managed file service in the cloud. After that, I built no-code, low-code services that made it easier for even non-technical folks to build AI and ML models in the cloud with SageMaker. And now I lead AWS Transform Migration Service. It's the first agentic AI service to help you migrate to AWS. I'm very passionate about making it easier for you to move to the cloud.

Today I'm going to introduce you to AWS Transform and also talk about composability, which we just announced yesterday. Then I will show an example of an internal partner of ours that used composability to extend AWS Transform for their own needs. This partner is our own AWS Professional Services team, and it's really going to change how Professional Services does business going forward. And finally, I'll share some customer testimonials and some best practices for how you can customize AWS Transform to your own needs.

Before I dive in, I just want to understand the audience a little bit. How many of you here are what we would call AWS partners? Good. This is going to be useful to both partners and direct customers as well, but especially if you're a partner working with a customer, this might be especially useful for you.

So much like GPS, our tools for migration and modernization are evolving. When you did migration a couple of years ago, you had scripts. There were documents that were passed between people. There was a lot of manual effort to figure out how to migrate your workloads from on-premises to the cloud, and that's why it took months, sometimes years, to migrate any kind of significant workload to the cloud.

But we want your migration journey to be like GPS, automatically navigating to your destination. So our vision is that AI agents are essentially a team of experts for you, and they can work with your team, your migration team, almost hand in hand like assistants and guide you all the way with migration from discovery all the way to rehosting and migrating to the cloud. They can understand your business needs and your priorities and adjust the path to the cloud based on your priorities and your needs automatically.

And it's not a very complex tool where you have to pull down menus and hundreds of options to select from and you don't know which one to use. Instead, these are AI agents, so you can in natural language talk to them and express your needs or even upload a document and let it figure out what your needs are. I'll show you a little bit of that as well. And then as you progress with your migration, AWS Transform learns from your migration and adapts accordingly and changes your plan on the fly as well.

AWS Transform: The First Agentic AI Service for Business-Critical Migrations

So with this vision, we launched AWS Transform as the first agentic AI service for migration and modernization. We launched with three main transformations that involve business-critical applications. The first is migrations, and when I say migrations, I specifically mean VMware migrations, which is the largest use case for migrations. Folks want to move very quickly, move out of data centers and into the cloud. They want the advantage and the flexibility of the cloud,

but the challenge is maintaining the networking and the security of your on-premises environments and making sure that the network we set up in the cloud is similar to what you have on premises and follows all the same compliances. That's hard. And you want your workload in the cloud to be built to AWS's best practices or cloud best practices. So that's not easy to do.

We started by building an AI agent. We announced yesterday an AI agent for VMware migrations that really makes this journey very seamless for you, and I'll show you a little bit of that. Second, on mainframes, these are really the last workloads that have yet to completely move to the cloud. These systems run some of the most complex applications. They contain 50 plus years of COBOL code. Most of the folks that wrote that code have long gone. The folks in the companies don't know what the business rules are that the COBOL code base even represents.

We launched a migration agent, a mainframe modernization agent in AWS Transform, and yesterday we announced some new features including capabilities for reimagining your code base altogether, which means you're not just translating a legacy code base into a modern code base. Instead, you're extracting business rules out of it and reimagining how it should be reimplemented to implement the same business rules as well. So that's the second workload that AWS Transform deals with.

And the third one, customers want to modernize Windows applications. They want to improve the security and performance and upgrade their Windows applications. So we launched a Windows modernization agent as well. We started with .NET a few months ago and we now include a full stack Windows modernization as well.

Now another thing that is complex about migrations is that not only are the systems you're migrating complex, but there's also additional complexity due to cross-functional work that needs to happen. Typically in a large migration, there are multiple teams, multiple folks, and not only if you're trying to migrate to the cloud, not only is it your own internal teams and the IT department, oftentimes you will work with a partner and so the partner would have their folks embedded with your team as well and sometimes AWS solutions architects might be helping you as well. So it's a large team. It could be 10, 12 people, maybe even 50 people sometimes working on a migration. And so there's a lot of communication that needs to be done. So how do they collaborate?

So that's another piece where AWS Transform, we built it from the ground up with the goal to bring order to this chaos. It's the one place to go for all your workloads, and we allow multiple folks to be able to collaborate on a migration project. We have things like approvals whereby if one person comes up with a migration plan they can seek approval of others in the team. So there's a lot of order that is brought to the complexity of migration by providing easy collaboration with enterprise permissions.

And there's also a shared artifacts store. Not only can you collaborate, you can share artifacts with each other. If you built a wave plan, you can share it with others and seek approvals. And the entire team interacts with the agent through a chat interface, which makes it easy and uniform for a large team to execute the migration.

Expert Agents, Orchestration, and Learning: The Three Foundations of AWS Transform

Now, the fundamentals of AWS Transform, the underlying interface really has three components. First, on the left, you see expert agents. So when I say VMware migrations, it's a single agent that you're communicating with, but under the hood there are multiple subagents that are experts in what they do. So take VMware for example. There could be a wave planning subagent, or in mainframe there could be a COBOL business extraction subagent that's part of the overall mainframe modernization workflow. So there's a bunch of subagents that are part of AWS Transform. I'll talk more about details about what they are.

Secondly, in AWS Transform, the second foundation is orchestration. Once you have a bunch of subagents that are real experts at doing what they do, whether it's building a wave plan, migrating a network, or extracting business rules out of COBOL, you now need to build a workflow end to end. So you can build an orchestrator that can orchestrate across these subagents and create an end to end workflow with it.

And third is learning. This orchestrator, as it's proceeding, is learning from you and adapting to it.

So that learning capability is also inherent in AWS Transform. Let me give you a specific example about VMware migration. A typical VMware migration has four stages.

You start with discovery. You have your on-premises inventory, your on-premises estate of servers. You might have 10,000 servers with, let's say, 600 or 800 applications running on them with VMs. So you want to do discovery. Then you want to create a migration plan based on what you discovered on premises. Once you've created a migration plan, you now need to set up the network in the cloud to which you're going to migrate. Now that network has to replicate the networking priorities that you had on premises. So you need a network conversion and migration agent.

Finally, once you've set the network up in the cloud, you now want to rehost your servers and VMs from on premises over to the cloud. So it clearly and cleanly breaks out into four stages. For each of these stages, what we've done in AWS Transform is we've built an agent. So we have a discovery agent, we have a migration planning agent, we have a network conversion and network generation agent, as well as a rehosting agent. And then on top of that, we have an orchestrator that orchestrates across these four agents to create a journey for you for migration.

Now it's not a linear affair, right? If you're trying to migrate to the cloud, you might want to do a wave plan, then you create a network. You migrate your first wave, and at that point you discover, hey, I've got a few more servers here that were discovered originally, but I really don't want to migrate them. I'm going to retire those applications. So you go back and redo the discovery, you recreate the wave plan. Now the orchestrator is able to work with you in natural language. You're able to express your priorities and express where you are at, and it will recreate the plan for you dynamically based on what you say.

And so this is what it looks like if you're trying to use the VMware agent in AWS Transform. This is the kind of environment you get. On the left side, what you see is the job plan. The job plan consists of essentially the steps that I had talked about, for example, and you can see it tells you the status, whether the step is complete and what step you're at. But this is where all the action happens. This is the chat. You ask it to do various things, and you can ask it all kinds of questions.

Just last week I was working with a customer where they were trying to do a migration plan, and they had all kinds of applications on their premises, and we didn't even program for this. They said, you know what, I think I want to migrate all my security-related applications first before I migrate anything else. So they just randomly in chat asked, hey, can you group my security applications? They had 600 applications. Can you group my security applications together and create a single migration wave out of that? And because this AI agent is intelligent, it was able to look at the application names, figure out from its context what the applications might do, and propose these are the applications that look like security applications, group them together, and generated a wave plan based on that.

So this is where in natural language you can collaborate. On the left-hand side is where you see the collaboration piece come in. Whenever you try to take a mutating action, there is a tab here to get approvals. Before you can, for example, migrate an actual server, it will seek approval, and you can set it up so that not everyone in your team can approve these kinds of migrations. So there might be certain people with approval permissions who have to come in and approve as well. So it makes the collaboration very easy, but everyone in the team is working on the same exact interface.

Introducing Composability: Build Custom Workflows with Your Own Agents and Tools

Now, how did we develop that? And this is where I'm going to transition into the composability piece of it. Under the hood, this is what AWS Transform looks like. If you go a little deeper, you'll see that it comprises of a UI layer. That UI that you just saw comes from the UI layer. It contains domain-specific tasks. The four sub-agents for VMware I talked about are domain-specific agents that do domain-specific tasks, and then there's an orchestrator. The entire VMware end-to-end migration flow was essentially an orchestrator. We have a similar one for mainframe and a similar one for Windows modernization as well.

So we have today three predefined agents. I already talked about them: VMware migration, mainframe modernization, and Windows modernization. But you might want to create your own different way of doing a migration. And that's where composability comes in. So I'm excited to introduce composable capabilities to you. We announced this yesterday in my boss Asa Kalawade's keynote.

AWS Transform allows all of your innovation to be brought into the platform, enabling partners and customers to build custom variants of AWS Transform. When you saw that workflow, you might do things a little differently. For example, if you want to skip network generation because you already have a landing zone in AWS, you don't need to generate a network since you've already set it up. You can just build a custom workflow that does discovery planning and then go straight to rehosting.

Or if you have your own way, let's say you're a partner and you've learned over the last few decades working with customers how to build really effective wave planning for the kind of customers that you target, you could bring in your own wave planner as well. That's what composability gives you. It gives you access to our best possible agent, but it also allows you to bring in your own agents.

What happens is when you bring in your own agents and create your own custom orchestration that includes our agents and your agents, you get the benefit of the UX and the chat interface and the collaboration and the entire platform in one shot. You don't have to worry about all the plumbing. We have the plumbing there, and as we evolve our agents, you can choose to use our agent and mix and match with your tools and agents that you trust as well.

We've been working with a few partners on this until today, and now as of today it's open to other partners as well. I'll talk about how you can get involved in this. One of the partners we've been working with is ProServe, so let me just quickly show you how that changes things.

What we did in order to bring composability to you is we added something called an agent registry. If you bring in your own custom agent or you bring in your own custom tool through, let's say, an MCP server, you can register in the agent registry. Once you register it here, it's available to be orchestrated from your orchestrator.

Now you can build your orchestrator. We have a developer's guide that we can share with you, and you can use that to build your own custom orchestration. That orchestration will have access to any agent that you have registered in the agent registry, as well as any agents that we have publicly launched already, like our wave planning agent, network generation agent, the mainframe modernization agent, and so on. You can mix and match.

Imagine if you wanted to, let's say for your customer base, do a VMware migration and then following that do SQL modernization, and that's your end-to-end workflow. Well, we don't offer that out of the box. We offer VMware migration and then we have a separate SQL modernization, or you might have your own way of doing SQL modernization. You can bring in your own SQL modernization agent into AWS Transform and orchestrate it with our VMware migration workflow as well to get a full end-to-end workflow.

Now you might say, AWS Transform is a public service, so if I build a custom workflow in AWS Transform, will that be available to everyone? No, it won't. It would only be available to the folks that you give permission to. For example, if you're a partner and you have your own professional services team, they're the only ones that will be able to use that. If you want, you can open it up to other customers as well, but the default is it's only available to folks that you allow list.

ProServe and Partner Success Stories: Custom Workflows in Action

Here's an example of how our ProServe built a custom agent. You remember I showed you this picture a couple of slides back. This is what a typical VMware orchestration in AWS Transform today looks like. What ProServe did is, when our professional services team is doing migrations, they start very early. They are building SOWs, they are scoping out the project, so they've built something called a delivery agent.

They brought the delivery agent into AWS Transform. Their consultants work with the delivery agent to create a statement of work, scope the project, and then once all of those assets are created, pass it along to our four subagents. Even when they're going through a VMware migration after doing their sales and delivery, they do rehosting a little differently in professional services.

They're working on very complex projects where sometimes after you do a rehosting, you have to do some other things on the server. You might need to install an application that the customer is asking for, so they have a tool that they've developed over the years called Cloud Migration Factory. They brought that tool in that executes these pipelines. They brought that tool in with an MCP server and integrated with our rehost agent to create a different rehost agent for themselves.

Finally, most of their projects or some of their projects end up with a modernization step as well to containerize the applications once they've been migrated. So they had a containerization agent that they brought in as well. Now they have an end-to-end custom workflow built in AWS Transform that does not just VMware, but it can do the SOW generation scoping as well as a different way of rehosting and then containerization at the end.

Here are some more examples of other partners that we're working with. Bale, for example, they've been building a BI migration agent in AWS Transform. Accenture, we've been working with them. They're taking an interesting approach to building a custom workflow in AWS Transform. They're bringing in their knowledge base. They've been working with customers for decades. They have a lot of knowledge about how to extract business rules. They're bringing in that knowledge base and enriching our business rules extraction agent to be even more powerful.

And then lastly, Gemini. I'm over time, so I'm going to stop here, but if you have any questions, find me in the back, and I'm happy to stick around and answer questions. Now, if you want to get started with a custom workflow in AWS Transform, if you're a partner, reach out to your partner development manager. If you're a customer, reach out to your account team or SA, and they should be able to connect you with us, and we can work together on figuring out how to build your custom workflow and bring it into AWS Transform. Thank you very much.

---

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