Migrations are tested against development databases, which are small, clean and recently created. They run against production databases, which are none of those things.
Never drop to recreate
A migration that drops a table and rebuilds it has destroyed live data. This is the single worst thing an update can do and there is no recovery message that makes it acceptable. Additive changes only, wherever it is possible at all.
Record what has run
A migrations table with one row per applied step. Without it you cannot know what state a buyer's database is in, and neither can they. With it, a half-finished update can be resumed rather than guessed at.
Make each one re-runnable
Adding a column should check the column is not already there. A buyer whose update timed out will run it again, and the second run must not fail because the first partly succeeded.
Adding a non-null column needs three steps
Add it nullable, fill the existing rows in batches, then add the constraint. Doing it in one statement locks a large table for long enough to take the site down, and fails outright if any row cannot be filled.
Batch anything that touches every row
A thousand rows at a time, with the position recorded. On a shared host with an execution timeout, this is the difference between an update that completes and one that dies at 60 seconds leaving the data half converted.
Tell them to back up, and mean it
A line in the update notes saying to back up before running, and an installer that says it again. Most will ignore it. The ones who do not will thank you exactly once, at the moment it matters.
