This article describes how to handle what to do when you wish to revert a migration that has already made it to master.
It is important to understand that a migration that has made it to master could already have been run in many environments, including developer devstacks. Although Production may be the first concern, you must follow-up with help for all other environments.
Here's what you do to resolve removing a bad migration from master.
Determine if the migration can be corrected with the addition of a new migration. This is the simplest option when it is available.
Use the following types of questions to help determine whether you can roll-forward (i.e. create a new migration rather than reverting the old migration).
Can the new migration handle bad data that may have been created before the new migration appears?
Will the new migration cause a problem in Production (e.g. altering a large table)?
If you can resolve with a new migration, do so and then communicate about the need to get and run the new migration (see below).
If you need to literally revert the migration from master, do so and then communicate about how to revert the old migration (see below).