most common reason you'll run into a disk signature collision is when a drive has been cloned, sector-by-sector, to make an identical copy, and is then attempted to be mounted, or used, alongside the original.

No such procedure exists to allow this.

Neither dell nor microsoft support this.

@speedstep :

most common reason you'll run into a disk signature collision is when a drive has been cloned, sector-by-sector, to make an identical copy, and is then attempted to be mounted, or used, alongside the original.

But if the original is removed or wiped, then the clone should work nonetheless, correct? @RobervalChocolat , is that the goal?

What machine model ?

Sounds like you are using procedures that used to work on Legacy-BIOS machine, and this is UEFI/SecureBoot.

You can use Macrium-Reflect, Image system (and HDD) to a file.

Connect only SSD, boot Macrium-Rescue USB, Restore file (to bare metal).

I didn't wipe the original one. Let me try that.

ssd to ssd is not an issue

HOWEVER HDD to SSD is a problem because SSD's do not do well when indexed and defraggged etc.

AHCI vs IRRT is also a STOP 7B issue.

Lastly MBR to UEFI is not a simple copy.

The F: drive in my Aurora R7 is an exact clone of my C: drive, UEFI/secure boot (at least, they started out that way; stuff has been added to it since.)  I have both SSDs installed concurrently, never had a boot problem. I can boot via F: using F12 one-time boot.   My F: drive is mainly for backups. 

you have signature collision issues and or corrupted UEFI GPT

exact cloning has other problems including duplicate SID

Drive Letters are irrelvant this is not MBR. Disk signature collision is when a drive has been cloned, sector-by-sector, to make an identical copy, and is then attempted to be mounted, or used, alongside the original.

GUID GPT disk signatures are not trivial

"The disk is offline because it has a signature collision with another disk that is online."