migration-readiness

# Migration Readiness Assessment ## Step 1: Gather context Ask the user: > What workload are you planning to migrate? Please share: > - **Current environment** (on-premises, other cloud, colocation) > - **Application stack** (languages, frameworks, databases, middleware) > - **Dependencies** (other systems it talks to, shared databases, network requirements) > - **Business drivers** (cost, agility, compliance, end-of-life hardware, etc.) > - **Timeline constraints** (optional) If context is already provided, proceed directly. ## Step 2: Determine migration strategy (7 Rs) For the workload, evaluate which strategy fits: | Strategy | When to use | |----------|-------------| | **Rehost** (lift & shift) | Fast migration, minimal changes, optimize later | | **Replatform** (lift & reshape) | Small optimizations during move (e.g., managed DB) | | **Refactor** (re-architect) | Need cloud-native benefits, willing to invest | | **Repurchase** | Replace with SaaS (e.g., CRM → Salesforce) | | **Retire** | No longer needed | | **Retain** | Not ready to move yet | | **Relocate** | VMware workloads → VMware Cloud on AWS | Recommend a strategy with justification based on the user's drivers and constraints. ## Step 3: Assess readiness by pillar For each pillar, classify readiness as: - 🟢 **Ready** — no blockers, can proceed - 🟡 **Conditionally Ready** — gaps exist but can be addressed during migration - 🔴 **Not Ready** — blockers must be resolved before migration ### Operational...