Zero-Touch Migration: The Hype vs. What Actually Ships
AI agents now containerize legacy apps with Kiro CLI and EKS Auto Mode — here's what's real, what's overstated, and where humans still decide.
Several posts making the rounds lately claim manual Dockerization is effectively dead, that AI agents now discover, containerize, and deploy legacy applications from a few natural-language prompts. The reality is more interesting than that. Most of the building blocks are real and shipping today, but they're connected in a far more deliberate way than the headlines suggest, and a couple of the specific claims needed tightening before I'd put my name next to them. Here's what the architecture actually looks like in mid-2026.
Picture a FastAPI service that's been running on a couple of EC2 instances for a few years, Async SQLAlchemy talking to RDS, a Redis cache sitting in front of it, nothing containerized because nobody had the week to spare. Kiro CLI picks it up as part of a wave plan, AWS Transform scans the repo, sees the
requirements.txt or pyproject.toml and the Uvicorn entry point, and generates a Dockerfile, a Helm chart, and the Terraform for the surrounding infrastructure, VPC networking, the RDS connection, and a Redis endpoint. ECR scans the resulting image for CVEs before it's allowed to exist, and the workload lands on EKS Auto Mode once someone signs off on the deployment. Nothing in that sequence is hypothetical; each step maps to a service or MCP server that ships today. What's worth examining is where the automation actually stops.The stack, verified
Three things anchor this workflow, and all three exist in the AWS ecosystem as of mid-2026.
AWS Transform is the discovery and code-transformation engine. It ingests server and application inventory, produces a business case with cost estimates, and organizes workloads into migration waves. For containerization specifically, it scans source repositories and generates deployment-ready artifacts, Dockerfiles, Terraform, and Helm charts among them, and every image it builds goes through CVE scanning before it's allowed to reach Amazon ECR. The source called this "AWS Transform with Containerization" as if it were a separately branded product; it isn't a distinct SKU, it's a capability of AWS Transform, now reachable directly from Kiro, Claude Code, Cursor, and other agentic IDEs through a dedicated MCP server since the developer-tools launch earlier this year.
Kiro CLI is the orchestration layer, the thing you actually talk to. The important architectural distinction is that it isn't replacing AWS services; it's coordinating them: a control plane for migration tasks rather than the migration engine itself. It doesn't migrate; it delegates to a set of specialized MCP servers on your behalf: the AWS API MCP Server for reading live resource state, the AWS Knowledge MCP Server for pulling current documentation and best practices instead of whatever a model memorized during training, and service-specific servers for EKS, ECS, and AWS Transform's own job lifecycle. AWS's published migration walkthroughs, including a Node.js EC2-to-EKS-Auto-Mode case study and a parallel EC2-to-ECS-Express-Mode one, both follow this exact pattern: Kiro CLI as the conversational front end, MCP servers doing the actual API calls underneath.
EKS Auto Mode is the landing zone. It removes node group management entirely; Karpenter picks instance types based on what your pods request, AWS manages the underlying AMIs and patches them, and the control plane stays out of your on-call rotation. The one number in the original piece worth double-checking was the patching cadence: nodes aren't patched on some vague "automatic" schedule; they're rotated on a hard maximum lifetime of 21 days, configurable downward but not upward, after which Karpenter drains and replaces them whether you've thought about it that week or not. That's a real operational constraint, not just a selling point, and it means anything holding a long-lived connection, an SSH session, a stateful job, needs a disruption budget or it will get pulled out from under you on someone else's timer.
How the pieces connect
The diagram below is closer to how I'd actually whiteboard this for a team than the original post's prose description. Kiro CLI sits outside the AWS boundary as the entry point; everything downstream of it is either an MCP server translating intent into API calls, or the AWS-native services those calls land on.
Worth noticing: CloudWatch isn't just a dashboard bolted on at the end. It feeds back into the planning stage, and it's also where human-in-the-loop approval lives. Anything destructive- a resource deletion, a wave cutover- gets a gate. Agents in this workflow aren't unsupervised; they're supervised at the specific points where a wrong autonomous decision is expensive to undo.
The workflow, stage by stage
Collapsing the three stages into one prompt-and-forget action would be the wrong takeaway. What's actually collapsed is the multi-week manual discovery and planning cycle, not the judgment calls inside it.
Discovery and planning start with AWS Transform ingesting whatever inventory data you feed it- server metadata, dependency maps, performance history- and turning that into a wave plan with real cost estimates attached. This is also where you'd ask Kiro something like "compare cold start metrics for our legacy Java functions and suggest an EKS target," and get an answer grounded in your actual CloudWatch data rather than a plausible-sounding guess, because the AWS API MCP Server is querying live resource state and the Knowledge MCP Server is checking that against current documentation instead of stale training data.
Containerization is where AWS Transform does the heavy lifting: scanning the codebase, including monorepos, and producing Dockerfile, Terraform, and Helm artifacts. Every image gets scanned for CVEs before it's allowed into ECR. This is the stage where I'd push back hardest on a "zero-touch" framing, since generated Terraform still needs a human to read it before it touches production state, especially anything involving IAM.
Deployment to EKS Auto Mode is the part that genuinely does get simpler than the old EC2-and-node-groups model. You're not choosing instance types, you're not tuning a cluster autoscaler, you're not tracking a compatibility matrix for kube-proxy, CoreDNS, and the VPC CNI plugin every time you upgrade. Karpenter handles instance selection from pod resource requests, AWS manages the AMI lifecycle, and that 21-day rotation ceiling keeps the fleet current without anyone filing a patching ticket.
Traditional migration | Autonomous workflow |
|---|---|
Manual inventory spreadsheets | AWS Transform discovery and wave planning |
Hand-written Dockerfile | Dockerfile generated from repo scan |
Manually assembled Helm charts | Manifests generated alongside the image |
Manual security review before push | Automatic CVE scanning ahead of ECR |
Manual node group sizing and patching | Karpenter selection, 21-day node rotation |
What the table doesn't show is that the rightmost column still has a human standing next to every row that involves deleting something or approving a cutover. That's not a gap in the automation; it's where the automation is supposed to stop.
Where I'd push back
The original piece framed this as a categorical shift from "how to write a Dockerfile" to "how to orchestrate a migration factory," and claimed a 4x acceleration figure for workload modernization. I couldn't find a source for that specific multiplier, so I've left it out rather than repeat an unverified number. What I can verify is directional: AWS's own published case studies describe migration timelines compressing from weeks to days, which is a real and meaningful claim, just a different one than a flat 4x.
The other place worth a skeptical read is "human-in-the-loop" as a footnote rather than the headline. In practice, the deterministic guardrails, requiring manual approval before any resource deletion, blocking disruption windows on stateful workloads, and reviewing generated IAM policies before applying, are not an optional add-on to this workflow. They're the difference between an agent that accelerates a migration and one that quietly deletes something you needed.
If you're setting this up yourself, the part worth spending real time on isn't the Kiro prompt; it's the NodePool disruption budgets and the approval gates around anything AWS Transform's agents generate with write access.
Zero-touch migration isn't about eliminating engineers; it's about eliminating repetitive engineering. Discovery, containerization, infrastructure generation, and deployment can increasingly run themselves, but architectural decisions, security reviews, and production approvals stay human responsibilities. The future this stack points to isn't autonomous infrastructure; it's supervised autonomy. Happy to walk through the specific MCP configuration or a CloudWatch alerting setup for an EKS Auto Mode cluster if that's useful.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article