I have cloned all partitions on a drive from an old Dell with BIOS PC running Windows 10 on MBR layout drive to a NVMe in a 11th gen Intel system with UEFI. I used Re-Deply during the clone process. The new system booted right up. I've had no problems with Windows / driver updates, etc after many restarts.

In a prior attempt l copied only the Windows OS partition to the SSD, and the outcome was the same, everything worked fine. I proceeded to remove outdated programs, and old drivers. After several more restarts the system was fine Until I removed something that rendered system unable to load Windows. Booting from the Macrium Rescue disk I could still navigate the Windows OS partition. I tried a number of different fixes and was unable to get Windows to restart.

Back to the current system with all cloned partitions, I have been careful not to remove drivers and the system is quite stable. However, I'm concerned that the issue that caused the 1st failure still remains. I've checked the Volumes on the SSD in Disk manager and it shows they are still MBR and I believe that is one of the potential problems. I tried to convert the layout using the Windows MBR2GPT.exe conversion utility but I can't get passed the validation process.
 
A few months ago someone in the forum with a similar problem wiped the disk and set it to GPT before installing the images. That seems unnecessary but I'd be willing to do it if I knew that would work in my specific setup.
I'm trying to find the most likely explanation as to why these failures occur. (fwiw, I work with the elderly on PCs that have unique apps which are not easily reinstalled; they also have difficulty adapting to any differences in their setups.)

Thanks

Macrium has a KB article for this precise subject: https://knowledgebase.macrium.com/display/KNOW80/Restoring+an+MBR+System+image+to+UEFI-GPT

If you performed a conventional restore of an MBR disk onto the new system, then the new system likely supported both UEFI and Legacy BIOS booting, the latter courtesy of UEFI CSM (aka Legacy Option ROMs) being enabled. But that would prevent you from using or even enabling UEFI Secure Boot.

There isn’t nearly enough detail in your post to provide assistance as to what you may have removed that subsequently rendered your system unbootable, but that would not be attributable to how Windows booted in the first place, and consequently would not be fixed by switching to another boot mode if the original boot mode already worked.

As for MBR2GPT, what is the exact error you’re seeing in the validation phase?

KB article: I read the link you shared before I posted. It says "we assume there are no other hardware differences" (the systems are very different) "For dissimilar hardware, use ReDeploy". I understood the article's caveat to mean, skip this process and do a ReDeploy, but perhaps they were saying do this and then run ReDeploy?

Boot Troubleshooting: The "Restoring" article references "Fixing Windows boot problems". It's a little confusing because it indicates that Fix Windows is only available in Windows PE but the screens show RE. I guess the option is available in both and it doesn't matter which you use? I ran through the Fixing Windows process; it was unable to build the BCD.  

Secure Boot: When I go into system setup Secure Boot is disabled but Windows MSINFO32 indicates the Bios mode is UEFI

Uninstall detail: I uninstalled old devices and their related drivers from Device Manager. There were quite of few, due to differences between the source and target hardware. I also uninstalled a number of outdated & unused programs including Dell utilities that came with the system. I don't recall if these included the Dell factory restore app. (fwiw, I didn't copy the OEM partition on the first attempt that crashed). 
So are you saying that nothing could have effected the BCD, winload.efi or some other component or step in the Windows startup & boot process? [I'm not familiar enough with the sequence to know, but I had successfully performed many reboots before the Windows became unbootable]

Conversion fail: Regarding the MBR2GPT conversion, there are no error codes, you simply get a failed to validate reply. I've googled how to fix validation failures; the things I've tried haven't worked.

Next step: I am going to create the partitions as recommended in the KB article and see how that goes. I'll post my results.

KB: Yes, if you are switching platforms AND moving to dissimilar hardware, then you would do both. ReDeploy would be the final step.

Fix Boot Problems: It’s available in all types of Rescue Media. The original article was probably written before WinRE became an option (as of Reflect 7.2) and that language might never have been updated. But it’s also important to note that you have to boot the Rescue Media itself using the same mode that you want fixes applied for. So for example if you’re trying to set up Windows for UEFI boot, then you have to boot the Rescue Media in UEFI mode. You can verify this by checking the title bar along the very top of the Rescue interface. It will say “UEFI” at the very end if it was booted in UEFI mode. And this step is necessary in this specific scenario because the process described in the KB article includes making a brand new EFI partition that will be empty. Fix Boot Problems when run in UEFI mode creates a Windows Boot Manager instance on that EFI partition using bootloader files copied from the core Windows partition. A correctly configured EFI partition is necessary for UEFI booting.

Secure Boot: I don’t understand how you can be booting in UEFI mode if your disk is MBR, unless you have another physical disk in your system that contains the Windows bootloader, which is then turning around and booting from the Windows partition on your MBR disk. Perhaps a screenshot of the Local Disks tab in Reflect would be illuminating here. A picture can quite often be worth 1000 words here.

Uninstalling: Removing old devices and their associated drivers isn’t really worth the effort. They won’t load if the device is no longer present, and drivers typically won’t free up enough space to be worth the effort. Uninstalling applications of course can be useful. An uninstallation that renders your system unbootable is rather rare, but if the application/utility in question loaded a boot-time component, that can happen. Some antimalware solutions have been notorious for this. They hook deeply into the system and don’t clean themselves up properly on uninstallation, so sometimes after removing them, your system no longer starts properly because it left some dependency on a component that no longer exists.

MBR2GPT: If you’re going to attempt the KB article steps, then you can forget about this. The KB article will give you a cleaner result anyway since you’ll have the reference partition sequence, which you can’t get with MBR2GPT.

I've used the procedure jphughan references above on both my PC and my wife's PC and it worked exactly as advertised. I had tried MBR2GPT prior to that with mixed results. First, he is right that the partitions are not in the order which you expect and want and I had several failures for reasons I didn't understand. So follow his advice and you should be okay. Just be sure to run the "fix boot" problems as directed and make sure you are booting into UEFI rescue media. 

The instructions in the article "Restoring an MBR System image to UEFI/GPT" worked for me also. When I was done with the procedure, my old PC hard drives' MBR partitions, including an extended partition, were working perfectly on the new PC's SSD as GPT. I suggest that the caution at the start of the "Restoring" article should read something along the lines "For dissimilar hardware run ReDeply after completing the procedure described below. This should be done before the first reboot" 

Fwiw, I used the option not to replace the MBR on the target with the MBR on the source when restoring the image to the new SSD. After completing the process and running ReDeploy, I had a boot error on the first restart. After booting from the Rescue Media I ran > Fix Windows Boot Problems as Flyer mentioned and was able to boot into the restored image.

A quick note regarding the issue that caused the system to become unbootable when I first began trying to restore my old PC to new hardware. After successfully completing the MRB to GPT conversion the drive became unbootable again. After a restore, I carefully removed the old drivers and was able to identify the culprit as the Intel Extensible Host Controller, which means the boot inaccessible problem was not related to the disk layout. I ended up leaving the driver on the system but made it uninstallable.