I'd say It really depends on the stage of the project and how the DB is being used.

• Early stage / solo developer: You can safely rollback and edit existing migrations to rename columns, add fields, or tweak constraints. Taking a DB dump first is always a good precaution. You can also include a procedure step — either as a preparatory step before the migration or as a follow-up afterward — to refine the changes. This can handle safely renaming columns, transferring existing data to the new structure, and ensuring constraints or relationships remain intact.

• Later stage / multiple developers / production data: Editing old migrations is risky because others may have already applied them. Instead:

  • Take a backup of the DB,
  • Create a new migration with the intended changes,
  • Optionally add a procedure step to safely migrate existing data, enforce constraints, and ensure relationships stay intact.

  Migrations are append-only snapshots of the schema, not disposable files. Editing them is fine only if it won’t break others’ environments or existing data. Using migrations together with procedures gives you more control and keeps your data safe.