If a release has occurred and it is deemed necessary to roll back the state of the schema, the best practice is to roll forward to that previous state, thereby preserving the true historical chain of events.

It is also often the case that a problematic release relates to not all, but a subset of specific changes, so it can be desirable to cherry-pick changes to revert to.

A roll forward can simply be regarded as a new migration, and should therefore follow the same release procedure.

Rolling forward using undo scripts

If undo scripts are being maintained already, the simplest way to roll forward is to copy the undo script as the next migration script. If there are programmable objects that need to be reverted, these will need to be copied from the previously deployed release package.

Cherry-picking changes

If not all of the changes need to be reverted, it is simply a question of editing the migration script and removing changes that are to be preserved. Likewise for programmable objects, only copy those that need to be reverted.

Rolling forward using our comparison technology

If undo scripts aren't being maintained, the roll forward script will need to either be authored manually, which can be time-consuming, or generated using SQL Compare or Schema Compare for Oracle.  These both have command lines and can be automated.

Save Schema snapshots as part of your release process.  These can be loaded as the "source" the compare tool.  Set the "target" as the target database to roll back. After a comparison, specific changes can be cherry-picked for reverting. Run through the Deploy wizard but don't apply the changes to the target directly as they must be applied via the proper process to be registered in the history table and not be regarded as "drift". Instead, copy the script and apply it to a development environment, and commit, push and deploy the changes as per the normal process.