Create view with column name aliases or hard change column names on a big database with a very low amount of changes?
Here would be two recommendation based on working in environments with lots of databases being used by lots of different apps.

Option 1:
Create a view with a similar name but reflecting the changes you want made. In your case, it's just one field renamed. You may have to create triggers on the view so the apps that perform DML can use it just like they use the original table.

Publicize the view name and encourage the app developers to change their code to use the view instead of the table. You want the only change needed to be the name of the table and any changes propagated through the view (the new name of the field). They can make the changes more or less "at their leisure" as the original table still works as before. You will, of course, give them a deadline to get this finished.

When all app changes have been made (and verified), you can really consider yourself finished. I encourage a system of exposing only views to apps instead of entity tables. This allows for much more freedom to make necessary changes to the tables and change views so everything looks the same to apps.

But if you want to, rename the fields in the tables and, after extensive testing of course, notify app developers to change the "table" names back to original.

Test and finished. Delete the views or keep them around if you prefer.

Option 2:
An alternative would be to rename the tables and create the views with the original table names. Then all apps would need to be changed at once to use the new field name(s). Thoroughly test after bringing the system back online.

Next, change the tables as needed and test. Then reverse the process -- rename (or drop) the views and rename the altered tables back to the original names. Test and (hopefully) finished.