* le plus naturel serait de passer d'Ubuntu 18.04.3 LTS vers 20.04 LTS;

* en effet, il n'est pas trop improbable qu'un Linux moderne puisse être passé d'une machine à une autre sans avoir à le reparamétrer, donc je pense aussi que ça serait à tester;

* je ne connais pas de distribution de plus de 2 ans qui reçoive un support sécurité digne de ce nom...
Pour le kernel, au bout d'un an, il manque déjà quelques centaines de fixes de sécurité aux kernels Linux LTS, et les kernels Linux XLTS sont pires. Pour les deux infos, la source est spender, qui sait de quoi il parle. Il a récemment fait une présentation au Linux Security Summit ( https://mobile.twitter.com/opensrcsec/status/1278798266646306817 ), la slide 26 du PDF contient un nombre: "As of our final 4.4 patch, had at least 1250 security-relevant fixes missing in the upstream 4.4 LTS". Et il ne prétend certainement pas qu'il n'a pas pu rater un seul commit.
Pour le user-space, j'ai fait l'expérience plusieurs fois que même des packages "populaires" (Debian popcon top 1000, pour ce que le popcon vaut) bourrés de failles allant parfois au-delà du simple DoS ne reçoivent pas toujours, et pas toujours rapidement, de backports dans Debian ou les autres distros majeures, même en notifiant security@ . Seul un jeu assez restreint de packages reçoit des mises à jour de sécurité. Une des méthodes les plus efficaces pour déclencher les mises à jour de sécurité est d'obtenir des CVE IDs pour les vulnérabilités, mais c'est beaucoup de boulot s'il y a beaucoup de vulnérabilités.
RHEL fait maintenant bien moins qu'une release tous les deux ans... donc pour moi, RHEL et ses dérivées font partie du gros ensemble des distros qui n'ont pas un support sécurité digne de ce nom, une partie du temps. Sur les packages majeurs, ils sont pourtant assez réactifs, en général.

* le support sécurité de CentOS est d'autant plus mauvais qu'il est retardé par rapport à RHEL: en comparant le flux de vulnérabilités du CERT-FR, qui linke des advisories RedHat contenant des infos sur les versions corrigées, et le repo de packages updates de CentOS - ça fait partie de mes tâches au boulot - je vois que les packages corrigés parviennent dans les repos CentOS quelques jours à quelques semaines après leur arrivée dans les repos RHEL.

* transférer les données de /boot , /boot/efi , / et autres partitions Linux vers une nouveau disque / une nouvelle machine est jouable, avec par exemple rsync -avHEAXSxt . J'ai fait ce genre de manips plusieurs fois ces dernières années pour faire des forks de machines, avec un downtime assez faible. Au passage, j'ai même changé de système de boot et de partitions (en installant d'abord le nouveau système, puis en transférant les données): je suis passé d'un boot BIOS classique avec partitions "physiques" /home et / non chiffrées, / à un boot UEFI avec /boot, /boot/efi bien sûr, et un volume LUKS contenant un PV LVM contenant un VG contenant deux LVs /home et /.