@Arne Bier very interesting and important questions. Here are my opinions on your concerns:
Completely migrating to a new ISE instance and performing a brand new integration would be a large task IMO. I can tell you from experience that I have seen the pxgrid connection between our ISE cluster and DNAC cluster go down and stay down for some time. This did not present any fabric related problems because they had been integrated beforehand so the SGT assignment to VNs in DNAC and everything else was already configured and provisioned. The issue was actually discovered when attempting to deploy new SGTs since we rely on ISE to perform all micro segmentation tasks and not DNAC. Simply updating the ISE IP in DNAC will not affect your NADs and clients in the fabric until you re-provision your hosts. When updating the ISE IP in DNAC, and then provisioning ENs this is going to update things on your ENs such as radius configs, dynamic auth configs, etc. I have actually tested this and the fabric remains operational when NOT re-provisioning the ENs. Note though that things were already provisioned and deployed. Since 1.3.x version of DNAC you can actually choose to rely on DNAC as the main policy enforcer where you would configure CTS related stuff (this is found under Policy->Group Based Access Control Settings). If you choose to use DNAC as the main driver ISE becomes a read-only mechanism.
What is the procedure to switch that existing integration to a totally different/new ISE deployment?
is there a way to point DNAC to a new ISE deployment (assuming you had no ISE config backups)?
AKAIK there is no documentation/CVD on switching over to a brand new ISE cluster. Some options I think you may have that would be worth a shot to test are:
*I would recommend ensuring that your critical auth vlan provides whatever access you deem necessary. You can tweak the DNAC out of the box config via template editor. This may bail you out and allow clients some sort of network access if things go wrong
Scenario 1 (migrate from existing ISE cluster): Change authz profiles in ISE to require re-auth to like 12 hours or more. Ensure clients reauth and you get the 12 hour window to play. Flip GBAC settings so that you rely on DNAC to manage micro segmentation. This should sync current ISE CTS config to DNAC. At this point no hosts are needing to reauth to existing PSNs and you have some footprint of CTS deployed and functioning. Build out new ISE cluster to include PSNs and radius policies. In a scheduled ASI change the ISE DNAC IP, then re-provision one EN so that it attempts to use new PSN come reauth time and test connectivity. At this point the new PSNs are authenticating and authorizing. You shouldnt need to make any CTS changes since the fabric already contains some sort of configs. Once confirmed the one EN works, start re-provisioning the remaining ENs.
Scenario 2 (migrate to new ISE cluster after losing other ISE cluster): I would assume at this point hosts would start dropping into the critical vlan access network once reauth occurred and your NADs figured out ISE is dead. You would probably want to build out the new ISE cluster and then integrate with DNAC to sync configs. I would imagine that your SGTs would need to remain with the same names, etc. so that you dont have to change VN to ip pool/sgt assignments in DNAC and really shake up the fabric. That info can be taken from your DNAC cluster for reference during new build. I think again in this scenario you could flip to using DNAC as main driver for GBAC. However, you will run into the NAD + ISE auth problem since your NADs will contain old dead ISE radius configs. Things wouldnt start to get better until complete integration and re-provisioning of ENs.
I may be forgetting a couple of items to watch out for/be aware of, but I hope this helps shed some light on your very good questions.
