Portfolio Assessment — AI Drafts the 6R, You Own the Override Log

Tier: Core · Hands-on time: ~35 minutes

The assessment phase of migration is being automated first: AWS Transform's assessment engine markets business cases in "hours, not a multi-month discovery project," and that is the direction of the whole segment. Whether the drafting engine is a vendor product or your own structured-output pipeline, the architect's role shifts the same way — from producing dispositions to validating them. This playbook trains that role deliberately: the model proposes rehost/replatform/refactor/repurchase/retire/retain with stated rationale and confidence; the human confirms or overrides; and the override log doubles as both audit trail and the calibration data that tells you when to trust the drafts.

When to use

• •
  A migration or modernization engagement needs 6R dispositions across a portfolio too large for app-by-app deep dives in the time available.
• •
  A first-pass triage must identify which applications deserve human deep-dives versus which are obvious calls.
• •
  An existing assessment (vendor tool or prior engagement) needs an independent second pass before wave planning commits to it.

Skip AI when the portfolio is under a dozen apps — Sameer's rule at the GCC: below that, the interviews are the assessment, and drafting adds a layer without adding speed.

Prerequisites

• The inventory dataCMDB export with whatever exists: tech stack, OS, dependencies, business owner, criticality, change frequency. Garbage-in warning applies: note which fields are trustworthy before drafting from them.
• Discovery interview notes per application cluster, where they exist — the qualitative signal that separates retire from retain.
• An LLM structured-output pipelinethe disposition table must land in a spreadsheet/database, not prose; client.messages.parse with a Pydantic model per app batch keeps the shape fixed.
• The engagement's decision rulestarget platform, licensing posture, compliance constraints, the client's appetite for refactor risk. Dispositions are relative to strategy, and the model must be told the strategy.

The workflow

1. 1.

   Write the disposition rubric first. One page: what makes an app a rehost candidate here (stable, low change, no license trap), what forces retain (mainframe adjacency, compliance pinning), what signals retire (no traffic, no owner, duplicate capability). The rubric is engagement-specific judgment — encoding it is the architect's real input to the drafting step, and it is what makes the model's rationales checkable against something.

2. 2.

   Draft in batches with rationale, confidence, and flags.

   Copy

   For each application record below, draft a 6R disposition using the
   attached rubric and target-platform strategy (GCC parent org, AWS
   target, exit two datacenters by FY-end).
   
   Per app, return: app_id; disposition (rehost/replatform/refactor/
   repurchase/retire/retain); rationale (2–3 sentences citing specific
   fields from the record or quotes from interview notes — cite which);
   confidence (high/medium/low with the single biggest uncertainty);
   data_gaps (fields empty or contradictory that materially affect the
   call); flags (license_risk, dependency_unknown, compliance_scope,
   owner_missing).
   
   Rules: when CMDB fields contradict interview notes, flag it — do not
   silently pick one. When data is insufficient for a call, disposition
   is INSUFFICIENT-DATA, not a guess. Never infer criticality from the
   app's name.
   ###
   [paste app batch]
   

3. 3.

   Validate app by app — at triage depth, not audit depth. Walk the drafted table in disposition order (retires first — they are the cheapest wrong answer to catch: an app drafted retire that finance runs quarterly is the classic miss). For each app: does the rationale's cited evidence exist, and does the rubric actually produce this call from that evidence? High-confidence drafts with clean data get seconds; low-confidence and flagged rows get the interview notes reopened. Book real time — a hundred apps is a day of validation, which is still a tenth of the manual assessment.

4. 4.

   Log every override with a reason code. When you change a disposition, record: app, AI call, your call, and why — coded (data the model lacked / rubric gap / model misread / strategic exception). The log serves three masters: the client sees governed judgment rather than tool output; the engagement's QA can sample it; and the code distribution tells you what to fix — many "rubric gap" entries mean the rubric needs a rule, many "model misread" entries mean the batch needs re-drafting with a tightened prompt.

5. 5.

   Convert INSUFFICIENT-DATA and flags into the discovery backlog. Every data gap the drafting surfaced is a discovery task with an owner: the CMDB fields to backfill, the interviews to schedule, the dependency scans to run. This inversion is the acceleration's real shape — discovery effort flows to where the assessment says uncertainty is, instead of being spread evenly across the portfolio.

6. 6.

   Package for wave planning. The validated disposition sheet, the override log, the discovery backlog, and a one-page summary (disposition counts, confidence distribution, top risks) feed pb-24. Dispositions marked low-confidence travel with that label — wave planning that treats a hedged retire as a firm one inherits the hedge as a surprise.

Verify before you trust it

• Sample rationales against source data. Ten apps, chosen randomly: open the CMDB record and notes, confirm every cited fact. A rationale citing a field value that is not in the record means the batch has fabrication in it — stop and audit the batch, not just the row.
• Retires get a second, human-only look. Retirement is the disposition that destroys things. Every retire call gets an owner confirmation or a traffic/log check before it enters the wave plan, regardless of the model's confidence.
• Contradiction flags were raised, not resolved. Spot-check apps where you know the CMDB and interviews disagree; the draft should show the flag. A model that silently harmonized conflicting sources is drafting fiction with clean formatting.
• The confidence column correlates with your overrides. After validation, check: were your overrides concentrated in low-confidence rows? If overrides scatter evenly across confidence levels, the model's self-assessment is noise — weight it accordingly next batch, and say so in the method notes.

Restricted-environment variant

A CMDB export is a map of the client's entire estate — among the most sensitive documents an engagement touches, and often explicitly restricted by the pb-03 register. Default to processing inside the client boundary: structured-output drafting via Bedrock/Azure OpenAI in the client's own subscription, or a local model for air-gapped assessments (the batch-drafting pattern works on capable local models; validate more aggressively). Pseudonymization is a workable middle path — app IDs replace names, business-owner fields drop — because the rubric operates on technical attributes; keep the mapping table client-side only. Interview notes carry names and candid judgments: scrub speaker identities before any external processing, whatever the tenancy.