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 compatible with AWS IAM/Identity Center?

Reliability Readiness

• What is the current availability? What's the target?
• Are there HA mechanisms to replicate?
• What's the acceptable downtime during migration?
• Are backup/recovery procedures tested?

Performance Efficiency Readiness

• Are there latency-sensitive integrations?
• Are there hardware-specific dependencies?
• What are current performance baselines?
• Are there SLAs to maintain during cutover?

Cost Optimization Readiness

• What's the current TCO? (hardware, licensing, ops, facilities)
• Are there licensing implications? (BYOL, license-included, re-purchase)
• Are there existing contracts or prepaid commitments?

Sustainability Readiness

• Can migration reduce resource footprint?
• Are there opportunities for Graviton/serverless?
• Can managed services replace self-managed infrastructure?

Step 7: Risk Assessment

For each risk, assess using Impact × Likelihood:

Impact: Minor (schedule slip, minor rework) | Moderate (significant rework, extended hybrid period) | Severe (migration failure, data loss, extended outage)

Likelihood: Low (unlikely with proper planning) | Medium (possible without specific mitigation) | High (likely given current state)

Impact	Likelihood	Risk Level
Severe	High	Critical
Severe	Medium	High
Severe	Low	High
Moderate	High	High
Moderate	Medium	Medium
Moderate	Low	Medium
Minor	High	Medium
Minor	Medium	Low
Minor	Low	Low

---STOP--- Checkpoint: Risk assessment complete — ready to produce the final migration assessment

Assessed {N} risks across the migration. Risk distribution: {X} Critical, {Y} High, {Z} Medium, {W} Low. Overall readiness: {Ready / Conditionally Ready / Not Ready}. Critical blockers and mitigations identified.

Shall I produce the full Migration Readiness assessment with migration plan and cost comparison?

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

Step 8: Produce the assessment

# Migration Readiness Assessment: {Workload Name}

## Executive Summary
- **Date**: {date}
- **Packages Analyzed**: {list}
- **Recommended Strategy**: {primary strategy}
- **Overall Readiness**: {Ready / Conditionally Ready / Not Ready}
- **Estimated Effort**: {T-shirt size with justification}
- **Key Risks**: {top 3}
- **Critical Blockers**: {count and brief description}

## Application Stack Summary
| Component | Technology | Version | AWS Equivalent | Strategy | Complexity |
|-----------|-----------|---------|---------------|----------|------------|
| {name} | {tech} | {ver} | {aws service} | {7R} | {Low/Med/High} |

## Dependency Map
{PlantUML diagram showing service dependencies, data flows, and migration wave groupings}

## Readiness Scorecard
| Pillar | Readiness | Score (1-5) | Key Blocker | Action Needed |
|--------|-----------|-------------|-------------|---------------|
| Operational Excellence | {status} | {score} | {blocker} | {action} |
| Security | {status} | {score} | {blocker} | {action} |
| Reliability | {status} | {score} | {blocker} | {action} |
| Performance Efficiency | {status} | {score} | {blocker} | {action} |
| Cost Optimization | {status} | {score} | {blocker} | {action} |
| Sustainability | {status} | {score} | {blocker} | {action} |

## Critical Blockers
{For each: ID, description, evidence (file:line), impact on migration, resolution approach, effort}

## Risks and Mitigations
| Risk | Evidence | Risk Level | Migration Impact | Mitigation | AWS Service |
|------|----------|------------|-----------------|------------|-------------|
| {risk} | {file:line} | {level} | {impact} | {mitigation} | {service} |

## Pre-Migration Checklist
{Ordered by priority — what must be done before migration starts}
- [ ] {action with evidence of why it's needed}

## Migration Plan

### Phase 1: Mobilize (Weeks 1-2)
| Task | Dependencies | AWS Service | Evidence |
|------|-------------|-------------|----------|
{Landing zone, connectivity, tooling setup}


| Wave | Components | Strategy | Data Volume | Downtime Window |
|------|-----------|----------|-------------|-----------------|
{Component migration waves based on dependency analysis}


| Optimization | Component | Expected Benefit | AWS Service |
|-------------|-----------|-----------------|-------------|
{Right-sizing, managed services, serverless, Graviton}


| Category | Service | Purpose | Relevant Components |
|----------|---------|---------|-------------------|
| Server | AWS MGN | Rehost EC2 | {components} |
| Database | AWS DMS | Replicate with minimal downtime | {components} |
| Data | DataSync / Snowball | Large-scale transfer | {components} |
| Schema | AWS SCT | Schema conversion | {components} |
| Network | Direct Connect / VPN | Hybrid connectivity | {components} |
| Governance | Control Tower | Multi-account | All |


| Category | Current (monthly est.) | AWS Estimated | Delta | Notes |
|----------|----------------------|---------------|-------|-------|
| Compute | {estimate} | {estimate} | {delta} | {basis} |
| Storage | {estimate} | {estimate} | {delta} | {basis} |
| Networking | {estimate} | {estimate} | {delta} | {basis} |
| Licensing | {estimate} | {estimate} | {delta} | {basis} |
| Operations | {estimate} | {estimate} | {delta} | {basis} |


{Top 5 concrete actions the team should take this week to prepare}

Step 9: Offer follow-up

After delivering the assessment, offer:

Would you like me to:

• Design the AWS landing zone architecture?
• Create a detailed data migration plan for a specific database?
• Estimate AWS costs in detail for specific components?
• Build a pre-migration testing strategy?
• Design the hybrid connectivity architecture?
• Create IaC for the target AWS architecture?

Calibration Guidance

• A workload already containerized with CI/CD and IaC is LARGELY READY — focus on AWS-specific optimizations and data migration planning
• Every blocker and risk MUST have code evidence — don't flag "licensing risk" without checking actual dependencies
• Migration strategy recommendations must be justified by code analysis (not assumptions)
• "Cannot Determine" is valid for runtime characteristics not visible in code (e.g., actual data volumes, network latency requirements)
• For shared databases, always flag the migration ordering constraint — this is the #1 cause of migration complexity
• Cost estimates from static analysis are rough — acknowledge uncertainty and recommend AWS Pricing Calculator for precision
• Acknowledge migration-ready aspects prominently (containerized, stateless, IaC already exists)