Use SQL Server Configuration Manager to change the service account used by the SQL Server services. That will ensure any necessary changes are made to permissions required by that account. See the MIcrosoft Docs for precise details.
Regardless of what you set the service account to, any local rights should be applied to NT SERVICE\MSSQLSERVER, as this is the per-service Virtual Account, and even after you change the service account, the SQL Server will retain any rights granted to it.
To pursue best practice for SQL Service accounts, I’m working through changing the SQL service account to be AD accounts for our existing SQL servers.
This is only a best-practice if you are using a Managed Service Account or Group Managed Service account, and only if
You've got a cluster and need Kerberos authentication, or
You've got multiple services on the SQL Server and and need to differentiate domain permissions between them.
Otherwise leave the default Virtual Account account and grant any domain permissions for accessing external resources (like file shares) to the machine account (eg MyDomain\MyServer$).
Managed service accounts, group managed service accounts, and virtual
accounts are designed to provide crucial applications such as SQL
Server with the isolation of their own accounts, while eliminating the
need for an administrator to manually administer the Service Principal
Name (SPN) and credentials for these accounts. These make long term
management of service account users, passwords and SPNs much easier.