Exodus Migration API Stage Map
This page maps each migration stage to the API calls used by operators, dashboards, and supervised agents. It covers the raw migration API used by heterogeneous migration validation runs and the lower-level service surface behind guided workflows.
Execution starts with POST /api/v1/migrations/{migrationId}/migrate. Completion uses POST /api/v1/migrations/{migrationId}/complete. Preflight, read, planning, and readiness endpoints are separate checks; they are not alternate names for the same mutation.
End-To-End Stage Flow
Stage Gates
API Responsibility Table
| Stage | Read APIs | Mutation APIs | Notes |
|---|---|---|---|
| Create | GET /api/v1/migrations, GET /api/v1/migrations/{migrationId} | POST /api/v1/migrations, PATCH /api/v1/migrations/{migrationId}, DELETE /api/v1/migrations/{migrationId} | Heterogeneous mapping is intentionally not supplied in the constructor. |
| Attach | GET /api/v1/migrations/{migrationId} | POST /api/v1/migrations/{migrationId}/api/{apiId}, POST /api/v1/migrations/{migrationId}/interlay/{interlayId} | Wires source, target, and gateway ownership. |
| Analysis | GET /analysis/info, GET /analysis/history, GET /analysis/timeseries | POST /analysis/start, POST /analysis/stop, PATCH /analysis/config | Measures source behavior and workload shape. |
| Compatibility | GET /compatibility/info | POST /compatibility/start, POST /compatibility/resolve, POST /compatibility/unresolve | Blocks unsupported endpoint, policy, and feature combinations. |
| Query seeding | GET /planning/query-seeding/status, GET /planning/query-seeding/queries, GET /planning/query-seeding/queries/{queryKey} | POST /planning/query-seeding/start | Observes live traffic and stores normalized query shapes. |
| Schema mapping | GET /planning/schema-mapping, GET /planning/schema-mapping/missing, GET /planning/target-schema-plan | POST /planning/run, PATCH /planning/schema-mapping | Discovers source fields, exposes missing mappings, and previews target schema/index plans. |
| Request mapping | GET /planning/request-mapping, GET /planning/request-mapping/missing, GET /planning/request-mapping/query/{queryKey} | PATCH /planning/request-mapping, PATCH /planning/request-mapping/query/{queryKey}, PATCH /planning/request-mapping/queries | Maps request templates and response templates for live traffic. |
| Planning gate | POST /planning/validate | POST /planning/finalize | Validate returns blockers. Finalize moves the plan to ready only when blockers are gone. |
| Execution gate | POST /execution/preflight, GET /migrations/{migrationId}, GET /migrations/{migrationId}/live_metrics | POST /migrate, POST /pause, POST /resume, POST /cancel | /migrate is the canonical start command. |
| Runtime strategy | GET /live-write-mode, GET /live-write-mode/readiness, GET /write-log/status, GET /write-log/gaps, GET /runtime-query-misses | PATCH /live-write-mode, PATCH /traffic, PATCH /toggle | LogAndReplay must prove replay readiness before switching to strict dual-write or target reads. |
| Cutover | POST /cutover/preflight | POST /complete | /complete is the canonical completion command. |
No Duplicate Command Routes
The migration API should have narrow read, validation, preflight, and resource-update endpoints, but should not add duplicate command routes for the same mutation. Keep the public command names stable:
- start execution with
POST /api/v1/migrations/{migrationId}/migrate; - complete with
POST /api/v1/migrations/{migrationId}/complete; - use preflight endpoints to inspect blockers before mutating state.
Related Docs
Last updated: July 5, 2026