Graviton Migration

This skill takes a workload from x86 (amd64) to AWS Graviton (arm64) end to end. It sets up a third-party Arm migration MCP server that exposes arm64-readiness scanning tools, then wraps a migration workflow around them: scan the code and containers, plan node capacity, cut over the nodes, validate, and make the CI pipeline build multi-arch images so the change sticks.

The value here is execution. Other skills in this catalog treat Graviton as a cost lever — they tell you how much you would save or whether you should adopt it. This skill does the actual move.

Readiness scanning uses three co-equal input layers

The pre-migration scan is not a single MCP call. It draws on three co-equal input layers, and no one of them is "the spine":

1. Layer 1 — Arm migration MCP (this is layer 1 of 3, and the one with known blind spots). The MCP's source scanner and image-arch tools are fast and broad, but they miss things: transitively pulled native wheels/JARs, vendored prebuilt binaries, and dependencies resolved at build time rather than declared in source.
2. Layer 2 — dependency-manifest parse (MANDATORY). Independently parse the lockfiles/manifests (requirements.txt/poetry.lock, go.mod, package-lock.json, pom.xml/Gradle) to catch arch-specific packages the MCP scanner does not flag.
3. Layer 3 — binary/JAR ELF scan (MANDATORY). Inspect shipped binaries, .so files, and JARs with bundled native libs (ELF machine type) to confirm an arm64 build exists — the ground truth the other two layers only approximate.

Layers 2 and 3 are not optional add-ons. A "clean" MCP result alone is not a readiness verdict; reconcile all three layers before calling a workload portable. references/scanner-workflow.md and references/dependency-knowledge.md carry the per-layer detail.

When NOT to Use This Skill