Getting ChatGPT to Write Accurate Database Migration Rollback Scripts

You ran a forward migration in production, something broke, and now you need to roll back — fast. If you used ChatGPT to write that rollback script without the right guardrails, there's a real chance it handed you a script that quietly destroys data or fails outright on a column that no longer exists.

Rollback scripts sit in a uniquely dangerous corner of database work. Unlike a forward migration, a rollback script must reverse a change that has already touched live data — and ChatGPT's default output rarely accounts for that asymmetry.

What You'll Learn

• Why ChatGPT produces structurally plausible but operationally risky rollback scripts by default
• How to build a prompt template that forces the model to reason about destructive changes
• Framework-specific prompt patterns for Django, Alembic, and Flyway
• A practical checklist for verifying AI-generated rollback output before you touch production
• The common pitfalls that catch teams off guard even after careful prompting

Prerequisites

This guide assumes you work with a relational database (PostgreSQL, MySQL, or SQLite) and use at least one migration framework in your stack. Code examples reference Django migrations, SQLAlchemy/Alembic, and Flyway, but the prompting principles apply to any toolchain.

Why Rollback Scripts Are Harder Than Forward Migrations

A forward migration has one job: get the schema from state A to state B. A rollback script must answer a more nuanced question: given that state B already has real data in it, how do we return to state A without losing anything we can't afford to lose?

Several operations are not safely reversible once data exists:

• Dropping a column that contained data — the data is gone unless you backed it up first
• Narrowing a column type (e.g., TEXT → VARCHAR(50)) — values that exceed the new limit cause errors
• Merging two columns into one — splitting them back requires logic you haven't written
• Renaming a column and then writing new data to it — the old name is a dead-end reference

ChatGPT doesn't know which state your database is actually in when it generates a rollback. It reasons from the migration code you paste in, not from a live schema snapshot. That gap is where mistakes happen.

Why ChatGPT Gets Rollbacks Wrong by Default

Give ChatGPT a forward migration and ask for the rollback, and you'll usually get something that looks reasonable. The problem is that "looks reasonable" is doing a lot of heavy lifting.

The model has learned from a huge body of migration examples, so it knows the syntax. But it defaults to a few dangerous assumptions:

• It assumes the rollback runs immediately after the forward migration, on an empty or test dataset
• It treats column drops as reversible by simply re-adding the column (without the data)
• It ignores application-level code that may have already written data in the new schema shape
• It doesn't account for foreign key constraints that change during the forward migration

The model also tends to mirror the forward migration one-for-one. If you added a column, it drops it. If you created a table, it drops the table. This works in development. In production, it can silently delete rows that have been inserted since the migration ran.

This is a close cousin of the hallucination problem you see in other generated infrastructure code — similar to how the model confidently produces Kubernetes manifests with stale API versions that pass a visual inspection but fail at apply time.

Structuring Your Prompt for Safe Rollback Output

The fix is to give ChatGPT the context it's missing and explicitly constrain the output. Here's a prompt template that works well in practice:

You are a database engineer writing a safe rollback migration.

Context:
- Database: PostgreSQL 15
- Migration framework: Alembic (SQLAlchemy)
- The forward migration ran in production approximately 2 hours ago
- Live data has been written to the new schema since the migration ran

Forward migration (paste the full file):
[PASTE FORWARD MIGRATION HERE]

Your task:
1. Identify every operation in the forward migration that is NOT safely reversible once live data exists. List them explicitly.
2. For each irreversible operation, propose a safe rollback strategy (e.g., archive data before dropping a column, cast data before narrowing a type).
3. Write the full rollback migration file, including all safety checks.
4. Add comments in the code that explain WHY each step is written the way it is.
5. Flag any assumption you are making about the current state of the database.

Do not produce a rollback that could silently discard data without a preceding archive step.

Breaking down what this prompt does: it establishes the production context (database version, framework, time elapsed since migration), forces the model to audit the forward migration before writing a single line of rollback code, and explicitly prohibits silent data loss. That prohibition matters — without it, the model defaults to the shortest valid answer.

Adding a Schema Snapshot

If you can provide the current \d tablename output from psql (or equivalent), paste it into the prompt after the forward migration. This gives the model a live reference point rather than letting it infer the schema from the migration file alone. Even a partial schema snapshot dramatically reduces hallucination risk.

Current schema state (from \d orders in production):
[PASTE \d OUTPUT HERE]

Note: rows have been inserted into the orders table since the migration ran.
The rollback must preserve all rows.

Handling Destructive Changes: The Hard Conversations With ChatGPT

Some operations don't have a clean rollback path. You need to push ChatGPT to acknowledge this and propose a real strategy, not a polite fiction.

Dropped Columns

If your forward migration dropped a column, the rollback can re-add it — but the data is gone. The correct rollback strategy depends on whether you archived the data before dropping it. If you didn't, the column comes back empty.

Prompt addition to force the right output:

The forward migration drops the column `legacy_status` from the `orders` table.
Assume NO archive was created before the drop.
In the rollback, re-add the column with a nullable type and insert a comment explaining that historical values are unrecoverable. Do not silently add it as NOT NULL.

Renamed Columns

A rename in the forward migration is reversible at the schema level, but if application code has written data to the new column name, the rename back will not recover values written between the migration and the rollback. Make this explicit:

The forward migration renames `user_name` to `display_name`.
New data has been written to `display_name` since the migration ran.
The rollback should rename `display_name` back to `user_name`, but add a comment that values written after the forward migration will appear under the old column name and may be misaligned with application expectations.

Type Changes

