Migration & Modernization

Migrate faster with AWS Transform and your AI coding agent

Introduction

If you already work with an AI coding agent, you know how much they can do. Tools like Kiro, Claude Code, and Cursor read repositories, reason over code, and drive multi-step tasks from an IDE or terminal. They’re excellent general-purpose AI coding agents, built to help with everyday software development tasks. But planning and executing a migration demands specialized knowledge: discovery, application grouping, wave planning, network conversion, cost modeling. That’s a different discipline entirely.

This is where AWS Transform comes in. Built specifically for migration and modernization, AWS Transform draws on two decades of AWS migration experience. Its specialized agents ingest discovery data, generate data-driven business cases, group applications, build wave plans, design and deploy landing zones, convert networks, and rehost servers and storage. It handles the migration-specific work that a coding agent was never designed to do. AWS Transform for migrations is available at no additional cost, making it a compelling option for performing the heavy lifting for a migration.

You can use AWS Transform through its web interface, but there’s another option that brings it directly into your existing workflow: the Model Context Protocol (MCP). When you connect AWS Transform to your coding agent over MCP, you get the best of both: the migration expertise of AWS Transform, called directly from the agent you already work in. This post focuses on that MCP integration: how it works, how to set it up in Kiro, Claude Code, Cursor, or other AI coding agents, and how to prompt them together for an effective migration.

Why connect a coding agent to AWS Transform

When you connect AWS Transform to your coding agent over MCP, the coding agent can drive the whole migration lifecycle. Using a chat approach, it can create Transform workspaces and jobs, respond to human-in-the-loop (HITL) tasks, monitor job status and handle Transform created artifacts. It still does everything a coding agent does best and now is able to perform complex migration tasks. This combination unlocks workflows neither tool can do alone:

  • Compose custom workflows. Have your coding agent kick off multiple migration jobs. It waits for each to progress, reads the outputs, and assembles them into a single set of outputs all in one session.
  • Enhance Discovery. The coding agent can read your local repositories, business-rule files, and notes. It then feeds that context into AWS Transform prompts, so app groupings and r-strategy dispositions reflect your reality.
  • Stay in one place. You review plans, approve HITL steps, and refine the wave plan in the same chat where you write code. You don’t switch tools.
  • Automate and verify. Build verification loops to check outputs against your success criteria, re-running a step when something looks off, and flagging anything that needs your review. You define what “done” looks like once, and the agent watches for it so you don’t have to babysit long-running jobs.
  • Cost efficiency. AI coding agents charge per token, so every prompt and response has a cost. AWS Transform doesn’t add to that bill: AWS Transform for migrations is free, and AWS Transform custom transformations charge only for active agent minutes while the agent is planning, analyzing, or modifying your code. Time spent waiting for local operations like compilation and tests doesn’t count. By offloading the migration-heavy work to AWS Transform, you keep your coding agent’s token usage focused where it adds the most value.

Prerequisites

To use AWS Transform MCP with an AI coding agent, you will need the following:

Choose your setup path

There are four ways to connect. Start with the packaged option for your AI coding agent. If a dedicated installation isn’t available for your agent, check your agent’s documentation for how to add MCP servers, then use option four. All of the options install and use the same AWS Transform MCP server, which runs locally and connects to your own AWS account. You control the identity and permissions that the server uses, and you have full control over what it can access.

Kiro

Install the AWS Transform Kiro Power. It gives you full access to AWS Transform agents from the Kiro IDE and installs the MCP server for you. In the Powers panel, find AWS Transform and install it. Then open Kiro Chat, select the Power, and choose Try power.

Agent Plugin for Claude Code, Codex and Cursor

Install the AWS Transform agent plugin from awslabs/agent-plugins. It ships .claude-plugin, .codex-plugin, and .mcp.json configurations.

VS Code and Open VSX IDE Plugin

Install using one of the following methods:

Any MCP-compatible client

Install the MCP server from PyPI as awslabs.aws-transform-mcp-server. Use this path only if you want the server without a Kiro Power or agent plugin.

After you configure it, restart your client. Then confirm the connection by asking your assistant: “Check my AWS Transform connection status”. The assistant calls the server’s status tool. It returns the server version and the authentication state.

Authenticate

