This looks like a bad experience. The trick with using VMs is to treat them - logically speaking - as real machines. Then the next question would be: why would you install sql server AND application on the same server? And next: why would you integrate software changes in a development environment? If having real servers, wouldn't you use an integration environment with application and database servers? This would be the right environment to keep security under control because not any developer will deploy in this environment, but the DBA will do (database) deployments and db versioning. As a note, being a DBA, I talk only about the db side of deployments, but the actual work has to be done with a designed person that deploys application changes as a team.

And an important thing to make a DBA's life easier: do not bring developer VMs under domain; you cannot and shouldn't control any AD change.

If you would need to re-create a SQL Server VM with same name as an old one then, again, treat this one as a real server, which means assign a static IP which, by the way, it's not necessary to be the same with the one for the old vm, rename the server ann then rename the sql server instance (if already installed) and finally, decommission the old VM.

There are many other things to be said both pro or against using VMs for sql servers. Hope these lines would help someone in setting up VM environments.