Migrations between data warehouses are some of the most painful work in enterprise engineering. The mechanical parts (rewriting operators, translating dialect quirks) take weeks. The judgment parts (knowing what to test, what to refactor, what to leave alone) take a senior engineer's time that's better spent elsewhere.

The dag-migration-compare skill in InsightWorker takes the mechanical parts off the table.

Step 1 — scaffold an app

InsightWorker creates an app folder under .insightworker/apps/ with scope, plan, tasks, config.yaml, and the input/ folder where you drop your source artifacts.

Step 2 — drop in source artifacts

Copy your DAG code, variables.json, stored procedures, and table DDLs into input/. The app's tasks.md is auto-populated based on what you supplied.

Step 3 — run the app

The agent executes one task at a time. For each operator it can't auto-translate, it asks. For each stored procedure where the dialect translation is ambiguous, it flags. The output/ folder fills up with translated artifacts and a change_report.md.

What you actually get

• DAG code with operators rewritten (S3 → OCI Object Storage, Redshift → Oracle, etc).
• variables_updated.json with connection strings and IDs swapped to OCI equivalents.
• Stored procedures translated to Oracle PL/SQL with comments where dialect choices were made.
• DDLs rewritten with Oracle types and tablespaces.
• change_report.md — every modification listed line-by-line for code review.

What it doesn't do

It doesn't make architecture decisions for you. If your Redshift design assumed sort keys, the agent flags that and asks how you want to map it on Oracle. If your DAG calls a custom Python operator nobody documented, it asks. The senior engineer is still in the loop — they're just not retyping operator imports.