AWS Professional Services has detailed a multi-agent system designed to automate large enterprise cloud migrations, using Amazon Bedrock AgentCore to coordinate discovery, infrastructure code generation, governance, and post-migration operations.

The system is aimed at migration programs involving hundreds of applications, where manual intake and infrastructure development can consume more time than the actual move. AWS says its internal framework reduced infrastructure-as-code development from three or four weeks per application to minutes across a portfolio of more than 300 applications. That result comes from internal project tracking data and has not been independently verified.

The disclosure matters because it presents AgentCore not simply as a runtime for individual assistants, but as the control layer for a workflow that spans assessment, deployment, and operations. For enterprise technology teams, the more significant question is whether agentic automation can produce repeatable, governed migration work without removing human approval from high-impact infrastructure decisions.

A migration workflow divided among specialized agents

AWS describes a framework built by AWS Professional Services with the Strands Agents SDK. Rather than assigning one general-purpose model to an entire migration, the architecture divides work among agents with narrower responsibilities.

An Intake Agent automates application discovery, dependency mapping, and the definition of a target architecture. An IaC Agent then generates infrastructure-as-code according to an organization’s security practices and standards. A Migration Intelligence and Governance Agent produces portfolio reporting, well-architected assessments, and governance information across tools including Jira, Confluence, and Webex.

After deployment, an SRE Agent monitors migrated workloads, identifies potential degradation, and supports automated remediation. AWS also lists adjacent services for specific migration tasks, including AWS Database Migration Service for assisted schema conversion and database cutover, and AWS Transform for modernization of legacy applications.

This division reflects the different risk profiles in a migration program. Discovery requires extracting facts from documents and existing systems. Code generation requires adherence to infrastructure standards. Governance requires portfolio-level visibility, while operations requires access to live systems and carefully controlled remediation. Treating those as separate agent roles can make permissions and evaluation more manageable than giving a single agent broad authority.

How Amazon Bedrock AgentCore fits into the system

According to the AWS Machine Learning Blog, each agent is defined by a foundation model, a system prompt, and a set of tools. Amazon Bedrock AgentCore Runtime hosts the agents in a serverless environment with session isolation and support for multi-agent orchestration.

The agents access external capabilities through Model Context Protocol tools. AgentCore Gateway can convert APIs, AWS Lambda functions, and existing services into MCP-compatible tools, allowing the framework to connect migration agents to enterprise systems without rebuilding every integration around a new interface.

Identity is handled through AgentCore Identity, which AWS says authenticates calls using scoped AWS Identity and Access Management roles and an organization’s identity provider. This is a central detail for infrastructure automation: the practical safety boundary is not only the model’s instructions, but also what each agent is technically allowed to read, change, or execute.

AWS says the framework applies security controls throughout the migration lifecycle and keeps humans responsible for decisions. The source does not specify the precise approval gates, rollback mechanisms, or evaluation thresholds used in the internal deployment, so teams should not assume that the described pattern automatically provides production-grade controls for every environment.

Evidence behind the performance claim

The strongest efficiency claim in the announcement is vendor-reported. AWS attributes the reduction from three or four weeks of IaC development per application to minutes across a portfolio exceeding 300 applications to its internal project tracking data. The blog does not provide a full before-and-after methodology, details on the complexity of each application, the amount of human review, or the percentage of generated code accepted without substantial changes.

That distinction is important. “Minutes” may describe initial generation rather than the complete path to approved, tested, secure, and deployed infrastructure. In enterprise migration work, validation, exception handling, networking decisions, data dependencies, compliance review, and change management can remain significant even when code drafting is automated.

The available evidence does establish what AWS is presenting: a working internal architecture that combines purpose-built AI agents, enterprise tools, and AWS migration services. It does not yet establish a generally repeatable time saving across industries or application portfolios. The second source in this cluster is an AWS-controlled blog, while the supplied wire item contains no additional article text or independent reporting.

What it means for cloud migration teams

For builders, the framework offers a reference pattern for connecting AI agents to existing migration data and operational systems. The most reusable idea is the separation of agents by lifecycle phase and permission scope. A discovery agent might have access to inventories and architecture documents, while an infrastructure agent could generate files but lack direct production deployment rights. An operations agent might inspect telemetry and propose remediation before a human or policy engine approves changes.

That structure can also make testing more concrete. Teams can evaluate discovery accuracy through dependency-mapping results, assess generated IaC against policy and security checks, and measure operational agents on alert precision, remediation success, and rollback behavior. These are more useful measures than the speed of a model’s response alone.

For enterprise buyers, the key trade-off is between faster standard work and the cost of governing agent access. AgentCore’s runtime, gateway, and identity capabilities address parts of deployment and authorization, but organizations still need model-selection policies, audit records, environment isolation, secrets management, human approvals, and a process for handling applications that do not fit standard patterns.

The approach may be especially relevant to data-center exit programs with fixed deadlines, where repetitive discovery and code preparation create a queue of work. It is less clear how well the system performs on highly customized systems, undocumented dependencies, or migrations requiring significant application redesign. AWS’s inclusion of AWS DMS and AWS Transform suggests the orchestration layer is intended to combine general agents with specialized services rather than replace every migration tool.

What to watch next

The next useful signals will be independent case studies showing total migration time, not only IaC generation time. Buyers should look for figures covering review effort, deployment success, rollback rates, security findings, and the share of applications handled without bespoke engineering.

Further detail on the framework’s human approval points would also clarify its operational maturity. Examples of rejected or corrected agent output, audit trails from AgentCore Identity, and policies governing automated remediation would help teams judge risk.

Finally, the availability of reusable reference implementations, supported models by AWS Region, and integrations beyond the tools named in the blog will indicate whether this remains an AWS Professional Services pattern or becomes a broadly adoptable platform architecture. Adoption by migration partners and evidence from customers outside AWS would provide a stronger market signal than the current internal result.

Creati.ai perspective

AWS is positioning AgentCore as infrastructure for coordinated enterprise AI agents, and cloud migration is a credible test case because the work is repetitive but still dependent on specialized judgment. The architecture’s value is likely to come less from autonomous decision-making than from turning scattered migration tasks into controlled, inspectable workflows.

The reported acceleration is noteworthy, but it should be read as an internal benchmark rather than a market-wide outcome. For AI builders and enterprise teams, the durable lesson is to pair narrow agent responsibilities with strict identity boundaries, measurable review gates, and operational evidence before allowing generated infrastructure or automated remediation to affect production systems.