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.
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.