Agentic migration workbenches — AWS Transform for Windows, VMware and mainframe estates, Azure Migrate with Copilot — now run assessment-to-code pipelines that used to be the engagement itself. The architect's job relocates: scope what the agent attempts, verify what it claims, and own every exception it cannot handle.
Tier: Advanced · Hands-on time: ~35 minutes
Agentic migration is a product category, not a forecast: AWS Transform runs agentic assessment, planning, and code transformation across .NET, VMware, and mainframe workloads, and its vendor materials claim billions of lines analyzed and headline hour-savings. Treat every such figure as what it is — a vendor claim about other people's estates, not a prediction about yours. Nothing about your accountability changed: the tool's output enters the client's production path only after the same verification you would apply to a subcontractor of unknown quality who works very fast and never says "I'm not sure." This playbook is the operating discipline: scope narrowly, verify by evidence class, and build the exception path before the first run.
Skip AI-agent tooling when the estate is small, exotic, or undocumented enough that scoping the agent costs more than doing the work — a dozen hand-crafted VMs with tribal-knowledge dependencies is a human job with a checklist.
Scope by capability match, from the docs. Build the scoping table before touching the tool: for each estate segment, what does the vendor documentation say the tool supports (source OS/framework versions, language levels, target patterns) — with doc links — versus what the segment actually contains. Segments outside documented support are human scope from day one, not "we'll see what it does." This table is also your commercial protection: when the tool's coverage disappoints, the doc-cited scoping shows the gap was known and planned for.
Set the verification gates before the first run. Decide per output class what proof admits it: assessment findings get sampled against the estate (does this server really run that framework version?); generated plans get dependency-order review by someone who knows the estate; transformed code gets the full chain — build, tests, security scan, behavior comparison in a staging environment. Writing the gates first prevents the demo-effect failure where impressive early output relaxes standards for everything after.
Run the pilot and sample its assessment claims.
Structure my verification sample for the Transform pilot on the
[CLUSTER-7] Windows estate (42 servers, .NET Framework mix).
The tool's assessment claims are attached as CSV.
Build: (1) a stratified sample of 8 servers covering every claimed
framework version and both "modernization-ready" and "blocked"
verdicts; (2) for each, the exact checks a human runs to confirm the
claim (registry keys, IIS config, dependency lists to pull); (3) a
scoring sheet — claim confirmed / partially wrong / wrong — so I can
compute a per-class accuracy rate for this estate.
Using an LLM to organize verification of another AI's output is the pattern worth internalizing: the workbench asserts, your sampling harness measures, and the measured accuracy rate on your estate — not the vendor's case studies — decides how much scope the tool earns next.
Route everything the agent flags, skips, or fumbles into the exception register. Agentic tools are honest about some limits (unsupported components lists) and silent about others (transformed code that compiles but changes behavior). Both land in the register with a human owner. The register is where the engagement's real architecture work now concentrates — the exceptions are, almost by definition, the interesting parts of the estate.
Gate promotion on measured accuracy, not elapsed calendar. Expand the tool's scope cluster by cluster, each expansion justified by the previous cluster's verification scores. A tool scoring well on assessment but poorly on code transformation gets its scope split — assessments trusted at sample-verification depth, transformations held at full-review depth. Write the current trust level down; teams inherit tools without inheriting the calibration.
Report with claims labeled. Engagement reporting distinguishes three numbers that vendor materials blur: what the tool attempted, what survived verification, and what humans did in exception handling. The client's steering committee should never receive a vendor's "hours saved" framing as your engagement metric — Sameer reports "agent-produced, human-verified: 31 of 42 servers; exceptions in flight: 11" and lets the ratio speak.
These workbenches ingest the client's estate wholesale — source code, VM images, dependency maps — so tenancy is the first architectural question, not an afterthought: the tool runs in the client's own cloud account under their controls, or it does not run. Verify the vendor's data-handling terms (retention, model-training use, support access) against the pb-03 register before onboarding, and put the answers in writing to the client. For estates where even in-tenancy agentic processing is refused (defense, some BFSI), the playbook's structure survives without the product: pb-22 assessment plus pb-25 legacy comprehension plus human transformation teams, with the same verification gates — the gates were never the tool's property.
An agentic migration tool is a subcontractor with infinite confidence and no liability. Scope it in writing, measure its accuracy on your estate, and keep the exception register where the client can see it — the architect who skips the middle step has delegated their signature, not their work.