/migration-readiness

name: migration-readiness
description: Assess a workload's readiness to migrate to AWS by analyzing existing code, dependencies, configurations, and infrastructure to produce evidence-backed findings covering the 7 Rs, risks, and a migration plan.
not_for: architecture decision records, single-pillar assessments, cost optimization of existing AWS workloads, full cross-pillar WA review
version: 2.0.0

Migration Readiness Assessment

Step 1: Gather context

Ask the user:

> What workload are you planning to migrate? Please share: > - **Workload name** and code packages/directories to analyze > - **Current environment** (on-premises, other cloud, colocation) > - **Business drivers** (cost, agility, compliance, end-of-life hardware, etc.) > - **Timeline constraints** (optional)

If context is already provided or you are in a codebase, proceed directly.

Step 2: Application Stack Discovery

Analyze the codebase to understand the current application stack.

You MUST examine:

• Programming languages and runtimes (versions, compatibility with AWS services)
• Frameworks and libraries (web frameworks, ORM, messaging)
• Database technologies (relational, NoSQL, search, caching)
• Middleware and message brokers
• External service dependencies (APIs, SaaS integrations)
• Configuration management (config files, environment variables, secrets)
• Operating system dependencies and system-level requirements
• Build and packaging systems (Maven, npm, pip, Docker)

For each component, document:

• File path and line numbers
• Technology and version
• AWS equivalent or migration path
• Migration complexity (simple lift, requires changes, requires rewrite)
• Dependencies on other components

You MUST flag as BLOCKER:

• OS-specific dependencies without cloud equivalents
• Proprietary software with licensing restrictions (Oracle, specific Windows features)
• Hardware-specific dependencies (FPGA, specific CPU instructions, USB dongles)
• Hardcoded IP addresses or hostnames in application code
• Local filesystem dependencies (shared network drives, local storage)

Step 3: Infrastructure Discovery

Analyze existing infrastructure configurations.

You MUST examine:

• Server configurations (CPU, memory, storage requirements)
• Network topology (VLANs, firewalls, load balancers, DNS)
• Storage systems (SAN, NAS, local disk, file shares)
• Database configurations (engine, version, size, replication)
• Monitoring and alerting systems
• Backup and DR configurations
• Security controls (firewalls, IDS/IPS, WAF, certificates)
• Existing IaC if any (Terraform, Ansible, Chef, Puppet)

For each infrastructure component, document:

• Current configuration
• AWS equivalent service
• Migration approach (rehost, replatform, refactor)
• Data volume and transfer considerations

Step 4: Dependency Mapping

Map all internal and external dependencies.

You MUST examine:

• Service-to-service communication (protocols, ports, patterns)
• Database connections (connection strings, pooling, multiple consumers)
• Shared databases or data stores (multiple services writing/reading)
• External API integrations (third-party services, partner APIs)
• Network dependencies (latency-sensitive connections, VPN tunnels)
• Batch job dependencies (scheduling, order of execution)
• Authentication/authorization dependencies (LDAP, AD, SSO)

You MUST create a dependency diagram showing:

• All services and their connections
• Data flows and protocols
• External dependencies
• Migration wave groupings (what must move together)

You MUST flag as HIGH RISK:

• Tight coupling between components that must move together (increases blast radius)
• Shared databases accessed by multiple services (migration ordering constraint)
• Latency-sensitive integrations that will span hybrid during migration
• Hard dependencies on on-premises systems that cannot move (require hybrid connectivity)

---STOP--- **Checkpoint**: Discovery and dependency mapping complete — ready to determine migration strategy

> Mapped the application stack ({X} components), infrastructure configurations, and dependency relationships. Identified {Y} blockers, {Z} high-risk dependencies (shared databases, latency-sensitive integrations), and migration wave groupings. > > **Shall I proceed with determining the migration strategy (7 Rs) for each component and assessing readiness by pillar?**

Do NOT proceed past this point until the user explicitly confirms. ---

Step 5: Determine migration strategy (7 Rs)

For each component, evaluate which strategy fits based on code evidence:

| Strategy | When to use | Code Indicators | |----------|-------------|-----------------| | **Rehost** | Fast migration, minimal changes | Standard OS, containerizable, no OS-specific deps | | **Replatform** | Small optimizations during move | Self-managed DB → RDS, self-managed cache → ElastiCache | | **Refactor** | Need cloud-native benefits | Monolith that should be decomposed, stateful → stateless | | **Repurchase** | Replace with SaaS | Commercial software with AWS/SaaS equivalent | | **Retire** | No longer needed | Unused code, deprecated services | | **Retain** | Not ready to move | Hard dependencies, compliance blockers | | **Relocate** | VMware workloads | VMware-specific configurations |

You MUST justify each recommendation with code evidence.

Step 6: Assess readiness by pillar

For each pillar, provide: **Readiness** (Ready/Conditionally Ready/Not Ready), **Evidence** (file:line), **Gaps**, **Actions needed**.

Operational Excellence Readiness

• Is there IaC? (CloudFormation, Terraform, CDK, Ansible)
• Are CI/CD pipelines in place? Can they target AWS?
• Is monitoring portable or tied to specific tools?
• Are operational procedures documented?

Security Readiness

• Are there compliance requirements affecting region/service choice?
• How are secrets managed? (hardcoded, vault, config files)
• Are there network security dependencies needing equivalents?
• Is identity management com