I have personal reservations to the statement that “adding business logic to the database” is a bad idea. Asides the issue of data migration, which holds true for other scenarios outside business logic. If the goal is to apply effective design principles for a database that is part of a cluster and has replication capabilities and logic can be moved to the database, which is closet to the data being dealt with - what are other reasons for it being considered bad practise?
In my opinion, your own stated reasons (to make it bad practice) are enough. Data migration, replication issues, and code refactoring are the things that make it bad practice to add business logic to DB.
Adding business logic to the database violates the single responsibility and the separation of concerns design principle. Also, the idea is to keep the business logic as compact as possible. Spreading the logic everywhere in the application isn’t a good idea. It makes code testing a nightmare. Even JSP (Java Server Pages) were deprecated for the same reason.
Also, making changes to the database or changing the database entirely keeps the need for code refactoring as minimal as possible.