There are multiple reasons to have to rename a systemd service in production. For example:
- to better differentiate it from a new one
- because your boss ordered it
- because of legacy scripts
Assuming a new generic service created in
/etc/systemd/system/foo.service and enabled and started as follow: 
systemctl daemon-reload systemctl enable --now foo
Then, you may want to rename it from
bar.service without impacting the related process in any way.
In normal circumstances you can just do something like this:
mv foo.service bar.service systemctl daemon-reload systemctl disable foo systemctl enable bar
Then you obtain:
systemctl status foo:
systemctl status bar:
So you may want to fix with:
systemctl stop foo systemctl start bar
Or with a reboot. However in production environments this is not feasible since you don't want to stop the application for such change. Additionally, reboots are scheduled after months or years. At the same time, it's risky to keep for a long time a stopped service like
bar that should not be started by mistake before stopping the not-found running
In short. What approach would you use to rename a systemd service in production?
The ideal condition would be to have the two services backward compatible. Thus, stopping
foo also stops
bar and vice versa.