HCI has been deprecated years ago, but somehow the code survived until oVirt 4.5.5 or so.
Which means it's still present in Oracle's 4.4 derivative. but not in their 4.5
release.
On that base (make sure to use to switch to the Redhat kernel on all hosts and the
management engine to avoid troubles) you can at least still build a HCI implementation
that is in support (EOL not announced by Oracle) and much less beta than oVirt releases.
When it comes to do an in-place migration of a HCI setup, open heart surgery may have more
predictable results. Essentially you'd have to treat it like a disaster recovery and
follow the path of restoring a management engine from backup.
I've gone the migration way, created a new cluster and used a backup domain to
transfer all VMs.
Gluster in itself is quite independent, which might be a bonus here, while I mostly
suffered from how it was never really integrated and had many mismatches in design
philosophy.
It's the storage domains on top that are at risk, but those again are relatively
independent of the storage underneath, since they were designed for SAN, NFS and whatnot.
Again, in theory, they can be imported elsewhere, because they have metadata describing
them.
I've done all my testing using play HCI clusters on VMware Workstation using nested
virtualization, before I tried things on "live patients".
Whatever you're planning, HCI has basically expired with oVirt 4.4 on EL8. If
you're happy to loose everything, you may keep trying. I went with Proxmox using HCI
on Ceph and while it's much more manual in many ways, it has a future, is way faster
(no Ansible) and rock solid.
Getting VMs migrated is a lot of bother, because none of these orchestrators were ever
keen on making it easy for customers to defect. But since it's all KVM/QEMU
underneath, tools that operate at that level will work.
Now you'll just have to learn them or rebuild those VMs: that's "the cloud
path" anyway...