Migration, Modernization & Scoping with Agentic AI

The assessment phase of the migration architect's job is being automated first. AWS Transform — an agentic migration and modernization workbench for Windows/.NET, VMware, and mainframe estates — advertises portfolio assessments in "hours, not a multi-month discovery project," and cites 4.56 billion lines of code analyzed. Those are vendor claims, and this module teaches you to treat them exactly as that — but the direction is unmistakable: the parts of migration work that are inventory, classification, and first-draft planning are moving to machines, and the architect's job is consolidating around scoping, verification, override judgment, and exception handling. This module is that job description.

The scenario — the sprint where the override log earned its keep

The economics of the week: assessment structuring that once took the better part of a month took days, and the architect's time concentrated exactly where it should — on the two apps where machine-readable data told the wrong story. The override log is the artifact that makes the speed defensible: it proves a human judged every disposition, and it records what kind of evidence the AI systematically misses, which is how the next sprint's prompts get better.

What You'll Learn

• RFP responses from a reuse libraryretrieval over past proposals and reference architectures, drafted at RFP speed, audited against what your team can actually deliver.
• Constraint extraction from MSAsturning client legal documents into a machine-checkable constraint register that governs both the solution and your own AI usage.
• Portfolio assessment with override disciplineAI-drafted 6R dispositions, per-app human validation, and the override log as a first-class deliverable.
• Agentic migration tooling, scoped and verifiedwhat Transform-class services automate, what the architect still owns, and how to treat vendor claims.
• Wave planning and legacy comprehensiondependency-driven wave drafts, cutover runbooks, and capability maps from old code, each with its verification gate.
• Cross-cloud IaC translation with parity gateswhy translated infrastructure is untrusted until a plan-diff harness proves equivalence.
• DR/BC drafting with failure tabletopsAI-drafted RTO/RPO tiering pressure-tested by generated failure scenarios, including the new one: your LLM dependency going down.

Scoping the engagement — RFPs, MSAs, and the RAID log

RFP responses from a reuse library (UC-03). For services-company architects like Rajesh, every 2026 RFP has a GenAI section, and response speed is competitive. The pattern is RAG over your own assets — past proposals, case studies, approved reference architectures — retrieving the nearest prior art and drafting tailored sections with consistent win themes. Two gates keep it honest: every capability claim is audited against what the delivery team can actually staff and ship (over-claiming is the taught pitfall — the RFP is a promise someone else must keep), and every service fact in the technical sections passes Module 1's verification checklist, because a hallucinated quota in a proposal becomes a contractual embarrassment later.

Constraint extraction from MSAs (UC-05). Before any AI touches engagement material, the architect answers a prior question: what do the client's contracts allow? MSAs, security questionnaires, and compliance addenda encode constraints — data residency, permitted subprocessors, tooling restrictions, audit rights — that govern both the solution architecture and your own AI usage on the engagement. "Can I paste this client's architecture into a chatbot?" is a contract question, and the default answer is no until the register says otherwise. Extraction is a structured-output task:

from pydantic import BaseModel
from typing import Literal
import anthropic

class Constraint(BaseModel):
    id: str
    category: Literal["data_residency", "tooling", "subprocessor",
                      "audit", "security", "ai_usage", "other"]
    requirement: str            # the obligation, in plain words
    source_clause: str          # verbatim quote from the document
    location: str               # section / page reference
    affects_own_ai_usage: bool  # does this bind OUR tools on this engagement?

class ConstraintRegister(BaseModel):
    document: str
    constraints: list[Constraint]
    ambiguities: list[str]      # clauses needing legal interpretation

client = anthropic.Anthropic()

def extract_constraints(msa_text: str) -> ConstraintRegister:
    resp = client.messages.parse(
        model="claude-opus-4-8",
        max_tokens=4000,
        thinking={"type": "adaptive"},
        system=(
            "Extract architecture-relevant constraints from this contract "
            "excerpt. Every constraint must quote its source clause "
            "verbatim — no quote, no constraint. Route unclear clauses to "
            "ambiguities; never resolve legal ambiguity yourself."
        ),
        messages=[{"role": "user", "content": msa_text}],
        output_format=ConstraintRegister,
    )
    return resp.parsed_output