Ask your assistant: “Configure AWS Transform with SSO.” It prompts for your AWS region and IAM Identity Center start URL (for example, https://d-1234567890.awsapps.com/start). It opens a browser for login and saves your credentials locally, so tokens load again on restart.

Some control-plane operations, such as associating an IAM role with a connector, use standard AWS credentials. The server picks these up automatically from your environment (~/.aws/config). If you use more than one profile, set AWS_PROFILE in your client’s configuration to select the right one.

Start your first migration workflow

With the MCP integration configured and authentication in place, you can begin working with AWS Transform directly from your coding agent. The two core concepts are workspaces and jobs. A workspace is a logical container for one or more migration jobs, giving you a single place to manage an entire migration. Within a workspace, you create jobs for specific tasks such as assessments, wave planning, or end-to-end migrations.

List existing workspaces. If your team has already started working in AWS Transform, ask your coding agent:

"List my AWS Transform workspaces."

The agent calls the MCP server and returns your available workspaces, along with their status and any active jobs.

Create a new workspace. To start fresh:

"Create a new AWS Transform workspace called data-center-exit-2026."

The agent creates the workspace and returns a confirmation with the workspace ID. From here, you can launch migration jobs inside it.

List available job types. Before launching a job, you can see what’s available:

"What job types can I run in AWS Transform?"

The agent returns the available job types, such as end-to-end migration, assessment, wave planning, or individual steps like network conversion and server rehost. This helps you pick the right job for where you are in the migration.

Launch a migration job. With a workspace ready, you can start a migration job. AWS Transform offers several job types, from end-to-end migrations to individual phases like assessment or wave planning. For example:

"In the data-center-exit-2026 workspace, start a migration assessment."

The agent launches the job, and AWS Transform begins working through the migration steps. You can check progress, respond to human-in-the-loop tasks, and download artifacts, all through your coding agent.

Prompting best practices that carry over

These habits apply to any AI agent. They are important to also consider when your coding agent is orchestrating AWS Transform. By following this guidance, you can write prompts that help ensure the best outcomes from both your coding agent and AWS Transform.

  • Lead with the artifact. Name what you want first: a business case, a wave plan, CDK for your network, migration status report. That points the response toward the most relevant, structured output instead of an open-ended chat.
  • Be specific, and say what you want, not what to avoid. “List my servers by operating system and flag anything on an unsupported OS” beats “analyze my servers.” And “put low-risk applications in the first wave” works better than “don’t make the first wave risky.” Describe the outcome you want in plain terms.
  • Point to your inputs. Tell the agent the file, the format, and any extra context: notes, an existing application list, or business-rule files in the repo. The coding agent can read that context locally and pass it into AWS Transform.
  • Choose the output shape up front. Decide early whether you want a report, a dashboard, a data export, or a set of sections. Then say how it should be organized.
  • State your limits as guardrails. Timelines, servers-per-wave caps, rollback rules, and licensing assumptions are all fair game. If you don’t state them, the agent fills the gaps with its own assumptions.
  • Lay out the steps for multi-stage work. When a request spans several stages, spell out the route so the agent can’t skip a step: “First scope and analyze, then group applications, then generate move groups, then build waves and show the evidence behind each grouping.”
  • Ask for evidence, and verify. Request the data behind each conclusion: server counts, dependency lists, or the rule that drove a decision. This helps you catch drift early. AWS Transform can trace planning decisions back to your own uploaded data.
  • Iterate. Start simple, review, and refine. Every change updates the plan or business case in place, so tightening your inputs is cheap.

Prompt examples to get you started

These prompts show the habits above applied end to end from your coding agent. The agent finds the right AWS Transform agent, starts and polls jobs, and returns the results, so you can express intent at a high level and stay in one place.

Kick off an assessment, with structured output:

"Using AWS Transform, start a migration assessment. For the inventory, use the RVTools export files located in ./discovery/ folder. Target Region us-east-1, Savings Plans pricing, SQL Server licensing as License Included. When the business case is ready, return three sections: compute recommendations, licensing scenarios, and on-prem vs AWS cost comparison."

Refine the assessment through chat:

"Ask AWS Transform to add my hidden on-premises costs, colocation rent and networking spend, then switch SQL Server licensing to Bring Your Own License and show me what changed in the business case."

Group applications with your own rules and repo context:

"Read business_rules.txt and naming-conventions.md from this repo. Instruct AWS Transform to group servers into applications using our environment codes (PRD, DEV, UAT) and those business rules, then show me the application catalog with the evidence for each grouping."

Build waves with clear limits and sequencing:

"Have AWS Transform build a wave plan for a phased data-center exit. Put low-risk, low-complexity applications in the early waves and hold business-critical, high-complexity ones for later. Cap each wave at a manageable number of servers, and keep each application's production and non-production environments together. Then recommend 7Rs strategies before I assign them."

Keep a human in the loop:

"Show me the pending AWS Transform approval task and its details. Don't submit a response, wait for my decision."

By default, every HITL step pauses and waits for human approval. However, a user could configure their coding agent to auto-approve these steps. The prompt above overrides auto-approve behavior, ensuring the agent always surfaces the task and its underlying artifact for your review before you approve, reject, or escalate.

Run the full sequence, with evidence required:

"Use my migration job. Run this in order and pause for my review between stages: 1) scope and analyze the inventory and exclude anything on an unsupported OS; 2) group applications; 3) generate move groups from technical and business dependencies; 4) build and prioritize waves. Provide the evidence behind each grouping decision."

Automate a poll-and-verify loop:

"Start the wave-planning job, then poll it to completion. Check the status periodically and wait while it's still running. When it finishes, verify the result against these criteria: every in-scope server is assigned to exactly one wave, no wave exceeds 50 servers, and each application's production and non-production environments stay together. If any check fails, tell AWS Transform what's wrong, re-run that step, and re-check. Stop and summarize once all checks pass or flag anything you can't resolve for my review."

This is where the two agents combine best. AWS Transform does the specialized planning; the coding agent handles the loop, starting the job, polling until it’s done, testing the output against your success criteria, and iterating until the plan is right. You set the bar once, and the agent holds the work to it.

When the jobs finish, let the coding agent pull the outputs together:

"Download the assessment and wave-plan artifacts from AWS Transform and combine them into one migration report, broken out by application, with a cost comparison and target-state architecture for each."

Conclusion

Coding agents and AWS Transform each solve different parts of the migration problem. Together, they cover the full picture. Your coding agent brings the context, the custom logic, and the automation. AWS Transform brings 20 years of migration knowledge, from application grouping and wave sequencing to landing-zone design and code modernization. It handles the specialized planning so your coding agent doesn’t have to. MCP is what connects them, and this post showed you how.

To learn more, see Developer tools for AWS Transform in the AWS Transform User Guide and the AWS Transform MCP server on GitHub.

Pick your install path, and ask your coding agent what AWS Transform can do for your migration. That single connection unlocks migration expertise at the speed of a prompt.