Move Windows 10 partition to another location on the same drive and avoid boot problems

Question

I an running Windows 10 on a 2 TB SSD. The drive partition layout looks like this:

enter image description here

01. 208 MB (no drive letter assigned)

02. 159.70 GB NTFS D: (Old Windows 7 installation partition)

03. 380.86 GB Unallocated space

04. 97.66 GB NTFS C: (Current Windows 10 system/boot partition)

05. 292.97 GB NTFS X: (Data drive for my storage)

I want to merge the unallocated space (03) with with the X: drive (05).

I have GParted on a bootable USB and I can move all the partitions on there and merge the unallocated storage using Windows afterwards. I am concerned that if I move these partitions, won't Windows have issues booting unless I modify the boot loader? Right now Windows 10 boots and it will ask me if I want to boot to Windows 7 or Windows 10.

I would like to have this layout:

01. 208 MB (no drive letter assigned)

02. 159.70 GB NTFS D: (Old Windows 7 installation partition)

03. 97.66 GB NTFS C: (Current Windows 10 system/boot partition)

04. 673.83 GB NTFS X: (Data drive for my storage)

What is the proper way to do this to avoid having boot issues after the partitions are moved?

• JW0914: This should not cause any boot issues, as the EFI partition is not being touched; however, if the system does not boot, simply boot to WinRE and issue: bootrec /fixmbr && bootrec /rebuildbcd, then reboot.

Answer 1

You can move C: upward over the unallocated space, then move X: over the newly displaced unallocated space, ending up with the unallocated space below X:, ready to be merged via the resize of X:.

This will not change the numbering of the partitions, since the unallocated space is not a partition and does not have a partition number.

Do not use GParted for resizing Windows partitions, and do not use Windows 7 for resizing a Windows 10 partition (the other direction is fine).

On some old-format disks GParted might warn that moving the starts of file systems is dangerous. In this case, moving any allocated partition is impossible on this disk, because the partitions are identified by their byte-offsets on the disk.

I would advice, before doing any partition work, to take a full backup of the disk and a have a boot media that can be used to restore the backup. This is because even a slight error might make the disk unbootable.

• qroberts: When you say "You can move C: upward over the unallocated space, then move X: over the newly displaced unallocated space, ending up with the unallocated space below X:, ready to be merged via the resize of X:" how do you suggest I move these partitions, with GParted or a partition manager? Thanks!
• harrymc: GParted is OK, especially as you know this tool. Only resizing can become problematic with the wrong tools.
• JW0914: Have you come across where merging unallocated space creates a boot issue that bootrec /fixmbr && bootrec /rebuildbcd did not correct, as I'm not understanding the purpose of either a full disk or partition backup for this scenario.
• harrymc: @JW0914: Murphy's law.
• harrymc: If you are looking for a backup utility, I recommend AOMEI Backupper Freeware.

Answer 2

I primarily stand with @harrymc but I would suggest imaging the whole disk with "Macrium Reflect" as a precaution. You have to select all the partitions on the disk & save its image to another Internal / external disk. You may use KYHI's Recovery ISO.

You don't have to move the whole partitions here or there but only resize them from left / right & you will be through the task:

1. Resize / extend C: from left to fill up the whole unallocated space.

2. Resize / Shrink C: from right to retain its final size as 100GB. ( I would suggest 150 GB )

3. Extend X: from left to include all the space made available after shrinking C:.

All good 3rd party partitioning programs give you a fair chance to know about the actual result before finally executing it. If you have any confusion, you should not apply the changes, and abort the process.

The terminology & options may be a little different from program to program. Take care of it.

• JW0914: Have you come across where merging unallocated space creates a boot issue that bootrec /fixmbr && bootrec /rebuildbcd did not correct, as I'm not understanding the purpose of either a full disk or partition backup for this scenario.
• Vineet Garg: The purpose of full disk image is to have a backup where the EFI, Windows and / or other partitions is / are deleted accidentally. For boot problems, your commands are quite good or one can use Startup Repair 3 times. Macrium Reflect from a rescue disk, can also solve potential boot problems automatically.
• JW0914: I'm not understanding how they could be deleted accidentally, but Windows natively includes a way to backup and restore partitions via DISM /Capture-Image and DISM /Apply-Image that doesn't rely on 3rd party software, proprietary backup formats, or non-standard boot media. The compression algorithms for WIMs are also usually superior to those of 3rd parties.
• Vineet Garg: 1. The objective is to make a full disk image to backup a situation where partitions are deleted accidentally. Surely, that will be the last option to solve a boot problem. 2. I agree DISM command line is very powerful. But the in-built Windows Backup tool is not that powerful & Macrium Reflect is a great alternative to that.
• JW0914: DISM is the built-in backup tool, and more importantly, is included in all WinPE/WinRE images. The Windows Backup GUI functionality is not the same thing as capturing and applying an image via DISM, and using DISM directly is both vastly more efficient and offers more options than both the GUI backup and any 3rd party solution, coupled with the fact WIMs are not bound to the partition or disk structure, whereas almost all 3rd party backup solutions are. If looking for the best tool for backing up [capturing] partition images on Windows, DISM has always been the best tool for the job.