Migrations - Never delete the old stuff right away. Instead, rename the old column or table and leave it there, right next to new data. You can clean it up a year later, once you are absolutely sure data in the old format will not be needed anymore.
I usually don't do this in case of some columns that are referenced by other tables.
Why don't use a database backup on this case? If the server allow linked queries (like MSSQLS) you can even query the data from both databases to compare them.
The problem of renaming the table to put another one in its place are the relationships with other tables, the indexes and constraints. All of that would need to be rebuild.
In general case, I would strip away the constraints but leave the data. Then in the down migration, rebuild the data and restore all how it was.
But there are definitely cases where leaving the old data indexed makes sense (eg. there is old code or scripting relying on it, still not upgraded), and there are cases when deleting/upgrading in place makes sense (eg. having a lot of data).
The solution with the backup copy is good too. Two downsides I can think of:
you lose automated rollback.
you increase devops burden (suddenly you have a bunch of special case backups you need to catalog and manage)
But there are advantages too, of course.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I usually don't do this in case of some columns that are referenced by other tables.
Why don't use a database backup on this case? If the server allow linked queries (like MSSQLS) you can even query the data from both databases to compare them.
The problem of renaming the table to put another one in its place are the relationships with other tables, the indexes and constraints. All of that would need to be rebuild.
Depends on the context.
In general case, I would strip away the constraints but leave the data. Then in the down migration, rebuild the data and restore all how it was.
But there are definitely cases where leaving the old data indexed makes sense (eg. there is old code or scripting relying on it, still not upgraded), and there are cases when deleting/upgrading in place makes sense (eg. having a lot of data).
The solution with the backup copy is good too. Two downsides I can think of:
But there are advantages too, of course.