Migration & Modernization

When to use what: A guide to AWS Transform interfaces

You just got assigned 40 applications to migrate. Three teams, two time zones, a mix of .NET services and legacy monoliths, and leadership wants a status update every Friday. Where do you start?

With AWS Transform, the answer depends on what you’re doing right now, not which interface is “correct.” There isn’t one. There are several, they all share state, and a real transformation project will touch more than one of them. That’s by design.

One transformation, many seats

Here’s what a real engagement looks like when a team uses AWS Transform across its interfaces:

A platform engineer opens the Console, creates a workspace, connects the source repositories, and assigns roles to the team. She gives the tech lead Approver access and adds two developers as Contributors.

One of those developers picks it up in Kiro the next morning. He’s modernizing a .NET application to Linux-ready cross-platform .NET, working conversationally with the Transform agent, reviewing suggestions inline, steering the approach when the first attempt doesn’t fit. He stays in his IDE for the full cycle: analysis, transformation, validation.

By Thursday, he’s nailed the pattern. He doesn’t even leave his IDE. He opens a terminal pane in Kiro, runs atx custom transform with non-interactive flags, and kicks off the same transformation across the 12 remaining microservices in a batch. Split-screen: code on the left, CLI running on the right. No context switch, no separate tool. He reviews the diffs Friday morning.

Meanwhile, the tech lead logs into the Console to review progress. She sees a Human-in-the-Loop task waiting for approval, reviews the proposed changes, and approves it. She asks the agent for the status of the jobs, notes that 28 of 40 apps are in progress, and pulls the status for the Friday update.

In parallel, an infrastructure engineer is tackling a VMware migration. She starts a migration plan in Kiro, uploading inventory data for the network, VMs, and physical servers. She designs VPCs, subnets, and connectivity for the environment and then hands off the job to a peer for the migration wave planning. He uses the Console to open the job and maps VMs and physical servers to Amazon EC2 instances and containers, modernizing the infrastructure in the process while building the migration wave plan.

Nobody argued about which interface to use. Each person used the one that fit their job, their preference, and their moment. The workspace, the job history, the context, it’s all the same underneath.

That’s the point. These aren’t competing options. They’re different seats at the same table.

And it extends beyond code modernization. An ops engineer composes Transform with other tools via MCP, or a Solutions Architect builds a custom agent with the Agent Builder toolkit and deploys it for the whole team.

Your front door

So where do you start? Two lenses:

What are you trying to do?

  • Explore: getting your bearings, setting up, managing access, tracking progress → Console
  • Execute: hands-on transformation work, interactive agent collaboration → Your IDE (Kiro, Claude Code, Codex, Cursor)
  • Script: deterministic automation, bulk execution, CI/CD integration → CLI
  • Compose: building Transform into larger AI workflows, multi-tool orchestration → MCP

What tool are you already in?

If you live in an AI assistant like Amazon Quick or Claude, you can drive transformations from there via MCP or plugins. If you prefer a browser, the Console covers the full lifecycle. If you live in the terminal, the CLI handles Custom transformations end-to-end, interactively or scripted. The verbs matter more than the job title. A platform engineer might Script on day one if she’s automating workspace provisioning. A business stakeholder might Explore in Console but also ask questions through an AI assistant. A developer might Execute in Claude Code instead of Kiro.

What each interface does

Console, Kiro, and MCP can each drive transformations end-to-end, any workload type. The CLI is purpose-built for Custom transformations. The difference isn’t capability, it’s form factor:

Console: A browser-based experience with visual workspace management, portfolio views, HITL collaboration pane, and role assignment.

Kiro: Your IDE, with the Transform agent embedded alongside your code, terminal, and file tree.

CLI: Custom transformations from your terminal, interactive or scripted. Batch execution, CI/CD pipelines, and the -x -t flags for fully autonomous runs.

MCP: The protocol layer that lets AI tools compose Transform into larger workflows. Also the plumbing underneath IDE integrations.

And for teams building their own transformation agents: the Agent Builder toolkit works through both Kiro and MCP. Build in your IDE, compose via the protocol, deploy through any surface.

Shared state is the real feature

Every interface reads and writes the same workspace. Create a job in Kiro, check its progress in Console, ask a question through MCP. The context carries over. The work log persists. Artifacts are accessible from any surface.

This means handoffs are free. You don’t export, re-import, or re-explain. The developer who finished in Kiro and the tech lead who approves in Console are looking at the same thing. The CLI batch job and the MCP automation write to the same work log the manager reads on Monday morning.

Start where you are

Not sure where to begin?

Exploring? Start in Console.

Executing? Open your IDE.

Scripting? Drop to CLI.

Composing? Wire up MCP.

But you’ll probably end up using more than one. That’s the point.

Ready to try it? Open the AWS Transform console, create a workspace, and start your first job. Then pick it up from whichever interface you use most.

Learn more