/arn-infra-migrate

name: arn-infra-migrate
description: >-
  This skill should be used when the user says "migrate infrastructure", "arn infra migrate",
  "infra migrate", "move to AWS", "move to GCP", "move to Azure",
  "switch providers", "change cloud provider", "graduate from PaaS", "move from heroku",
  "move from fly.io", "consolidate providers", "infrastructure migration",
  "provider migration", "partial migration",
  "move database", "move services", "arn-infra-migrate", "infrastructure move",
  "cloud migration", or wants to migrate infrastructure between providers,
  graduate from PaaS to IaC, consolidate providers, or partially move
  specific services.
version: 1.0.0

Arness Infra Migrate

Handle infrastructure migrations as tracked projects with four scenarios: PaaS-to-IaC graduation, provider-to-provider migration, provider consolidation, and partial migration. Creates a parent issue with migration overview and decomposes into individual task issues with dependencies, verification criteria, and rollback procedures.

This skill manages the full migration lifecycle: planning, IaC generation for the target, incremental deployment to staging, verification, cutover, and cleanup. It warns other skills about in-progress migrations to prevent conflicting changes.

Prerequisites

Read `## Arness` from the project's CLAUDE.md. If no `## Arness` section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run `/arn-infra-wizard` to get started — it will set everything up automatically." Do not proceed without it.

Check the **Deferred** field. If `Deferred: yes`, inform the user: "Infrastructure is in deferred mode. Migration is not available until infrastructure is fully configured. Run `/arn-infra-assess` to un-defer." Stop.

Extract:

• **Experience level** -- derived from user profile. Read `~/.arness/user-profile.yaml` (or `.claude/arness-profile.local.md` if it exists — project override takes precedence). Apply the experience derivation mapping from `${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md`. If no profile exists, check for legacy `Experience level` in `## Arness` as fallback.
• **Providers** -- current cloud providers
• **Providers config** -- path to `providers.md`
• **Default IaC tool** -- the target IaC tool for graduation migrations
• **Environments** -- environment list for staged migration
• **Environments config** -- path to `environments.md`
• **Issue tracker** -- for creating migration project issues (github, jira, none)
• **Platform** -- for issue management
• **Infra plans directory** -- for migration plan storage (default: `.arness/infra-plans`)
• **Jira site** and **Jira project** -- if Issue tracker is jira

---

Workflow

Step 1: Detect Migration Scenario

Ask (using `AskUserQuestion`):

**"What kind of migration are you planning?"**

Options: 1. **Graduate** -- Move from PaaS/platform-native configs to infrastructure-as-code (e.g., `fly.toml` to OpenTofu, Heroku to AWS) 2. **Provider migration** -- Move services from one cloud provider to another (e.g., AWS to GCP, Fly.io to AWS) 3. **Consolidation** -- Reduce the number of providers (e.g., 3 providers to 1-2) 4. **Partial migration** -- Move specific services while keeping others in place (e.g., move just the database to a managed service)

> Read the local override or plugin default for `migration-scenarios.md`.

---

Step 2: Check for Active Migrations

Read the provider configuration:

Read <providers-config-path>

Check if any providers have `Migration: <id> (in progress)`:

**If active migration detected:** Warn: "There is an active migration in progress: [migration-id] affecting [providers/services]. Starting a new migration that overlaps with these services could cause conflicts."

Ask (using `AskUserQuestion`):

**"How would you like to handle the active migration conflict?"**

Options: 1. **Continue anyway** -- Start a new migration (I'll flag potential conflicts) 2. **Wait** -- Complete the current migration first 3. **Cancel current** -- Roll back the current migration and start this one

**If no active migrations:** Continue to Step 3.

---

Step 3: Assess Source and Target

Based on the chosen scenario:

**Graduate:**

• Read current PaaS configuration (fly.toml, railway.json, render.yaml, vercel.json, etc.)
• Identify deployed services, databases, and networking
• Determine target provider and IaC tool from `## Arness` config
• Map PaaS features to IaC equivalents (auto-scaling, health checks, SSL, custom domains)

**Provider migration:**

• Read source provider's IaC configs and deployed resources
• Ask for target provider: "Which provider do you want to migrate to?"
• Compare source resources with target provider equivalents
• Identify services that may not have direct equivalents

**Consolidation:**

• List all configured providers with their scopes
• Ask which providers to consolidate into: "You currently use [list]. Which provider(s) do you want to consolidate into?"
• Identify the scope of each provider being removed
• Map services to the consolidation target

**Partial migration:**

• Ask which specific services to migrate: "Which services do you want to move?"
• Identify the target provider/service for each
• Check dependencies between migrating and non-migrating services

---

Step 4: Create Migration Project

4.1: Generate Migration Plan

Invoke the `arn-infra-specialist` agent via the Task tool, passing the model from `.arness/agent-models/infra.md` as the `model` parameter (see `plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md` "Dispatch convention" for fallback). Context:

--- MIGRATION CONTEXT --- Scenario: [graduate | provider-migration | consolidation | partial] Source: [source provider(s) and current configuration] Target: [target provider(s) and IaC tool] Services affected: [list of services being migrated] Environments: [e