In LINUX: Using dd to transfer shrunk partitions on a 2TB HDD to a 500GB SSD

A source HDA (2TB mechanical HDD) has 5 partitions on it (GPT) that used to occupy the entire capacity of the 2TB HDA. The Operating System resident on the source drive *is* Windows 10. Since the majority of the 'data' partition was unused storage space, and occupied 1.5TB of the drive capacity, it was shrunk, using gparted, to about 350GB, and the 'Push Button Recovery' partition (above it on the source HDA) was moved downward to be contiguous with the data partition. The resultant state of the source HDA is 5 partitions occupying less than 400GB on a 2TB HDA, with the excess storage space on the drive being unallocated space. Proposed target device is a Samsung 500GB SDD, which is currently in an unallocated state (no partitions defined and no boot structures written to the drive). Hypothesis: I can use dd (bs=1M, no count parameter specified) to write directly from the source device to the target device, since the aggregate partition sizes on the source device amount to less than the capacity of the target device; and have only an anomalous condition in what will be the unallocated space that results on the target device, post transfer. Addressing this anomalous unallocated region of the target device by relocating the 'Push Button Recovery' partition to the upper end of the drive space, and growing the data partition to fill the remainder of the unallocated space on the target device, using gparted should work and leave me with a bootable device. Question: I don't tinker with windows systems unless I get backed into a corner by somebody else (like a family member), so I do not have a great deal of intuition in dealing with such situations; so, can anybody see why this would produce a non-bootable target SSD before I waste the time doing this? # # # # # # UPDATE # # # # # # OK....I'm following-up on this--merely to let others know what ultimately worked in this particular situation: Partition arrangement on the source HDD: Partition FS Label Size Flags /dev/sdg1 ntfs Recovery 600 MiB hidden, diag /dev/sdg2 fat32 ESP 300 MiB boot, esp /dev/sdg3 unknown 128 MiB msftres /dev/sdg4 NTFS User Data Space 350 GiB msftdata /dev/sdg5 NTFS Push Button Reset 16.61 GiB hidden, diag Unallocated -- -- 1.5 TiB -- Partition arrangement on the target SSD: Partition FS Label Size Flags /dev/sdh1 ntfs Recovery 600 MiB hidden, diag /dev/sdh2 fat32 ESP 300 MiB boot, esp /dev/sdh3 unknown 128 MiB msftres /dev/sdh4 NTFS User Data Space 448.15 GiB msftdata /dev/sdh5 NTFS Push Button Reset 16.61 GiB hidden, diag A lot of time was spent trying various approaches to addressing the issue at hand, with unsatisfactory results. Because allocated time was expiring, the installed OS recovery facilities were used to create 'restore' media, and perform an OS recovery to the SSD installed in the host system. With both drives attached to a Debian 8.5 based computer, partclone_0.2.73-2+b1 (partclone.ntfs) was used to write the user data partition from the source HDD to the the target SSD. (/dev/sdg4 to /dev/sdh4) While a windows-agnostic solution is preferred, this method produces a bootable target SSD with all original user data intact, and mismatches between partition tables were avoided. Info on partclone can be found at: https://packages.debian.org/jessie/admin/partclone https://packages.debian.org/stretch/admin/partclone https://manpages.debian.org/testing/partclone/index.html