Migration Readiness

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:

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?