Replace 2012 DC with 2019 DC

If you script mounting your shares to drive letters, then changing the server name is a simple task in modifying the script.

If you use Group Policy to map your shares to drive letters, then the changing of the server name should be easily and quickly adjusted in the group policy.

If you use DFS Namespaces, then you just add the server as a target and remove the old server and no one ever knows you replaced the server (I'd recommend this even if you do either of the first two).  If you don't use DFS Namespaces right now, START.  That way, next time you do this, it's not an issue.

I completely agree with Kevin - you DO NOT want to rename a DC.  The only reliable way to preserve the name is to migrate first to a temp DC, retire the original, then migrate a second time.  A huge waste of effort in my opinion.

As for how to move the data, I have an article on File Server Migration Methods - see https://www.experts-exchange.com/articles/29316/File-Server-Migration-Methods.html

Is there a good reason to have file sharing on a DC?  That is generally discouraged.

I've done it many times in the past before I used VMs.  It wasn't cost-effective for my small clients to have two physical servers, one for the DC (AD, DNS, DHCP) and the other for file sharing.  Once I went to VMs, it was very practical to separate the DC from the App server (file sharing, print sharing, apps such as QuickBooks).

With newer versions of Windows Server (somewhere around 2016, I think) you are allowed to have two VMs with one Server license.  That got rid of a big expense.

If your hardware has adequate cores and RAM, give serious consideration to setting up two VMs.  Kevinsieh makes an excellent point about DFS Namespace.  It won't make this migration any easier, but it will make the next one (there WILL be a next one) MUCH easier.  The key is that you map to network shares, not file server shares.  It's very easy to change where those network shares are located.  The clients never know the difference.

Is there a good reason to have file sharing on a DC?  That is generally discouraged.

This is discouraged because of the idea that you should separate roles to minimize disruption should something need to be rebooted.  HOWEVER, File servers rarely need rebooting as do DCs. And the security risks in a small business (for most small businesses) are MINIMAL.

Yes, one license gives you two VMs, HOWEVER, I find it a better use of the resources to leave that VM either unused to introduce it as an RDS server or an application server.  Especially in a post covid world, using it as an RDS Gateway or full fledged session host, is likely a better use of the VM, meaning you continue to use the DC as a file server, as has been done in SMB for the last 25 years or so.

At least in my opinion.

Back in the SBS days we would do what we called a Swing Migration and since we're long past SBS:
 1: S/U new VM using Trial Server Edition
 2: Name it TempDC and S/U ADDS/DNS/DHCP
 2a: NOTE: FRS to DFSR AD Replication Topology migration may be required
 3: Demote old DC once everything is 100%
 4: S/U Windows Admin Centre and Storage Migration Service
 5: Update both WAC and SMS
 6: Run the steps to create the initial sync between Source and Destination
 7: At cut-over use the rename process to name the new server the same as old and give the old a different name
 8: DCPromo the new server and verify all
 9: DCPromo TempDC out.

Done.

Thank you all for your suggestions.  Since it is 2012r2, what are your thoughts on imaging the new server with the old 2012r2, then performing an upgrade to 2019.  If this is possible, I think it would save a lot of time.  This is a small network of about 12 workstations.  Not using GPO for mapped drives.  Most users simply have desktop shortcuts to the server location. 

Answers to these questions from Kevinhsieh:  "Is the new server a VM? Can you spin up a VM? Have you ever used DFS Namespace before? How many users do you have? How many shares? Are all drive mappings handled via GPO? Do you have folder redirection? Roaming profiles?"

The new server is not VM.  It is a pysical server.  I am not using DFS Namespace.  There are only 12 users.  There are 15 shares.  Not using GPO for mapping.  No roaming profiles.

Thank you.

In-Place upgrade is not possible with the ADDS Role installed (DC).

It's 2022. Don't you think it is time for running in VMs?

Current server is running 2012 R2, so it is what, 6-12 years old already? Time for new hardware (and VMs)?

Jeff Glover provides a path that should work.  It is probably the easiest way to do this, but it has two significant shortcomings: server in-place upgrades are usually discouraged as they can create problems down the road and your server will still be physical and not virtual.  You'll have to decide of those potential issues are not significant enough to worry about.

I was a late adopter of VMs, mostly because of software manufacturers that wouldn't support their products on VMs.  As that changed I started doing VMs and am very glad that I did.  I've similarly moved to DFS Namespace for sharing.  I complain about it when I first set it up as it would have been easier to do the migration of shares manually, but the next time I do a migration on that server I see just how handy it is.

One of the many advantages for me with VMs on servers has to do with disaster recovery.  I've had to fight with physical servers whose motherboards have failed.  Getting a physical installation of Windows Server running on different hardware may not be easy and you are doing it at a time when the server is down and you don't need any additional stress.

I had a client whose server was needing some hardware work and the client didn't want downtime.  It was easy for me to grab a Windows 10 workstation, add some RAM, toss in a regular 2T HD (that was big enough), set up Hyper-V, copy the VM over, and configure it.  Other than the server being slower, clients couldn't tell the difference between my temporary computer and the original server.  That would likely have been much harder to do without VMs.

If you buy new server hardware, it's also quite easy to move a VM over from the old hardware.  Again, that may not be so easy with new hardware.

You really need to virtualize. It's a waste of a Windows license not to.  Backup, wipe and reload the new server as a Hyper-V host, then install another server as a VM.  If you've never done this before, spend some time learning about virtualization and Hyper-V (if you're already familiar with VMware, fine, use that, but if not, no need to overly complicate things, use Hyper-V).  So what, it's a small business.  All the more reason to virtualize as it will ultimately save money and potentially provide for MUCH EASIER disaster recovery and even backups.  Again, I have an article on this too, https://www.experts-exchange.com/articles/27799/Virtual-or-Physical.html

Thank you everyone for your input.  Sorry for the delay in responding.  I didn't get a chance to get back to the task until this weekend.  I ended up following Jeff Glover's suggestions and everything went very well.  Also appreciate the input from Lee W. MVP and CompProbSolv.  

Glad to hear that you got it working.

I'd give careful consideration to moving over to VMs as a longer-term project.  It would be easy to set up a DC VM (DNS, DHCP, AD only) and move the roles over to it.  It shouldn't be disruptive other than changing the DNS settings on anything that is statically set.  Until you get the changes made, the devices will still work as you'll not get rid of the original DNS server until you are done.

Moving the shares over to a second VM will take more effort, but should be worth it in the long run.  It's much easier to do when you're not under a big time crunch.

I should note that my suggestion likely violates MS licensing rules while you are in the process of moving to the VMs.  Last time I read the rules, you could have two VMs with one license, but the host couldn't do much other than be a Hyper-V host.  Once you are done moving to the two VMs, you should be back in compliance.  You'd have to decide if the short-term licensing issue is of concern.

Thank you for the input CompProbSolv.  I understand as far as the MS licensing issue is concerned.