Migrations & refactors
The migration that could take everything down
A schema change or a framework upgrade touches everything. Get the order wrong, drop the wrong column, and the whole app — and its data — goes with it.
The scenario
Noor — the lead dev on a small product team, building a CRM with a few thousand active users.
The goal
Pull off a big database migration — splitting one table into two — and a framework upgrade in the same week, with AI doing most of the work, without losing data or taking downtime.
The migration is the scary kind: it rewrites a core table, and a dozen files depend on the old shape. Claude can write each piece, but the danger lives in the seams — the order things apply, a “rename” that’s really a drop, a stale branch that reverts half of it.
Without afterclick
- A migration meant to rename a column generates as a drop-and-recreate — and the data in it is gone.
- The code that reads the new shape ships before the schema change applies, so prod half-breaks for everyone mid-deploy.
- A parallel session’s stale branch lands on top and quietly reverts part of the migration.
- Noor finds out which of these happened from a customer, at the worst possible time.
With afterclick
- Destructive migrations caught. A migration that would drop a column — and its data — instead of renaming it is stopped by a tripwire before it ever runs.
- The right order, enforced. The release manager plans the merge order — schema before the code that depends on it — so the deploy can’t half-apply.
- No stale-branch reverts. The ship queue forces a rebase on what’s already live, so a parallel session can’t land on top and undo half the migration.
- Proven on staging first. The whole migration runs and is verified on staging before it ever touches the production database.
What afterclick did here
- 1Flagged the generated migration that would have dropped the old column instead of moving its data.
- 2Planned the deploy: schema migration first, then the code that reads the new tables.
- 3Forced a rebase on main so a parallel branch couldn’t revert part of the change.
- 4Ran the full migration on staging and confirmed the data survived before prod.
- 5Held the prod deploy in the ship queue until every check was green.
What you’d have seen
This “rename” is a drop
The migration drops customers.phone and recreates it empty — the data goes with it. Held before it ran.
The obvious objection
Why not just test the migration and lean on CI?
You should test it — but a migration that passes on an empty test database can still drop real data on a full one, and CI runs after the push, not at the moment the destructive statement is about to execute against prod. CI also won’t plan your merge order or stop a parallel branch from reverting half your work in a race. afterclick blocks the destructive statement deterministically, enforces the schema-before-code order, forces the rebase that prevents the revert, and runs the whole thing through staging first — the seams a test suite doesn’t cover are exactly where migrations go wrong.
For the senior engineer
You know migrations are all about ordering and irreversibility, and you’d hand-check this one — the value is that the checks are mechanical and easy to skip when you’re confident, and a “rename” that’s really a drop has taken down apps run by people far more careful than a tired lead at the end of a big week. afterclick reads the migration with fresh eyes every time, enforces the order, and won’t let a stale branch undo it — the discipline you’d apply on a good day, applied on every day.
What it replaced for you
- The hand-checking of every migration’s ordering and reversibility.
- The half-applied deploy that breaks prod mid-rollout.
- The data lost to a “rename” that was really a drop.
- The stale-branch revert nobody saw coming.
The outcome
Noor landed both the table split and the framework upgrade in one week, with no data loss and no downtime. The migration that used to mean a maintenance window and crossed fingers became a normal, staged ship.
Sound like you?
One paste, AI included, free to start.