AWS re:Invent opens on Monday, and migration agents will be everywhere. AWS already says its tooling can produce executable migration plans for tens of thousands of servers in hours. The plan is about to become the cheapest part of a migration. Whether it survives contact with your estate depends on what the agents can’t see, and that’s still your job.
AWS re:Invent runs from 30 November to 4 December in Las Vegas, with AWS chief executive Matt Garman’s keynote on Tuesday. AWS’s own guide to the Microsoft-workloads track says “this year’s content centers on agentic AI for .NET and SQL Server modernization with AWS Transform and Kiro, moving off Windows and SQL Server licensing costs, VMware exit strategies, and operating Microsoft workloads resiliently once they are in the cloud.” The session list includes “Build a data-driven migration plan with AWS Transform” and “Large-scale VMware exit: engineering a 10,000+ server migration wave engine”.
None of that needs to wait for a keynote. AWS Transform has been generally available since May 2025. AWS says it “generates executable migration plans for tens of thousands of servers in hours”, “can rehost 1,000 servers in less than 24 hours”, and at launch “generated migration wave plans for 500 VMs in just 15 minutes”. Microsoft’s Azure Copilot migration agent and Google Cloud Modernize offer agentic discovery and planning of their own.
Agents can now write the migration plan in hours. They still can’t tell you whether your estate will let it happen.
Why the Pressure to Move Is Building
Licensing is pushing hardest. Broadcom ended perpetual VMware licence sales after its acquisition, and Gartner has forecast, as reported by The Register, that more than a third of workloads running on VMware will move to another platform by 2028, with a full migration taking “three or more years”. In the UK, the Competition and Markets Authority’s cloud market investigation found in July 2025 that “customers with existing licences cannot bring these to AWS and Google in most instances”, naming Windows Server and SQL Server.
So a lot of organisations will leave re:Invent with a reason to move, a tool that promises speed, and a board asking for a date. That’s when readiness matters most, because a fast plan built on incomplete inputs fails fast too.
What the Agents Can’t See
Agentic migration tools are good at what can be observed and parsed. They read inventories, utilisation data and code, and AWS Transform maps dependencies from “server-to-server connections” and “proposes logical application groups for migration waves”. That’s real progress on some of the most tedious work in any migration. But a lot of what decides whether a wave succeeds isn’t in the data the agent can collect.
Jobs that didn’t run while it was watching. Dependency mapping sees the connections that happen during the discovery window. The month-end close, the quarterly regulatory extract and the annual pricing run may not happen in that window at all.
Who owns each application, and when it can move. Change freezes, trading peaks and the one person who understands the billing system aren’t in a server inventory.
Identity. Federation, service accounts and privileged access tend to be the dependency that blocks everything else, and the one nobody fully owns going in.
Network and security rules. AWS said it plainly in its one-year review of Transform: “We learned that moving networks and security settings often derails projects.” AWS has added network capabilities since, but firewall rules, DNS and hybrid connectivity still need someone to decide what the target should look like.
Where data is allowed to go. Residency, retention and encryption requirements live in contracts and regulation, not in utilisation metrics. Legal will find these constraints eventually. Finding them first is cheaper.
Licences and contracts. An agent can recommend leaving Windows Server or SQL Server licensing behind. It can’t read your enterprise agreement, your support renewal dates or your exit terms.
What “done” means. Performance baselines, acceptance criteria, cutover procedures and a rollback you’ve actually tested decide whether a wave lands or comes back.
An agent plans from what it can observe. A migration fails on what nobody wrote down.
Better Inputs Make Better Plans
None of this is an argument against the tools. It’s an argument for preparing for them. AWS says Transform assessments can start “with whatever data you have including RVTools exports, CMDB data”. That’s useful, and it’s also the risk: whatever data you have is whatever the plan will assume.
The readiness work that makes a manual migration safer makes an agentic one better. Reconcile the configuration database with what’s actually running. Put an owner and a migration window against every application. Record the constraints, from residency rules to licence terms, somewhere the planning tool or your engineers can use them. Run discovery across a full business cycle, or find the periodic jobs another way. Agree the acceptance and rollback criteria for each wave before the plan exists, so the plan has to meet them.
Our free Cloud Migration Readiness Checklist covers that groundwork across nine domains: discovery and portfolio assessment, landing zone and account structure, identity and security, networking and connectivity, data migration and compliance, modernisation opportunities, operations and observability, testing and validation, and post-migration optimisation. It includes a wave planning worksheet and a framework for the lift-and-shift, re-platform or re-architect decision.
Five Questions to Take to re:Invent
If you’re at re:Invent next week, or talking to any vendor’s migration agent this winter, these questions will tell you more than a demo.
How does it find dependencies that only appear at month-end or year-end? If the answer is a longer discovery window, ask how long, and what it does with the jobs it never saw.
Can it take our constraints as inputs? Residency rules, change freezes and licence positions should shape the plan, not be checked against it afterwards.
Which steps need a person’s approval? Rehosting 1,000 servers in a day is impressive. Know which of those changes a person signs off, and who.
What does rollback look like for each wave? A plan without a tested way back is a one-way door.
What happens after cutover? Cost, security and compliance drift start the day the workloads land. Ask who governs them, and how.
The Plan Is the Start, Not the Finish
Most migrations that disappoint don’t fail at cutover. They fail in the months after, when costs creep, controls drift and the promised modernisation never starts. We’ve written about the common cloud migration challenges, the post-migration hangover and why AI projects stall after cloud migration. Faster planning makes that phase more important, not less, because more workloads arrive sooner.
That’s the problem we built Agentic DevOps for. Built on Amazon Bedrock AgentCore, it puts specialist AI agents to work across AWS, Azure, GCP and on-premises estates, grounded in live data and governed by policy-as-code and human approval. Agents can plan the move. Governance decides whether it was worth making.
Q&A: Agentic Migration Tools and Readiness
What is AWS Transform?
AWS Transform is AWS’s agentic AI service for migration and modernisation, generally available since May 2025. It covers VMware migration, .NET, mainframe and full-stack Windows modernisation, and AWS says it can generate executable migration plans for tens of thousands of servers in hours.
When is AWS re:Invent 2026?
AWS re:Invent 2026 runs from 30 November to 4 December 2026 in Las Vegas. AWS’s Microsoft-workloads content centres on agentic .NET and SQL Server modernisation, moving off Windows and SQL Server licensing costs, VMware exit strategies and resilient operations.
Can AI agents plan a cloud migration?
Yes, at the level of what they can observe: inventories, utilisation, network connections and code. They can’t see jobs that didn’t run during discovery, application ownership and change windows, residency and contract constraints, or the acceptance and rollback criteria that decide whether a wave succeeds.
What should we prepare before using an agentic migration tool?
A reconciled inventory, an owner and migration window for every application, recorded constraints such as data residency and licence terms, discovery across a full business cycle, and agreed acceptance and rollback criteria for each wave.
What’s in the Cloud Migration Readiness Checklist?
Nine technical domains, from discovery and landing zones to identity, networking, data compliance, testing and post-migration optimisation, with team-by-team checklists, dependency mapping templates, a wave planning worksheet and a lift-and-shift, re-platform or re-architect decision framework.
Working Through This With Vertex Agility
As an AI-native transformation consultancy, we help organisations move faster with agentic tools without betting the estate on them. Our AWS Cloud Migration Readiness & Planning engagement builds the inputs a migration plan depends on, and our Cloud Migration & Re-platforming service delivers the waves with senior engineers accountable for every cutover. After the move, an Agentic DevOps pilot connects the platform to a defined part of your estate, so you can measure its agents against your own baseline before you commit further.
If you’d like to know whether your estate is ready for an agent’s plan, download our free Cloud Migration Readiness Checklist. It covers the dependencies most organisations only discover once the project is already behind.