The verbatim source_clause is the verification hook: every register entry is checked against its quote, and the quote against the document. Ambiguous clauses go to legal, not to the model's best guess. The finished register does double duty for the rest of this module — it constrains the solution design, and it is the client-safe-variant switch for every AI workflow on the engagement (App 9's compliance surprise in the scenario is what happens when constraint-grade evidence lives outside the structured data).

The RAID log (UC-06). Discovery notes → drafted risks, assumptions, issues, dependencies, with severity/likelihood scaffolding — the ratings themselves are set by the architect, per Module 1's division-of-labor rule. The RAID draft is the cheap first hour of an engagement that most teams skip and later regret.

Portfolio assessment — the override log is the deliverable

The 6R assessment (UC-22) is the workflow from the scenario, and its shape is the module's template: AI drafts every disposition; the architect validates every disposition; overrides are logged with evidence. The draft pass runs structured outputs over CMDB exports and interview notes, producing per-app: disposition, rationale, confidence, and — critically — the evidence it relied on. Then the validation pass, one app at a time, asks a single question: does the evidence actually support this disposition, and is there evidence outside the structured data that changes it?

The override log from Sameer's sprint, as the artifact looks in practice:

Three properties make the log more than bureaucracy:

• It proves human judgment happened. In a regulated or client-audited migration, "an AI classified your estate" is not a defensible process; "an AI drafted, an architect validated each app, here are the overrides" is.
• It is a systematic-error detector. Both of Sameer's overrides share a signature — decisive evidence living in unstructured or out-of-band sources. That pattern feeds back into the next sprint's inputs and prompts.
• Zero overrides is a red flag, not a triumph. Across a real portfolio, a validation pass that changes nothing usually means the pass didn't happen. Sameer's factory made that policy: no-override sprints get audited.

Agentic migration tooling — scope it, verify it, handle exceptions

Transform-class services (UC-23) run agentic pipelines across assessment → planning → code transformation for named estates: Windows/.NET, VMware, mainframe — with 2026 additions including continuous-modernization previews, mainframe assessment-to-code, and migration of AI workloads to Bedrock. Azure runs the parallel play with Azure Migrate plus Copilot. The architect's relationship to this tool class has three verbs, none of which is "trust":

1. 1Scope it. Decide which estate segments enter the agentic pipeline at all. The tools are strongest on the estates they were built for; feeding them the long tail of odd, undocumented systems produces confident nonsense at scale. Your constraint register (above) also gates scope — client contracts may prohibit code leaving approved environments.
2. 2Verify it. Every agentic output — assessment findings, wave suggestions, transformed code — inherits the discipline of this module: dispositions get the override-log treatment; generated code goes through the same validate→plan→policy→cost chain as Module 2's IaC skeletons; business-case numbers are traced to verifiable inputs. The vendor's own numbers get the same skepticism: 4.56 billion lines analyzed and 1.69 million hours saved are vendor claims — useful as directional evidence that the category works, inadmissible as evidence about your estate. Your estate's evidence comes from your pilot wave.
3. 3Handle exceptions. The apps that fall out of the automated path — the mis-dispositioned, the contractually constrained, the genuinely weird — become the architect's concentrated workload. This is the job shift in one line: from doing the assessments to owning everything the machine gets wrong.

Legacy comprehension (UC-25) is the input-side sibling: large-context AI over legacy codebases — COBOL, aging .NET, stored-procedure sprawl — produces capability maps and interface inventories that feed target design. The architect consumes the map and designs the target; the map's claims about critical interfaces are spot-verified against the running system before the target design hardens, because a hallucinated interface in a capability map becomes a missing integration on cutover weekend.

Waves, cutovers, and translated infrastructure

Wave planning (UC-24). Dependency data — network flows, CMDB relations — plus constraints in; candidate wave plans with risk annotations out. AI is genuinely good at the combinatorics; the gates are two. First, spot-check the dependency data itself before believing any plan built on it: sample the claimed flows against observed traffic, because dependency exports are notoriously stale and a wave plan inherits every error. Second, sequencing sign-off is human — the AI doesn't know that the App 9 compliance filing lands on the 5th of the month, or that the client's freeze window moves for Diwali. The plan ships when the architect has walked every wave boundary asking "what breaks if this order is wrong?"

