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: [1]
systemctl daemon-reload
systemctl enable --now foo
Then, you may want to rename it from foo.service to 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:- running- not-found- disabled
- systemctl status bar:- not-running- enabled
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 foo.
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.