Do not let an AI-written migration reach production until a named reviewer has checked its data effects, recovery evidence and execution target. Approval of the SQL is not automatically approval to run it against a live database.
Define what must survive
Practical editorial advice: begin with invariants, not the generated migration's explanation. Specify which records, relationships and application behaviours must remain intact.
For an Indian order-management application, these might include preserving order identifiers, keeping rupee amounts unchanged and retaining the relationship between an order and its line items. Define the permitted change narrowly enough that an unrelated schema alteration becomes visible.
Read the migration itself. Flag destructive statements, bulk updates, new constraints, type conversions and defaults that could silently reinterpret existing values. A migration can be harmful without containing an obvious deletion.
Require a migration gate record
Complete this record using evidence rather than ticks alone:
- Target: intended environment and database identifier, without credentials.
- Scope: objects changed, estimated affected records and permitted data transformations.
- Destruction: every deletion, drop or irreversible conversion, with an owner-approved reason.
- Backup evidence: when the recovery copy was created and who verified its relevance.
- Restore evidence: a rehearsal result showing what can actually be recovered.
- Reversibility: rollback steps, forward-repair steps and changes that cannot be undone directly.
- Operations: acceptable interruption, observation window and responsible reviewer.
- Execution: exact reviewed artifact and the person authorised to approve its run.
An untested recovery assumption should remain an open gate. Do not label a reverse schema change as full recovery if it cannot reconstruct lost values.
Hypothetical amount conversion
Suppose a migration converts an amount field into integer paise. Use synthetic inputs ₹0.00, ₹19.99 and ₹1,250.50, with expected outputs 0, 1999 and 125050. Include a missing value and a deliberately malformed value with explicitly agreed outcomes.
Evaluate record counts, totals and individual conversions in a disposable environment. Check what happens if execution stops midway. These are illustrative review requirements, not a claimed test result.
Stop if rounding rules are unresolved or recovery cannot preserve the original values. Next, revise the transformation and repeat the rehearsal before requesting production approval.
Separate the run permission
Cursor's Run Modes govern how agent tool calls run and when approval is requested. Auto-review, Allowlist and Run Everything differ in approval, sandboxing and classifier behaviour. Those distinctions make execution policy relevant; they do not certify migration correctness.
When evaluating tool access, use the coding catalog to check access format and saved terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or production readiness.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Cursor Run Modes supports the execution-policy distinction. Backup gates, SQL review criteria and the hypothetical conversion are editorial advice, not documented Cursor database safeguards.