A thought: In a remote LAB environment set up a VM SLES 15 SP6 with eDir same IP, FQDN and other as the SLES 12 VM. I assume that if a technician is involved with IDM, he knows how to make a DIB and certificate backup. After the backup has been made on the SLES 12 VM, the VM can be shut down and an eDir disaster recovery can be performed bon target vm in the lab.. The NDS knows that the eDir on the server is down, this is also announced in the NDS in Sync. Even if the NDS is restarted on the new VM in the lab, the sync partners are missing and the system is shut down again at the end, i.e. the VM and DIB are offline.

There are other things to consider for the master functions of the eDir on a VM, but that should also be clear. After the VM has the SLES 12 DIB + Cert, move it from the LAB network to the “real” network and run the necessary health check

One important thing. Before the whole migration topic, please check whether the transitive synchronization is OK and whether any vectors in the NDS are “rotten”. An experienced NDS supporter will know what this means. Furthermore, please check whether SLP is really OK, whether there are no open offsprings backlinks, Replika sync,  obituaries etc. at any point. Please think about the timekeeping, SLES 12 is different from SLES 15. Check all certificates beforehand and, above all, make a backup of the tree CA. Write a small script using nmap to check whether the necessary ports for eDir, Time, etc. are open on all systems and, above all, check whether every server can reach every server via 524 TCP. Check the hosts of all servers and above all check whether the NDS is bound to 127.0.0.2, the IP can appear as a bind IP in the hosts in certain situations. An NDS on 127.0.02 leads to quite funny errors in the NDS communication. 
George

A thought: In a remote LAB environment set up a VM SLES 15 SP6 with eDir same IP, FQDN and other as the SLES 12 VM. I assume that if a technician is involved with IDM, he knows how to make a DIB and certificate backup. After the backup has been made on the SLES 12 VM, the VM can be shut down and an eDir disaster recovery can be performed bon target vm in the lab.. The NDS knows that the eDir on the server is down, this is also announced in the NDS in Sync. Even if the NDS is restarted on the new VM in the lab, the sync partners are missing and the system is shut down again at the end, i.e. the VM and DIB are offline.

There are other things to consider for the master functions of the eDir on a VM, but that should also be clear. After the VM has the SLES 12 DIB + Cert, move it from the LAB network to the “real” network and run the necessary health check

One important thing. Before the whole migration topic, please check whether the transitive synchronization is OK and whether any vectors in the NDS are “rotten”. An experienced NDS supporter will know what this means. Furthermore, please check whether SLP is really OK, whether there are no open offsprings backlinks, Replika sync,  obituaries etc. at any point. Please think about the timekeeping, SLES 12 is different from SLES 15. Check all certificates beforehand and, above all, make a backup of the tree CA. Write a small script using nmap to check whether the necessary ports for eDir, Time, etc. are open on all systems and, above all, check whether every server can reach every server via 524 TCP. Check the hosts of all servers and above all check whether the NDS is bound to 127.0.0.2, the IP can appear as a bind IP in the hosts in certain situations. An NDS on 127.0.02 leads to quite funny errors in the NDS communication. 
George