Structured workflow for migrating applications and infrastructure from on-premises or between cloud providers. Covers assessment, planning, migration execution, optimization, and governance to ensure a smooth transition with minimal business disruption and maximum cloud value.
Use when the user wants to cloud migration or needs a structured multi-step process for this goal.
Do NOT use when the request is a single-step task or requires professional advice beyond educational guidance.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Structured workflow for migrating applications and infrastructure from on-premises or between cloud providers. Covers assessment, planning, migration execution, optimization, and governance to ensure a smooth transition with minimal business disruption and maximum cloud value.
Use when the user wants to cloud migration or needs a structured multi-step process for this goal.
Do NOT use when the request is a single-step task or requires professional advice beyond educational guidance.
Cloud migration is a strategic undertaking that, when done well, delivers agility, scalability, and cost efficiency. When done poorly, it creates expensive, hard-to-manage cloud infrastructure that costs more than the on-premises systems it replaced. This workflow provides a structured approach: assess what you have, plan how to migrate it, execute the migration in waves, optimize for cloud-native benefits, and establish governance for ongoing management.
The workflow uses the industry-standard 6 R's framework for categorizing migration strategies: Rehost (lift-and-shift), Replatform (lift-and-reshape), Refactor (re-architect for cloud-native), Repurchase (replace with SaaS), Retire (decommission), and Retain (keep on-premises). Each application gets the migration strategy that matches its business value and technical complexity.
When to Use
User wants to cloud migration
User needs a structured, step-by-step process for cloud migration
User wants to migrate to the cloud
I need to move from on-prem to AWS
How do I plan a cloud migration
Do NOT use when: the request is outside the scope of cloud migration or requires professional advice beyond educational guidance
Do NOT use for single-step tasks that one atomic skill can handle independently
Prerequisites
Before starting this workflow, ensure:
Executive sponsorship and budget allocation for migration
Inventory of applications and infrastructure to migrate
Cloud provider account (AWS, Azure, or GCP)
Network connectivity between on-premises and cloud (VPN or Direct Connect)
Team with cloud skills (or training plan)
Business continuity requirements (acceptable downtime per application)
Steps
Step 1: Assess Current State (uses: risk-assessor)
identify migration risks and the AWS Architect skill (or equivalent for your target cloud) to assess cloud readiness. Catalog every application: technology stack, dependencies, data volume, traffic patterns, compliance requirements, and business criticality. Map the dependency graph: which applications depend on which databases, APIs, and shared services. Calculate current total cost of ownership (TCO) for baseline comparison. Identify high-risk applications (stateful, tightly coupled, legacy technology) that need special attention.
Key focus: Use the Risk Assessor skill to identify migration risks and the AWS Architect skill (or equivalent for your target cloud) to assess cloud readiness
Step 2: Plan Migration Waves (uses: aws-architect)
classify each application using the 6 R's framework: Rehost, Replatform, Refactor, Repurchase, Retire, or Retain. Then organize applications into migration waves (batches of 3-7 applications migrated together). Wave 1 should be low-risk, non-critical applications to build team confidence and validate the migration process. Subsequent waves increase in complexity and criticality. Create a detailed plan for each wave: migration strategy, timeline, rollback procedure, success criteria, and team assignments.
Input: Assessment from Step 1, Business priorities and timelines, Team capacity and cloud expertise
Output: 6 R's classification for every application, Migration wave plan (applications per wave, with sequence), Detailed migration plan per wave (strategy, timeline, rollback)
Key focus: Use the AWS Architect skill to classify each application using the 6 R's framework: Rehost, Replatform, Refactor, Repurchase, Retire, or Retain
Step 3: Set Up Cloud Foundation (uses: terraform-engineer)
build the cloud foundation as code: account structure (multi-account for production, staging, shared services), networking (VPC, subnets, security groups, VPN/Direct Connect to on-premises), IAM (roles, policies, SSO), and shared services (logging, monitoring, DNS). Use the Security Hardener skill to apply cloud security best practices from day one: CIS benchmarks, encryption defaults, IAM least privilege, and audit logging. This foundation must be solid before any application migration begins.
Input: Target cloud architecture from Step 2, Security and compliance requirements, Network connectivity requirements
Key focus: Use the Terraform Engineer skill to build the cloud foundation as code: account structure (multi-account for production, staging, shared services), networking (VPC, subnets, security groups, VPN/Direct Connect to on-premises), IAM (roles, policies, SSO), and shared services (logging, monitoring, DNS)
containerize applications if replatforming. Use the Database Architect skill to plan database migration strategies (schema migration, data transfer, replication cutover). Use the Data Migration Specialist skill for zero-downtime data migration where required. Execute the migration: provision cloud infrastructure, migrate data, deploy application, validate functionality, switch traffic (DNS cutover or load balancer switch), and monitor. Keep the on-premises environment running as a rollback target for at least 2 weeks after cutover.
Input: Wave 1 applications (low-risk, non-critical), Cloud foundation from Step 3, Migration strategy per application (rehost, replatform, etc.)
Output: Migrated Wave 1 applications in cloud, Database migration scripts and verification reports, Cutover runbooks (step-by-step procedure)
Key focus: Use the Docker Engineer skill to containerize applications if replatforming
Step 5: Monitor and Optimize (uses: monitoring-engineer)
set up cloud-native monitoring for migrated applications. Compare performance metrics against the on-premises baseline. Use the Cloud Cost Optimizer skill to identify optimization opportunities: right-size instances, implement auto-scaling, convert to reserved instances for stable workloads, use spot instances for batch processing, and clean up unused resources. Cloud costs in the first month are often 2-3x the steady-state cost due to over-provisioning -- optimization brings costs down to target.
Input: Migrated applications from Step 4, SLIs/SLOs for migrated services, Cloud cost data
Output: Cloud monitoring dashboards for migrated applications, Performance comparison report (cloud vs on-premises), Cost optimization report with recommendations
Key focus: Use the Monitoring Engineer skill to set up cloud-native monitoring for migrated applications
Execute remaining migration waves, applying lessons learned from Wave 1. Each wave should be faster than the previous one as the team builds expertise and reuses infrastructure patterns. For applications classified as Refactor, design cloud-native deployments. For applications classified as Retire or Repurchase, coordinate decommission with the SaaS replacement timeline. Track progress against the overall migration plan and adjust wave composition as needed.
Input: Lessons learned from Wave 1, Remaining migration waves from Step 2, Refined processes and tooling
Output: Migrated applications per wave, Migration progress dashboard, Updated cost comparison (cloud vs on-premises)
establish ongoing cost governance: budget alerts, cost allocation tags, monthly cost review process, and anomaly detection. Use the Security Hardener skill to establish security governance: automated compliance scanning, security baseline enforcement, IAM review cadence, and incident response procedures for cloud. Create guardrails (Service Control Policies, landing zone rules) that prevent common mistakes without blocking development.
Key focus: Use the Cloud Cost Optimizer skill to establish ongoing cost governance: budget alerts, cost allocation tags, monthly cost review process, and anomaly detection
Decision Points
After Step ?:
If After Step 1: Fill assessment gaps before planning
If After Step 3: Fix foundation security before migrating workloads
If After Step 4: Resolve Wave 1 issues before migrating more
If After Step 5: Optimize before adding more workloads
Failure Handling
Lift-and-shift everything: -- Not every application should be rehosted. Some should be refactored, some repurchased as SaaS, and some retired. Use the 6 R's framework.
No cloud foundation: -- Migrating applications without a solid foundation (networking, security, IAM) creates technical debt from day one.
Underestimating data migration: -- Data migration is often the hardest part. Plan for data validation, cutover windows, and rollback.
Ignoring costs until the bill arrives: -- Cloud spending can grow rapidly without governance. Set up cost monitoring and alerts before migration.
Big-bang migration: -- Migrating everything at once is high-risk. Use waves, starting with low-risk applications.
Expected Outcome
When this workflow is complete, the user will have:
All planned applications are migrated within the timeline and budget
Cloud costs are within 10% of projected estimates
Application performance meets or exceeds on-premises baseline
Zero data loss during migration
Downtime during migration stays within agreed business windows
Cloud governance prevents uncontrolled cost growth and security drift
Team is self-sufficient in cloud operations within 3 months of migration
Adjust timeline based on user's availability and prior experience
Steps may be reordered if dependencies allow parallel execution
Skip optional steps if time or budget is constrained
Edge Cases
Lift-and-shift everything: -- Not every application should be rehosted. Some should be refactored, some repurchased as SaaS, and some retired. Use the 6 R's framework.
No cloud foundation: -- Migrating applications without a solid foundation (networking, security, IAM) creates technical debt from day one.
Underestimating data migration: -- Data migration is often the hardest part. Plan for data validation, cutover windows, and rollback.
Ignoring costs until the bill arrives: -- Cloud spending can grow rapidly without governance. Set up cost monitoring and alerts before migration.
Example
Input: "I want to cloud migration and need a structured plan to follow step by step."
Output:
Step 1 (risk-assessor-aws-architect): Assess Current State -- produces concrete deliverables for this phase.
Step 2 (aws-architect-risk-assessor): Plan Migration Waves -- produces concrete deliverables for this phase.
Step 3 (terraform-engineer-security-hardener): Set Up Cloud Foundation -- produces concrete deliverables for this phase.
Step 4 (docker-engineer-database-architect-data-migration-specialist): Migrate Wave 1 (Validation Wave) -- produces concrete deliverables for this phase.
Step 5 (monitoring-engineer-cloud-cost-optimizer): Monitor and Optimize -- produces concrete deliverables for this phase.
Step 6 (aws-architect-docker-engineer-kubernetes-operator): Migrate Remaining Waves -- produces concrete deliverables for this phase.
Step 7 (cloud-cost-optimizer-security-hardener): Establish Cloud Governance -- produces concrete deliverables for this phase.
Result: User has a complete cloud migration plan with all deliverables produced, validated, and ready for implementation.
