Source: [AI-written database migrations: test the application-version overlap — Skills for Business](<https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/>)

[← All articles](https://skillsforbusiness.ai/blog/)

Development · Guide

# AI-written database migrations: test the application-version overlap

A migration can run successfully and still break an older application. Review readers, writers, data authority and rollback before accepting AI-generated changes.

[Skills for Business](https://skillsforbusiness.ai/blog/editorial/)1 November 20267 min read

On this page

1.  [Separate translation correctness from deployment compatibility](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#separate-translation-correctness-from-deployment-compatibility)
2.  [Inventory consumers before approving a rename](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#inventory-consumers-before-approving-a-rename)
3.  [Two columns need an explicit authority rule](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#two-columns-need-an-explicit-authority-rule)
4.  [Rehearse the sequence that could invalidate the data](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#rehearse-the-sequence-that-could-invalidate-the-data)
5.  [Check operational cost on the real engine](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#check-operational-cost-on-the-real-engine)
6.  [Make rollback a supported state](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#make-rollback-a-supported-state)
7.  [Sources](https://skillsforbusiness.ai/blog/ai-database-migrations-application-version-overlap/#sources)

What to take away

-   Test the application versions and background jobs that will share the database during deployment.
-   When old and new fields coexist, define which is authoritative and how every writer keeps the transition consistent.
-   Treat operational rehearsal and rollback compatibility as separate evidence from SQL validity or a successful empty-database migration.

Before accepting an AI-written database migration, check the period when different application versions will use the changed database. A script that runs successfully can still break an older worker, leave a new field stale or make the promised rollback unusable. Test that transition explicitly, alongside the final schema.

For a business application, the consequences can be ordinary but consequential: an order note disappears from a dispatch screen, an overnight export fails or a deployment rollback restores code that can no longer read its data. Reviewing the generated SQL alone will not answer all of those questions.

Our editorial recommendation is to ask the coding assistant for a staged compatibility plan, then verify its assumptions against the actual consumers and database engine. The example below is hypothetical. It is a review method, not a production-tested migration recipe or a claim that a named model has been independently evaluated.

## Separate translation correctness from deployment compatibility

The 2025 [Horizon demonstration paper](https://www.vldb.org/pvldb/vol18/p5259-emani.pdf), authored by Microsoft researchers and engineers, describes checks for LLM-assisted SQL migration between database dialects. Its workflow combines existing tools, generated candidates and validation feedback. The checks go beyond parsing to address issues such as unintended edits and functional behavior.

That is vendor-authored research about a particular system and task. It does not validate this article’s proposed rollout or establish that an arbitrary assistant can safely change a live application’s schema. Moving SQL between database products and evolving a schema under running clients are different problems.

For the second problem, Danilo Sato’s 2014 practitioner article [Parallel Change](https://martinfowler.com/bliki/ParallelChange.html) describes expanding an interface, migrating its consumers and removing the old interface afterward. It explicitly discusses database refactoring. The architectural principle predates today’s coding assistants: consumers need a supported transition, not just a changed definition.

The practical question for a reviewer is therefore broader than “Does this migration execute?” Ask: **Which readers and writers can run at each stage, and what data will they observe?**

## Inventory consumers before approving a rename

Imagine a fictional order-management system. The team wants to rename a text field from `shipping_note` to `delivery_note` without changing its meaning. The web application is deployed gradually, and a background dispatch worker may remain on an older release during the rollout.

An assistant could propose renaming the column and updating the current application’s queries in one change. A fresh test database and the newest code might work together. The older worker, however, still requests the original field. The successful local result would not demonstrate compatibility with that worker.

Before choosing a migration, list the consumers: web instances, scheduled jobs, queue workers, reports, exports and any external integration with direct database access. Record which versions may be active and which version an operator would restore after a failure. A repository search is useful, but cannot establish that an independently deployed reporting tool has stopped using a column.

Decide whether a staged rollout is actually required. A planned maintenance window with all relevant clients stopped has different constraints. Do not add temporary compatibility structures merely because a pattern sounds sophisticated; equally, do not assume an atomic application-and-database switch when deployment practice does not provide one.

## Two columns need an explicit authority rule

One possible staged approach retains the original column and adds the replacement. That avoids immediately removing the old name, but it introduces another question: which value is the truth while both exist?

Suppose a backfill copies the original notes into the replacement field. An older dispatch tool subsequently changes only `shipping_note`. A new reader that trusts the previously populated `delivery_note` now sees stale information. Falling back to the old field only when the new field is empty does not resolve this case: the new field contains an outdated value.

For this fictional rename, a team could keep the original field authoritative while legacy writers remain. A bridge release would continue reading that field and maintain both copies on its own writes. Updating both copies should be one atomic operation in this same-database example. The assistant must not treat two independent successful writes as equivalent.

Before switching authority, retire or pause the legacy writers, reconcile the data and establish that every remaining writer maintains the intended relationship. Reconciliation must not overwrite a newer value with a stale application-side snapshot. Its implementation needs concurrency review on the actual engine.

The table below is a proposed set of gates for this example, not an executable deployment plan.

| Transition point | What must be established before proceeding |
| --- | --- |
| Add the replacement field | Existing clients still read and write successfully against the expanded schema. |
| Run the bridge alongside legacy clients | The old field remains authoritative; bridge writes maintain both copies atomically. |
| Prepare the authority switch | Legacy writers are stopped or upgraded; reconciliation completes without losing concurrent updates. |
| Read the replacement field | Remaining writers maintain both copies during the agreed rollback window; the rollback target preserves that contract. |
| Remove the original field | No supported reader, writer or rollback release still depends on it. |

This is not the only implementation. A database-side compatibility mechanism or a stable access layer may fit a system better. The owner must choose the mechanism and verify its behavior rather than accepting “dual write” as a complete design.

## Rehearse the sequence that could invalidate the data

Ask the assistant to propose tests from the transition rules, then review their expected results independently. For the fictional notes field, the important cases include:

-   An old client reads and updates a populated record after the expanded schema is installed.
-   A legacy write occurs after the initial backfill; the application still displays the current authoritative note.
-   A bridge update is interrupted; the transaction leaves both copies consistent or neither update committed.
-   Reconciliation runs while supported writers remain active, without replacing newer notes with older snapshots.
-   A deployment returns to the designated bridge release after the read switch, preserving the supported data contract.
-   A remaining scheduled export prevents removal of the old column until its dependency is resolved.

Use representative existing records, including empty notes, long text and values changed during the rehearsal. Record the exact sequence, observed values and application versions. These are proposed acceptance cases; no migration execution is claimed in this article.

A final-state test using only the newest code cannot substitute for these checks. This extends the same discipline as [reviewing AI-generated regression tests](https://skillsforbusiness.ai/blog/ai-generated-tests-intended-regression/): the expected behavior needs an independent basis, and the test must exercise the failure you intend to prevent.

## Check operational cost on the real engine

Compatibility does not establish that a schema change will finish within an acceptable service window. Inspect the exact database product, version, table size, indexes, constraints and workload.

For example, the [PostgreSQL 18 `ALTER TABLE` documentation](https://www.postgresql.org/docs/18/sql-altertable.html) states that lock requirements vary by subcommand and that an `ACCESS EXCLUSIVE` lock is acquired unless otherwise noted. Combining subcommands takes the strictest required lock. A generated migration labeled “additive” is therefore not evidence that it has no blocking impact.

Have the responsible engineer review the statements against the versioned documentation and rehearse on an appropriately sized, approved environment. Inspect lock waits, transaction duration, backfill progress and the effect on the application’s important operations. Set stopping conditions before running the production change. A tiny empty database offers little evidence about those operational effects.

Do not turn a staging observation into a universal zero-downtime promise. Production traffic, long-running transactions and data distribution may differ. Report the actual rehearsal conditions and the remaining uncertainty.

## Make rollback a supported state

An application rollback and a database reversal are separate actions. Once new writes exist, dropping a replacement field or reversing a transformation can discard information. Keeping the original column helps only if the rollback release still understands the data relationship and its writes remain compatible with any other running clients.

In the fictional plan, identify the bridge release as the supported rollback target during the read transition. Returning an unmodified legacy writer while new readers are active would reintroduce the stale-copy problem. After the old interface is removed, the rollback options change again; document that boundary before cleanup.

For the next AI-assisted schema change, request the consumer inventory, authority rule, transition gates and rehearsal evidence alongside the SQL. Those artifacts let a reviewer assess the whole release. A generated script is one part of that evidence, and its successful execution is one result—not proof that every supported application version will keep working.

## Sources & further reading

Sources checked for this article. Research findings and vendor claims are distinguished in the text.

1.  [Horizon: Robust Checks for SQL Migration Using LLMs](https://www.vldb.org/pvldb/vol18/p5259-emani.pdf)Venkatesh Emani and colleagues, Microsoft; PVLDB · Accessed 1 November 2026
2.  [Parallel Change](https://martinfowler.com/bliki/ParallelChange.html)Danilo Sato; martinfowler.com · Accessed 1 November 2026
3.  [PostgreSQL 18: ALTER TABLE](https://www.postgresql.org/docs/18/sql-altertable.html)PostgreSQL Global Development Group · Accessed 1 November 2026

Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/)

## Keep reading

[AI agent record updates: prevent overwrites with version checks](https://skillsforbusiness.ai/blog/ai-agent-record-updates-version-checks/)[A passing rerun does not explain an AI coding fix](https://skillsforbusiness.ai/blog/ai-coding-fixes-passing-rerun-evidence/)