The smoothest way would be to alter DNS so the original name is still correct and ends up at your new Casper service.

It will depend on your users and how many you have as to whether asking them to re-enroll would work. If they are already up and running and have all the apps they need there's not much of an incentive to re-enroll. The obedient ones will do it just because they are asked. But the others might not.

You could push a new quickadd package or an enrollment script to migrate them to the new instance, but the cleanest way would be to restore the database to the new JSS and point them to it via DNS or a jss URL change in the jamf config file. If you have escrowed FV keys you won't want to lose them.

I could be mistaken, but I've read others who have done similar migrations and I believe there's a component involved regarding certificates that can really mess things up if you don't do it right. Again, I've never done this and I'm only recalling issues others have posted here where they were trying to move to a new JSS. Perhaps someone will correct me or elaborate a bit more on my behalf.

That depends on your configuration. If it is a cert validation issue, a cert with the proper SANs should pass any verification.

Re-enrolling would work with a restored database too, the system would enroll back to its old record.

I am not sure about the cert issues, but guess will have to cross that bridge when I come to it. Okay will change the hostname of the old machine to point to the new IP address of Casper version 2. By the way does anyone know how long DNS cache lasts on the Macs before they will renew their DNS?

I will keep the old Mac Mini around in case re-architecting to CentOS 7 fails.

Well, I presume you would want to do a test run with a system, simulating a DNS change with a hosts file entry or something along those line.