From migration-to-aws
Migrate workloads from Google Cloud Platform to AWS. Triggers on: migrate from GCP, GCP to AWS, move off Google Cloud, migrate Terraform to AWS, migrate Cloud SQL to RDS, migrate GKE to EKS, migrate Cloud Run to Fargate, Google Cloud migration. Runs a 6-phase process: discover GCP resources from Terraform files, app code, or billing exports, clarify migration requirements, design AWS architecture, estimate costs, generate migration artifacts, and collect optional feedback. Clarify must finish before Design, Estimate, or Generate. Includes AI provider migration guidance (for example, OpenAI to Amazon Bedrock) by selecting closest-fit Bedrock model families for required modality, latency/quality targets, context windows, and cost constraints. Model mapping is compatibility-guided, not 1:1 parity; validate prompts, tool-calling behavior, and eval metrics before cutover. Do not use for: Azure or on-premises migrations to AWS, AWS-to-GCP reverse migration, general AWS architecture advice without migration intent, GCP-to-GCP refactoring, or multi-cloud deployments that do not involve migrating off GCP.
How this skill is triggered — by the user, by Claude, or both
Slash command
/migration-to-aws:gcp-to-awsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
- **Re-platform by default**: Select AWS services that match GCP workload types (e.g., Cloud Run → Fargate, Cloud SQL → RDS).
references/clustering/terraform/classification-rules.mdreferences/clustering/terraform/clustering-algorithm.mdreferences/clustering/terraform/depth-calculation.mdreferences/clustering/terraform/typed-edges-strategy.mdreferences/design-refs/ai-gemini-to-bedrock.mdreferences/design-refs/ai-openai-to-bedrock.mdreferences/design-refs/ai.mdreferences/design-refs/compute.mdreferences/design-refs/database.mdreferences/design-refs/design-ref-agentic-to-agentcore.mdreferences/design-refs/design-ref-harness.mdreferences/design-refs/fast-path.mdreferences/design-refs/index.mdreferences/design-refs/messaging.mdreferences/design-refs/networking.mdreferences/design-refs/security.mdreferences/design-refs/storage.mdreferences/phases/clarify/clarify-ai-only.mdreferences/phases/clarify/clarify-ai.mdreferences/phases/clarify/clarify-compute.mdgoogle_bigquery_*: The skill does not recommend a specific AWS analytics or warehouse service. During Clarify, if discovery shows BigQuery (IaC google_bigquery_* and/or billing rows for BigQuery), you must surface the specialist advisory before Design (see references/phases/clarify/clarify.md). Design output uses Deferred — specialist engagement; keep directing the user to their AWS account team and/or a data analytics migration partner through Design, Estimate, and docs (see references/phases/design/design-infra.md BigQuery specialist gate).$MIGRATION_DIR = The run-specific directory under .migration/ (e.g., .migration/0226-1430/). Set during Phase 1 (Discover).Each phase loads reference files on demand. To keep per-turn context manageable and prevent instruction-following degradation:
agentic_profile.is_agentic == true) MUST NOT be loaded unless the condition is met. Do not speculatively load files.design.md, generate.md) contain short routing logic that points to detailed sub-files. Load the sub-file only when its path is selected.Conditional reference files (load ONLY when condition is true):
| File | Condition |
|---|---|
design-refs/ai-gemini-to-bedrock.md | ai-workload-profile.json exists AND summary.ai_source = "gemini" or "both" |
design-refs/ai-openai-to-bedrock.md | ai-workload-profile.json exists AND summary.ai_source = "openai" or "both" |
design-refs/ai.md | ai-workload-profile.json exists AND summary.ai_source = "other" |
design-refs/design-ref-harness.md | agentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "harness" |
design-refs/design-ref-agentic-to-agentcore.md | agentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "strands" |
shared/retarget-gotchas.md | agentic_profile.is_agentic == true AND ai_constraints.agentic.migration_approach == "retarget" |
When adding new reference files, verify the phase's total loaded instructions remain under budget. If a new file would exceed ~800 lines when combined with other loaded refs, split it or make it conditional.
User must provide at least one GCP source:
.tf files (with optional .tfvars, .tfstate)If none of the above are found, stop and ask user to provide at least one source type.
This is the execution controller. After completing each phase, consult this table to determine the next action.
| Current State | Condition | Next Action |
|---|---|---|
discover | phases.discover != "completed" | Load references/phases/discover/discover.md |
clarify | phases.discover == "completed" AND phases.clarify != "completed" | Load references/phases/clarify/clarify.md |
design | phases.clarify == "completed" AND phases.design != "completed" | Load references/phases/design/design.md |
estimate | phases.design == "completed" AND phases.estimate != "completed" | Load references/phases/estimate/estimate.md |
generate | phases.estimate == "completed" AND phases.generate != "completed" | Load references/phases/generate/generate.md |
complete | phases.generate == "completed" AND phases.feedback == "pending" | Set phases.feedback to "completed" (user had two chances), then migration complete |
complete | phases.generate == "completed" AND phases.feedback == "completed" | Migration planning complete |
How to determine current state (deterministic):
$MIGRATION_DIR/.phase-status.jsoncurrent_phase exists, use it (must match one of: discover, clarify, design, estimate, generate, complete)discover → clarify → design → estimate → generatephases.<phase> != "completed"; if none, state is completePhase gate checks: If prior phase incomplete, do not advance (e.g., cannot enter estimate without completed design).
Clarify is mandatory: Do not load references/phases/design/design.md, references/phases/estimate/estimate.md, or references/phases/generate/generate.md unless $MIGRATION_DIR/.phase-status.json exists and phases.clarify is exactly "completed". A preferences.json file alone is not sufficient proof that Clarify ran. If the user asks to skip Clarify or jump straight to Design, cost estimate, or artifact generation, refuse briefly, then load references/phases/clarify/clarify.md and run Phase 2. There is no exception for "quick" or "obvious" migrations.
Feedback checkpoints: Feedback is not a sequential phase — it is offered at two interleaved checkpoints (after Discover and after Estimate). See the Feedback Checkpoints section below for details.
When reading $MIGRATION_DIR/.phase-status.json, validate before proceeding:
.migration/, list them with their phase status and ask: [A] Resume latest, [B] Start fresh, [C] Cancel..phase-status.json fails to parse, STOP. Output: "State file corrupted (invalid JSON). Delete the file and restart the current phase."phases object contains a phase not in {discover, clarify, design, estimate, generate, feedback}, STOP. Output: "Unrecognized phase: [value]. Valid phases: discover, clarify, design, estimate, generate, feedback."phases.* value is not in {pending, in_progress, completed}, STOP. Output: "Unrecognized status: [value]. Valid values: pending, in_progress, completed."current_phase (if present): If current_phase is not in {discover, clarify, design, estimate, generate, complete}, STOP. Output: "Unrecognized current_phase: [value]. Valid values: discover, clarify, design, estimate, generate, complete.""completed" while an earlier phase is not "completed", STOP. Output: "Inconsistent phase ordering detected. Reconcile .phase-status.json before resuming.""in_progress". If >1, STOP. Output: "Multiple phases are in_progress. Keep only one active phase before resuming."Migration state lives in $MIGRATION_DIR (.migration/[MMDD-HHMM]/), created by Phase 1 and persisted across invocations.
.phase-status.json schema:
{
"migration_id": "0226-1430",
"last_updated": "2026-02-26T15:35:22Z",
"current_phase": "design",
"phases": {
"discover": "completed",
"clarify": "completed",
"design": "in_progress",
"estimate": "pending",
"generate": "pending",
"feedback": "pending"
}
}
Status values: "pending" → "in_progress" → "completed". Never goes backward.
For core phases (discover, clarify, design, estimate, generate), at most one phase may be "in_progress" at any time.
current_phase is optional but recommended; when present it is authoritative.
The .migration/ directory is automatically protected by a .gitignore file created in Phase 1.
Use read-merge-write updates for .phase-status.json:
last_updated.current_phase to the next deterministic phase (or complete after generate).Example — after completing the Clarify phase, write $MIGRATION_DIR/.phase-status.json with:
{
"migration_id": "MMDD-HHMM",
"last_updated": "2026-02-26T15:35:22Z",
"current_phase": "design",
"phases": {
"discover": "completed",
"clarify": "completed",
"design": "pending",
"estimate": "pending",
"generate": "pending",
"feedback": "pending"
}
}
Replace MMDD-HHMM with the actual migration ID, generate the last_updated ISO 8601 UTC timestamp yourself, and set each phase to its correct status at that point.
| Phase | Inputs | Outputs | Reference |
|---|---|---|---|
| Discover | .tf files, app source code, and/or billing exports (at least one required) | gcp-resource-inventory.json, gcp-resource-clusters.json, ai-workload-profile.json, billing-profile.json, .phase-status.json updated (outputs vary by input) | references/phases/discover/discover.md |
| Clarify | Discovery artifacts (gcp-resource-inventory.json, gcp-resource-clusters.json, ai-workload-profile.json, billing-profile.json — whichever exist) | preferences.json, .phase-status.json updated | references/phases/clarify/clarify.md |
| Design | preferences.json + discovery artifacts | aws-design.json (infra), aws-design-ai.json (AI), aws-design-billing.json (billing-only) | references/phases/design/design.md |
| Estimate | aws-design.json or aws-design-billing.json or aws-design-ai.json, preferences.json | estimation-infra.json or estimation-ai.json or estimation-billing.json, .phase-status.json updated | references/phases/estimate/estimate.md |
| Generate | estimation-infra.json or estimation-ai.json or estimation-billing.json, aws-design.json or aws-design-billing.json or aws-design-ai.json, preferences.json | generation-infra.json or generation-ai.json or generation-billing.json + terraform/, scripts/, ai-migration/, validation-report.json (when infra route active), MIGRATION_GUIDE.md, README.md, .phase-status.json updated | references/phases/generate/generate.md |
| Feedback | .phase-status.json (discover completed minimum), all existing migration artifacts | feedback.json, trace.json, .phase-status.json updated | references/phases/feedback/feedback.md |
awspricing (for cost estimation):
get_pricing, get_pricing_service_codes, get_pricing_service_attributes toolsreferences/shared/pricing-cache.md (cached 2026 rates, ±5-10% for infrastructure, ±15-25% for AI models). MCP is secondary — used only for services not found in the cache.gcp-to-aws/
├── SKILL.md ← You are here (orchestrator + state machine)
│
├── references/
│ ├── phases/
│ │ ├── discover/
│ │ │ ├── discover.md # Phase 1: Discover orchestrator
│ │ │ ├── discover-iac.md # Terraform/IaC discovery
│ │ │ ├── discover-app-code.md # App code discovery
│ │ │ └── discover-billing.md # Billing data discovery
│ │ ├── clarify/
│ │ │ ├── clarify.md # Phase 2: Clarify orchestrator
│ │ │ ├── clarify-global.md # Category A: Global/Strategic (Q1-Q7)
│ │ │ ├── clarify-compute.md # Categories B+C: Config Gaps + Compute (Q8-Q11)
│ │ │ ├── clarify-database.md # Category D: Database (Q12-Q13)
│ │ │ ├── clarify-ai.md # Category F: AI/Bedrock (Q14-Q22)
│ │ │ └── clarify-ai-only.md # Standalone AI-only migration flow
│ │ ├── design/
│ │ │ ├── design.md # Phase 3: Design orchestrator
│ │ │ ├── design-infra.md # Infrastructure design (IaC-based)
│ │ │ ├── design-ai.md # AI workload design (Bedrock)
│ │ │ └── design-billing.md # Billing-only design (fallback)
│ │ ├── estimate/
│ │ │ ├── estimate.md # Phase 4: Estimate orchestrator
│ │ │ ├── estimate-infra.md # Infrastructure cost analysis
│ │ │ ├── estimate-ai.md # AI workload cost analysis
│ │ │ └── estimate-billing.md # Billing-only cost analysis
│ │ ├── generate/
│ │ │ ├── generate.md # Phase 5: Generate orchestrator
│ │ │ ├── generate-infra.md # Infrastructure migration plan
│ │ │ ├── generate-ai.md # AI migration plan
│ │ │ ├── generate-billing.md # Billing-only migration plan
│ │ │ ├── generate-artifacts-infra.md # Terraform configurations
│ │ │ ├── generate-artifacts-scripts.md # Migration scripts
│ │ │ ├── generate-artifacts-ai.md # Provider adapter + test harness
│ │ │ ├── generate-artifacts-billing.md # Skeleton Terraform
│ │ │ └── generate-artifacts-docs.md # MIGRATION_GUIDE.md + README.md
│ │ └── feedback/
│ │ ├── feedback.md # Phase 6: Feedback orchestrator
│ │ └── feedback-trace.md # Anonymized trace builder
│ │
│ ├── design-refs/
│ │ ├── index.md # Lookup table: GCP type → design-ref file
│ │ ├── fast-path.md # Deterministic 1:1 mappings (Pass 1)
│ │ ├── compute.md # Compute mappings (Cloud Run, GCE, GKE, etc.)
│ │ ├── database.md # Database mappings (Cloud SQL, Spanner, etc.)
│ │ ├── storage.md # Storage mappings (GCS, Filestore, etc.)
│ │ ├── networking.md # Networking mappings (VPC, LB, DNS, etc.)
│ │ ├── messaging.md # Messaging mappings (Pub/Sub, etc.)
│ │ └── ai.md # AI mappings (Vertex AI → Bedrock)
│ │
│ ├── clustering/terraform/
│ │ ├── classification-rules.md # Primary/secondary classification
│ │ ├── clustering-algorithm.md # Cluster formation rules
│ │ ├── depth-calculation.md # Topological depth calculation
│ │ └── typed-edges-strategy.md # Edge type assignment
│ │
│ └── shared/
│ ├── schema-phase-status.md # .phase-status.json schema (canonical reference)
│ ├── schema-discover-iac.md # gcp-resource-inventory + clusters schemas (loaded by discover-iac.md)
│ ├── schema-discover-ai.md # ai-workload-profile schema (loaded by discover-app-code.md and discover-iac.md Step 7d)
│ ├── schema-discover-billing.md # billing-profile schema (loaded by discover-billing.md)
│ ├── schema-estimate-infra.md # estimation-infra.json schema (loaded by estimate-infra.md at write time)
│ ├── migration-complexity.md # Complexity tier definitions (small/medium/large) for timeline scaling
│ ├── pricing-cache.md # Cached AWS + source provider pricing (±5-25%, primary source)
│ └── bedrock-quotas.md # Bedrock TPM/RPM quota awareness, burndown rates, capacity planning
| Condition | Action |
|---|---|
No GCP sources found (no .tf, no app code, no billing data) | Stop. Output: "No GCP sources detected. Provide at least one source type (Terraform files, application code, or billing exports) and try again." |
.phase-status.json missing phase gate | Stop. Output: "Cannot enter Phase X: Phase Y-1 not completed. Start from Phase Y or resume Phase Y-1." |
| awspricing unavailable after 3 attempts | Display user warning about ±5-25% accuracy. Use pricing-cache.md. Add pricing_source: "cached_fallback" to the applicable estimation-*.json file. |
| User skips questions or says "use defaults for the rest" | Apply documented defaults for remaining questions in the current batch and all subsequent batches. Phase 2 completes either way. |
aws-design.json missing required clusters | Stop Phase 4. Output: "Re-run Phase 3 to generate missing cluster designs." |
us-east-1 (unless user specifies, or GCP region → AWS region mapping suggests otherwise)db.t4g.micro for databases, 0.5 CPU for Fargate)references/shared/migration-complexity.md for tier definitions.When invoked, the agent MUST follow this exact sequence:
Load phase status: Read .phase-status.json from .migration/*/.
Determine phase to execute:
current_phase exists: execute that phase.Read phase reference: Load the full reference file for the target phase.
Execute ALL steps in order: Follow every numbered step in the reference file. Do not skip, optimize, or deviate.
Validate outputs: Confirm all required output files exist with correct schema before proceeding.
Update phase status: Use the Phase Status Update Protocol (read-merge-write) in the same turn as the phase's final output message.
Feedback checkpoint: After a phase completes, check if feedback is due (see rules below). This runs before advancing to the next phase.
After Discover (if phases.feedback is "pending"): Output to user:
"Would you like to share quick feedback (5 optional questions + anonymized usage data) to help improve this tool? Your data never includes resource names, file paths, or account IDs.
[A] Send feedback now
[B] Wait until after the Estimate phase"
references/phases/feedback/feedback.md, execute it, then continue to Clarify."pending").After Estimate (if phases.feedback is "pending"): Output to user:
"Would you like to share quick feedback now? (5 optional questions + anonymized usage data)
[A] Yes, share feedback
[B] No thanks, continue to Generate"
references/phases/feedback/feedback.md, execute it, then continue to Generate.phases.feedback to "completed". Continue to Generate.After Generate: No feedback offer. If phases.feedback is still "pending", use the Phase Status Update Protocol to set it to "completed" (user had two chances and chose to defer/skip).
Display summary: Show user what was accomplished, highlight next phase, or confirm migration completion.
Critical constraint: Agent must strictly adhere to the reference file's workflow. If unable to complete a step, stop and report the exact step that failed.
User can invoke the skill again to resume from current_phase (or deterministic ordered evaluation when current_phase is absent).
v1.0 includes:
npx claudepluginhub awslabs/startups --plugin migration-to-awsProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Searches MemPalace before answering questions about past work, people, projects, or prior decisions. Returns verbatim stored content instead of guessing from model memory.