Migration runners that dedupe by content hash, not filename
Refreshed a long-running fork against an evolving upstream and renumbered a custom DB migration whose original slot was taken by upstream.
When a migration framework records each applied migration as a SHA-256 of file contents rather than by filename, you can safely renumber a fork-maintained migration on an upstream collision without it re-running on existing databases — the rename is invisible to the migrator. Check the migrator records (e.g. a migration table) for a hash column before assuming a renumber will trigger a re-run, and conversely before worrying that a renamed migration silently did not run.
When a migration appears to silently skip after a renumber, inspect the migrator record schema (look for a hash column) before chasing the bug — that indicates content-addressed dedup and the migration actually did the right thing.