If you can roll back and forward events, good for you but for most of us rollbacks are actually a new build, deployment, and a new set of tests. Every single time.
This is why I've never used or understood the value of the "downgrade" feature in some database migration tools. If you need to revert, make a _new_ migration that fixes the problem. Your tooling/code/logs should reflect the true history of the system without cooking the books.
Of course usually it would be followed by something that fixes it 'properly' - applying the original 'upgrade' again but with some correction, but typically that'll take longer than reverting to the previous version, and given it's gone wrong you'll probably want to take longer with it, test more, restore confidence.
Forward migration: add date column, set = date(day, month, year) for existing records, drop is valid date constraint, drop day/month/year columns
Down migration: add day/month/year columns, add is valid date constraint, set day/month/year = appropriate datepart of date, drop date column
for trivial example.
It's technically a roll forward, while to most users it's more nature to say rollback/revert