Cutover runbooks (UC-28). Per-app runbooks — steps, checks, abort criteria, comms plan — are checklist-shaped documents AI drafts well from the wave plan and app profile. The gate is a dry run: a runbook that hasn't been rehearsed is a hypothesis, and abort criteria in particular get human scrutiny, because they're what you'll be reading at 02:00 mid-cutover.

Cross-cloud IaC translation with parity gates (UC-27). CloudFormation→Terraform, ARM→Bicep, cloud-A→cloud-B: AI translates fluently, and fluently wrong. Service mappings are where it fails — near-equivalent services with different defaults, semantics, or limits translated as if identical, plus the familiar hallucinated resource attributes. The rule mirrors Module 2's but goes further: translated IaC is untrusted until a parity harness proves it —

• Static paritythe translated stack passes validate and produces a plan; every resource in the source maps to an explicit resource, or an explicit, documented gap, in the target.
• Plan-diff parityresource-by-resource comparison of what each stack would create: counts, types, key attributes (sizing, encryption, network placement). Unexplained deltas are defects.
• Behavioral spot checksfor the services where mapping is semantically loose (queues, identity, managed databases), deploy-and-compare on the specific behaviors the architecture depends on.
• A written trap listevery mapping the AI got confidently wrong goes into the engagement notes; the traps recur, and the list is transferable knowledge. Lab 05 seeds two such traps and grades whether you catch and document both.

DR/BC drafting — and the tabletop that includes your LLM

DR/BC strategy (UC-26) gets the draft-then-attack treatment. AI drafts the RTO/RPO tier proposal per workload class — tiers, replication posture, failover approach — as a structured starting point; the architect validates tier assignments against business impact, which is judgment the model doesn't have. Then the same tooling switches sides and generates the failure tabletops that pressure-test the draft: region loss, quota exhaustion, provider outage, dependency-chain failures — walked scenario by scenario against the proposed design until it breaks or holds.

One scenario class is new to the AI era, and migration architects now own it: the LLM dependency in your DR plan. Any workload that acquired an AI feature during modernization has acquired a new external dependency with its own failure modes — model-provider outages, and quota exhaustion that presents as throttling rather than failure. A 2026-grade DR tabletop asks: what does this application do when its model endpoint is down or throttled? Degrade to a non-AI path? Queue? Fail visibly? If the DR plan has no answer, the modernization added an availability liability nobody signed for. (Designing those degradation ladders in depth is Module 7's territory; the DR plan's job is to make sure the question is asked.)

Where this lands in your week

• Per RFPretrieval-drafted sections from the reuse library; capability claims audited against delivery reality; service facts verified and cited.
• Per engagement startMSA constraint extraction with verbatim clause anchors; the register gates both the solution and your own AI tooling; RAID log drafted in hour one.
• Per assessment sprintAI-drafted dispositions, per-app validation, override log filed as a deliverable; zero overrides triggers a second look.
• Per wavedependency data spot-checked before planning; sequencing human-signed; cutover runbooks dry-run before they're trusted.
• Per translationthe parity harness runs before any translated stack is called done; the trap list grows.
• Per DR reviewAI-generated failure tabletops against the draft, including the LLM-dependency scenario for every AI-touched workload.

Your playbooks & labs

Two labs anchor this stage. Lab 04 — Migration assessment sprint: a 12-app synthetic portfolio (CMDB export + interview notes) → AI-drafted 6R dispositions, wave plan, one-page business case — with every override logged and justified; the override log is graded. Lab 05 — Cross-cloud IaC translation with a parity gate: translate a CloudFormation stack to Terraform with AI, prove parity via the plan/deploy-compare harness, and document the two seeded service-mapping traps.

Companion playbooks: pb-21 (RFP Response Drafting from a Reuse Library), pb-22 (Portfolio Assessment — AI Drafts the 6R, You Own the Override Log), pb-23 (Agentic Migration Tooling — Scope It, Verify It, Handle Exceptions), pb-24 (Wave Planning, Dependency Analysis & Cutover Runbooks), pb-25 (Legacy Comprehension — Capability Maps from Old Code), pb-26 (DR/BC Strategy Drafting + Failure Tabletops), pb-27 (Cross-Cloud IaC Translation with Parity Gates) — plus, from the scoping area, pb-03 (Constraint Extraction from MSAs & Compliance Addenda) and pb-04 (RAID Log Drafting from Discovery Notes).