Can I suggest you also look at your application upgrade process. The standard I have been used to is to minimise risk.
There should be no DB changes made that could stop the current version of the application running. (This includes the table name change you propose to do, that should be banned)
DB changes are typically harder or more disruptive to back out than reverting to an old version of application code, so plan to avoid any need for a DB backout. All changes you need should be planned to avoid any downtime.
Any DB changes needed for the new version of the application are done and verified in advance of rolling out the new application code. New columns can be added while the application is in use. Populating the new data should be planned to avoid workload peaks.
When the DB has been upgraded and data verified, the application code can be upgraded. If the new application code does have a problem, the old code can be reinstated and will continue to work.
I have worked in a Devops environment where new stuff got rolled out twice each day, so it all had to be done without downtime. One main lesson learned was that avoiding the need for downtime also avoided points of buisness risk.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara