Switch legacy system to new hard disk with uefi Windows

I just bought a new computer with an NVme drive with, of course, Windows 11 pre-installed. I took the SATA SSD from my old computer and installed it in the new one. My plan was to repartition the NVme drive, copy my Home partition to the NVMe drive from the SATA drive using Clonezilla and reinstall Opensuse. In the process of getting the system to boot with a USB stick, I managed to put the old SSD above the NVMe disk in the boot order and my existing Opensuse installation booted. I did a zypper up and all the kernel modules needed by the new system magically loaded (I switched from AMD to Intel) and the Nvidia drivers updated themselves to accomodate the new video card (the old system was Nvidia as well). So, to make a long-story short, rather than reinstall, I’d like to move the OpenSuse system to the NVMe and move a much shrunken Windows to the SATA SSD and have a dual boot system. I’m not sure how to work this as the old SUSE system is booted as a legacy system and Windows is UEFI. Presumably I need to convert the old SUSE system to UEFI and clone the Windows partitions to the same position on the SATA SSD as they occupy on the NVme SSD. I’m reticent to do this as I don’t want to have an unbootable system. Does anyone have any advice?

Do a fresh, new Installation, it’s the best advice, I could give to you.
After Installation copy the needed files to the new Installation.

Download https://download.opensuse.org/distribution/leap/15.5/iso/openSUSE-Leap-15.5-NET-x86_64-Media.iso

Boot into the UEFI Version of the Installer. It’s main menu has a nice option for booting an installed system.

A potential gotcha is to boot from the nvme ssd requires a different driver than for the sata ssd. That means initrd(s) need(s) to be regenerated to include it before it can work on the nvme. Even so, it’s possible you will need appended to the linu line in Grub rd.hostonly=0 and/or rd.auto (to enable locating the ESP) until another initrd regeneration has occurred post-migration.

This sounds problematic. Would it make a difference in performance to move then OS to the NVMe drive from the SATA III drive? Could I mount root on the NVME drive but leave /boot on the SATA drive as its own little partition and still boot from the SATA drive? Is there a way to dual boot the UEFI Windows and the legacy SUSE?

If I leave things as is and just move /home to the NVMe would that make up any performance differences?

I really appreciate your help on this.

Sauerland and karlmistelberger’s advice is sound.

Yes, but not a very good idea for someone lacking experience in disk and partition migrations. You’d need to do a repair installation that converts from legacy to UEFI booting, using the existing ESP partition on the NVME. If you wish Leap to be on the NVME, you’d first create space for it, which I would only do using Windows’ own resize facility, then clone the SATA system partition to the NVME before changing BIOS to disable legacy booting, then booting installation media in UEFI mode to “upgrade” the existing installation using the NVME’s ESP. To avoid potential clashing, I’d remove the SATA before booting installation media, and do an extra maintenance boot to change all the copied UUIDs to restore uniqueness. I’d also assign unique LABELs to all partitions that don’t already have them, change the copies on any that do, then replace all fstab UUIDs with those LABELs, to ensure when you reinstall the SATA that there’s no chance for non-unique LABELs or UUIDs causing trouble, and make it easier on your own brain to keep straight what’s what while working your way through the processes.

I have no experience with Windows 11, nor with moving Windows 10 or earlier off of HD0. Windows historically hasn’t much cared to be on a non-HD0 disk, but it has been doable. What I’d try, after succeeding in the Leap migration, is cloning the Windows system partition to the SATA, then replacing Windows’ original system partition table type entry with a nonsense entry, such as 0xE7, to prevent Windows from trying to damage the content of that space by creating partition(s) in it. Once done, I’d boot Windows installation media to do a repair of its bootloader, keeping it on the original ESP.

Once both Windows and Leap are booting UEFI successfully, you could consider eliminating its non-ESP partitions from NVME, making those spaces available to expand spaces used by Leap, either enlarging a BTRFS /, or creating a new home or other data partition/filesystem.

The point of my preceding text here is demonstrating that there are many ways to proceed, all including multiple steps, as well as many ways to thwart success. Fresh installations make better sense for those with little to no experience in such processes.

As it happened, my backup HDD bit the dust after several years. Given the ridiculously cheap prices for NVMEs, rather than replace the backup disk, I bought a second NVME and installed it in the computer. I cloned the old SATA to the new NVME, leaving Windows on the original NVME. I adjusted the BIOS and can boot to OpenSuse on the new NVME as a legacy system. I can boot to Windows by calling up the BIOS boot menu when rebooting the computer. Is there any advantage to trying to convert the legacy SUSE to EFI and combine everything on the Grub menu, or is my current kludge a reasonable solution? As for the SATA drive, I’ve bought a cheap enclosure and will use it as a backup drive over USB.

I did manage to change the system from legacy to uefi. First I converted the MBR partition table to GPT following the instructions in [https://www.redhat.com/sysadmin/bios-uefi]. I mounted the EFI partition that Windows had created at /boot/efi and ran shim-install. I checked Probe for foreign operating systems in the Yast setup page for Grub and rebooted a dual boot system with Opensuse and Windows successfully. I did prepare the disks with unique labels for the partitions as well as making sure UUIDs were unique and for clarity used labels rather than uuids in fstab.