Veto this migration plan

Assume it has to be rejected first, then decide whether it is worth doing

You are the senior engineer brought in to review this migration, and your job is to find grounds strong enough to veto it. Please: 1) list the specific conditions under which this migration fails (data volume, downtime window, rollback, other teams' cooperation); 2) name the problems the plan waves off as 'we will deal with that then'; 3) propose a smaller alternative path (migrate a subset first, dual-write first, migrate reads only); 4) only at the end: if you cannot veto it, which two things must be added.

[paste the migration plan]

How to use

For a real decision, have it argue against first and for second. The wider the gap between the two verdicts, the more the plan needs filling in.

Good for

The migration involves a write freeze, dual writes or moving data, and a mid-way failure means hours of downtime.
The plan already has supporters and nobody objected in the meeting — you need someone whose job is to argue against it.

Not for

It is an additive, reversible change like a new column or an index: just do it, no veto process needed.
You have already decided and want endorsement: this prompt will veto it exactly as you expect and waste a round.

Example

Input

Migration summary
Move the MySQL orders table (230M rows) to a new PostgreSQL cluster.
Window: Saturday 02:00-06:00. Export with mysqldump, import, switch traffic by changing DNS.
Rollback: "point back at the old database."
Four services and two external reconciliation partners are involved.

What you get

Show that a 4-hour window cannot cover export, import and verification of 230M rows; that 'point back at the old database' fails once writes have landed in the new one, because nothing syncs back; and that the external partners are offline at the weekend. Offer the smaller path — dual-write, migrate in user_id shards, move reads first — and if it survives, require row and amount reconciliation plus 24 hours of reverse sync.

Common mistakes

Writing only 'we are migrating' without volume, window or rollback: the veto degrades into 'this is risky'.
Treating it as the decision-maker: cancelling the project because it said veto, without going back to add the two preconditions.

Try tweaking it like this

Change the role from 'veto' to 'you are the on-call engineer for this migration — which step scares you most' and you get operational detail instead of process opinions.
Add 'attach one observable metric to each risk (latency, row-count delta, error rate)' and the veto becomes a pre-launch checklist.