get_migration

Get the current status and phase breakdown of a migration. The response includes all migration phases (Discovery, DB Migration, Data Import, Edge Functions, Storage Buckets, Auth Config, Backend Switchover, Preview & Verify, Continuous Sync, Download, Follow-ups) with their individual statuses, plus sourceType (LOVABLE_SUPABASE / BOLT_SUPABASE / FIREBASE / BASE44_SUPABASE / BASE44_NATIVE), targetType (SUPABASE_CLOUD / SUPABASE_SELF_HOSTED), and packageAvailable (true once the downloadable zip is ready — fetch via download_package).

Self-navigating: the response includes a pendingAction field that tells you the next action to take. New pre-flight states are explicit: REVIEW_TARGET_CONFLICTS → present targetConflictReport, then either call clean_migration_target after destructive confirmation or call confirm_migration only after the user explicitly declines cleanup; WAIT_FOR_TARGET_CLEANUP → poll; RETRY_TARGET_CLEANUP → call retry_migration_job (never skip cleanup); CHOOSE_MIGRATION_STRATEGY → present preFlightGate.actions and consequences, then call confirm_migration with the selected gateChoice. RESUME → the migration is paused and waiting on a person: tell the user what it is waiting for and call resume_migration once they agree (never resume a migration they paused without asking). PROVIDE_BASE44_SECRETS → this gate takes the values of the customer's own third-party credentials, so it is resolved in a browser and NOT by a tool: endpoint is null, url is the migration page, and detail is written to be shown to the user verbatim. Give them the URL, keep polling, and do not ask for the secret values in the conversation — no tool accepts them and the API refuses them over this connection. Other types: CONFIRM, RETRY_OR_SKIP, RESOLVE_SCHEMA_GAP, CHOOSE_BACKEND_SWITCHOVER, CHOOSE_DATA_IMPORT_METHOD, CHOOSE_FRONTEND_DEPLOY, COMPLETE_MANUAL_JOB. When pendingAction is null, poll only while the status is flowing.

The response exposes preFlightGate with backend-authored labels, consequences, export files, and the accepted choice IDs. It also exposes targetConflictReport with conflicting objects, cleanup scopes, confirmationProjectRef, and endpoint paths. Present these fields instead of inventing or defaulting a choice.

The response also includes failureBanner with categorised error info (category, title, body, severity, actionable, followupNote, retryable) when a job has a categorised failure. Use this to present richer error feedback. When retryable=false, prefer skip_migration_job or an AI-assisted fix over repeating deterministic SQL that will fail again — but check the job's skipGuard first, because a guarded job breaks the migration if skipped and needs the user's explicit approval; retryable=null means the cause may be environmental.

The support field reports whether this migration is SELF_SERVICE, SUPPORTED, or SUPPORT_WINDOW_ENDED, together with available human-support contact details. consultationUrl is returned only for SUPPORTED migrations and books the optional consultation already included in that migration's existing support entitlement; it is never a purchase, checkout, or upgrade route. When support is active, use those routes for human escalation instead of implying the MCP itself provides human support. Purchase and operator-grant actions are intentionally unavailable through MCP.

Polling Phase 7 (Backend Switchover): the response also includes previewDeployment (null until Phase 7 provisions one) with its own independent status. Important: the migration itself can be marked COMPLETED while previewDeployment.status is still IN_PROGRESS — the preview Terraform applies in the background. When babysitting a migration toward 'live preview ready', also poll previewDeployment.status until it reaches COMPLETED. Treat anything other than COMPLETED/FAILED/ABORTED/DESTROYED/CLEANED_UP as 'still progressing'. Use previewDeployment.createdAt to compute elapsed time so you can give the user a sense of progress without spamming this endpoint — once-every-5s is plenty.