oc-migration-ops

Topics in the source

• Migration Ops
• /oc-migrate — Command Reference
• How This Skill Fits the Pipeline
• Migration Types
• Auto-Detection
• Phase 0: Assessment (/oc-migrate assess)
• Step 1: Gather Current State
• Step 2: Define Target State

On first invocation, read references/orchestrator.md and follow its welcome protocol. The "change the engine mid-flight" skill. Fills the gap between oc-reverse-spec ("what I have") and oc-app-architect ("what I want") when the answer is "transform one into the other" — without downtime, without data loss, and with a rollback at every step. This is inherently multi-session work. A database migration plan might span 3–4 conversations. Checkpoint protocol adoption is critical from day one. -- Migration-ops sits between "what exists" and "what should exist" — it's the transformation engine. It does NOT build new features (oc-app-architect) or document existing code (oc-reverse-spec). It transforms running systems from state A to state B. -- Every migration request is classified into one of these types. The type determines which reference playbook to load and which verification strategy to use. | Type | Examples | Risk | Key Concern | |---|---|---|---| | Database | D1 → Postgres, schema overhaul, ORM swap, warehouse engine moves (BigQuery → Snowflake), dbt-model/schema overhauls | HIGH | Data integrity, zero data loss | | Framework | Hono v3→v4, React 18→19, Next.js pages→app router |

This is an excerpt. Refer to the complete source and its current requirements.