Type narrowing is the most likely to cause a rollback failure at runtime. Ask ChatGPT to generate the rollback with an explicit guard:

The forward migration changes `description` from TEXT to VARCHAR(255).
The rollback must change it back to TEXT.
Before the ALTER, add a check that reports how many rows have a description longer than 255 characters, so the operator can decide whether to proceed.

Framework-Specific Prompting: Django, Alembic, and Flyway

Django

Django's migration framework auto-generates rollbacks through the operations list, but custom RunSQL or RunPython operations require you to provide a reverse_sql or reverse callable. ChatGPT often skips these or fills them with migrations.RunSQL.noop, which means the rollback does nothing.

I'm writing a Django migration that uses RunSQL to backfill a new column.
Write both the forward `sql` and the `reverse_sql` for the RunSQL operation.
The reverse should undo the backfill safely without dropping rows.
Do not use RunSQL.noop as the reverse.

Alembic

Alembic uses upgrade() and downgrade() functions. ChatGPT usually populates both, but the downgrade() body is often a naive inverse without data-safety logic. Your prompt should require parity between the two:

Write an Alembic migration with both upgrade() and downgrade().
For every operation in upgrade(), the downgrade() must either:
a) safely reverse it with data preserved, or
b) explicitly raise NotImplementedError with a message explaining why the operation cannot be safely reversed and what manual steps are required instead.

Flyway

Flyway's undo migrations (U__ prefix) are a paid feature in some editions. If you're on the community edition, you're writing plain SQL undo scripts manually. Be explicit about this in your prompt:

I'm using Flyway Community Edition. There is no automatic undo support.
Write a plain SQL rollback script that I will run manually via psql.
The script should wrap all operations in a single transaction and include a ROLLBACK statement at the top so I can test the logic before committing.

This transaction-wrapping pattern is valuable regardless of framework — it's the same discipline that prevents half-applied rollbacks from leaving your schema in a worse state than before.

Verifying ChatGPT's Output Before You Trust It

No matter how carefully you prompt, treat the output as a first draft that requires review. Here's a practical verification checklist:

1. Run it against a staging database first. Restore a recent production backup to staging, apply the forward migration, write some test data, then run the rollback. Verify row counts and spot-check data integrity.
2. Check every DROP and ALTER. Read each destructive operation and ask: if new data exists in this column or table since the forward migration ran, does this operation handle it correctly?
3. Confirm constraint handling. Foreign keys, unique constraints, and check constraints may have been added in the forward migration. The rollback needs to drop them in the right order before it touches the columns they reference.
4. Inspect transaction boundaries. The rollback should be wrapped in a transaction. If ChatGPT omitted it, add it. A partial rollback is often worse than no rollback.
5. Ask ChatGPT to review its own output. Paste the generated script back and ask: "What could go wrong when this script runs against a production database where data has been written since the forward migration? List every risk." This secondary audit often surfaces issues the first pass missed.

The self-review step in particular mirrors the technique that catches problems in other AI-generated infrastructure code — it's the same approach that helps when you're verifying AI-generated CI/CD pipeline configs for broken steps.

Common Pitfalls in AI-Generated Rollback Scripts

Assuming an Empty Table

ChatGPT's training data skews toward tutorials and test environments where tables are often empty. When it writes a rollback that drops and recreates a table, it rarely includes logic to preserve existing rows. Always state explicitly in your prompt that the table contains live data.

Wrong Operation Order

Foreign key constraints require child tables to be modified before parent tables in a rollback (the reverse of the forward migration order). ChatGPT sometimes mirrors the forward order, which causes constraint violations. Ask it to explicitly list the dependency order before writing the script.

Missing Index Rollbacks

If your forward migration created an index concurrently (CREATE INDEX CONCURRENTLY), the rollback should drop it concurrently too. ChatGPT often drops the CONCURRENTLY keyword on the rollback, which takes a full table lock. Include this in your prompt requirements.

Ignoring Sequences and Defaults

Column defaults and sequences (auto-increment IDs) modified in the forward migration need to be reset in the rollback. These are easy to overlook and harder to spot in code review. Specifically ask ChatGPT to audit for sequence and default changes.

Silent Failures in Python Callbacks

In Django's RunPython and Alembic's Python-based operations, ChatGPT sometimes writes a reverse callable that returns without doing anything. Always read the reverse function body, not just the signature. This is a close relative of the silent edge-case failures you can encounter with AI-generated webhook handlers.

It's also worth cross-referencing the output against any environment-specific configuration. Missed or wrong variables in the script context cause exactly the kind of hard-to-debug failures discussed in getting ChatGPT to write accurate environment variable configs.

Wrapping Up: Next Steps

ChatGPT can save you significant time on rollback scripts, but it needs you to supply the context it cannot infer on its own: the live schema state, the time since migration, and the data that's been written in between. Without that, it defaults to safe-looking syntax that doesn't account for production reality.

Here are five concrete actions to take right now:

1. Add a rollback prompt template to your team's runbook. Standardize the context fields (database version, framework, time elapsed, live data flag) so every engineer uses the same baseline.
2. Require staging verification as a step in your migration review process. No rollback script ships to production without a staging run against a recent data restore.
3. Prompt ChatGPT for a risk audit after generating the script. The two-pass approach — generate then critique — catches issues the first pass misses.
4. Build a short pre-rollback checklist into your deployment tooling. Row count checks, constraint validation, and index verification should run automatically before the rollback executes.
5. Treat irreversible operations as blockers in forward migrations. If you can't write a safe rollback, that's a signal to reconsider the forward migration design — use expand-contract patterns instead of destructive single-step changes.