Migrate Ubuntu to a New SSD via Cloning (September 2026)

If you have ever opened your computer and heard a drive click its last breath, you already know why people search for migrating a working Ubuntu install to a new SSD by cloning the root filesystem. The good news: you do not have to reinstall Ubuntu from scratch, reconfigure every package, and reimport your data. You can clone your existing system to a new SSD and keep everything intact.

In this guide, I walk through four practical methods I have used over the years on real Ubuntu boxes, from a 14.04 laptop to a fresh 24.04 server. You will learn how to prepare your disks, clone them with the right tool, fix the UUID and fstab issues that cause most boot failures, and reinstall GRUB so the new SSD boots cleanly. Let us get started.

Why Clone Instead of Doing a Fresh Install?

Cloning your Ubuntu installation preserves every package, dotfile, and system tweak you have built up over months or years. A fresh install means hours of reinstalling drivers, reapplying tweaks, and copying data back. When the goal is just bigger storage or a healthier drive, cloning is almost always faster.

That said, cloning is not always the right call. If your current install is full of leftover configs from old experiments, or if you are switching to a new architecture, a fresh install is cleaner. For most users who just want more space or a working drive, cloning wins.

What You Need Before You Start

Before you touch any drive, gather these items so you do not get stuck halfway through the process.

1. A USB flash drive with at least 4 GB of space for a live Ubuntu environment or Clonezilla.

2. The target SSD already installed in your machine, or a USB SATA adapter if it lives outside.

3. A complete backup of anything you cannot afford to lose. Cloning is safe, but a wrong command can still erase the source drive.

4. Basic terminal comfort. You will be running lsblk, blkid, and a few other commands.

5. Your Ubuntu install media, or a second live USB, to chroot into the new SSD after cloning.

Warning: Never run both the source and target drives live at the same time when you do a block-level clone. It is too easy to mix them up and overwrite your good drive with empty data. Always clone from a live USB environment.

Identify Your Source and Target Disks

The single most important step in any cloning workflow is knowing which drive is which. I learned this the hard way early in my Linux career, and I have never skipped the check since.

Boot from your live USB and open a terminal. Run lsblk to list every block device on the system.

lsblk -o NAME,SIZE,MODEL,SERIAL

Then run sudo lshw -class disk -short for a more detailed view that includes the serial number of each drive. Write down the device name (for example, /dev/sda or /dev/nvme0n1) and the model of your source drive and your new SSD. Cross-check by matching the serial number printed on the drive label.

Choose Your Cloning Method

Each method has tradeoffs. Here is the quick comparison I wish someone had given me on day one.

Clonezilla is the easiest whole-disk clone, handles GPT and MBR, and runs from a dedicated live USB.
GParted is best when you only need to copy a single non-LVM root partition to a larger drive.
dd or pv is a low-level block copy that clones every byte, including blank space, so it is slower but extremely faithful.
rsync is a file-level copy that gives you the most control over what gets transferred, at the cost of more post-clone configuration.

Method 1: Clonezilla (Easiest for Whole-Disk Clones)

Clonezilla is the tool most recommended on Reddit and the Ubuntu Discourse, and for good reason. It is free, reliable, and handles UEFI, BIOS, LVM, and tricky partition layouts without complaining.

1. Download the Clonezilla live ISO and flash it to a USB drive using Balena Etcher or dd.

2. Boot from the Clonezilla USB. Choose device-image or device-device. For a direct SSD-to-SSD clone, choose device-device.

3. Select beginner mode, then disk-to-local-disk.

4. Pick your source disk (the one you identified with lsblk) and your target disk (the new SSD).

5. Confirm the operation. Clonezilla will warn you that the target disk will be overwritten.

6. Wait for the clone to finish. A 500 GB SSD typically takes 30 to 60 minutes on a SATA connection, and around 10 to 15 minutes on NVMe.

Once Clonezilla finishes, shut down, remove the old drive, and try booting from the new SSD. If it boots, you are done. If not, skip to the post-clone section below.

Method 2: GParted Partition Copy (Best for Non-LVM Single Partition Moves)

If your Ubuntu install uses a simple partition layout (no LVM), GParted is the most approachable option. It runs from a live environment and lets you copy partitions visually.

1. Boot from an Ubuntu live USB and launch GParted.

2. Identify your source partition and select it. Choose Partition, then Copy.

3. Select the target SSD in the device dropdown at the top right.

4. Right-click the unallocated space on the target and choose Paste. GParted will warn you if the new partition is smaller than the source.

5. Apply all operations and wait for the copy to complete.

6. If the new SSD is larger, drag the partition boundary to fill the extra space, then apply.

You will still need to update the UUID in fstab and reinstall GRUB before the new SSD boots. GParted does not do that for you.

Method 3: dd or pv Disk Imaging (For Advanced Users)

The dd command copies a drive at the block level, which makes it perfect for cloning an entire disk or partition byte-for-byte. Wrap it in pv if you want a progress bar, since dd is famously silent.

sudo pv /dev/sda | sudo dd of=/dev/sdb bs=64K conv=noerror,sync

Replace /dev/sda with your actual source drive and /dev/sdb with your target SSD. Triple-check the device names. After the copy, you may need to fix the partition table with gdisk so the target SSD uses all of its space, especially when migrating to a larger drive.

sudo gdisk /dev/sdb

Use the w option in gdisk to write a fresh partition table that reflects the new size, then reboot into the live USB and use GParted to grow the last partition into the unallocated space.

Warning: dd does not show progress by default. If you skip pv and the clone stalls, you cannot tell whether it is working or hung. Always use pv on large drives.

Method 4: rsync File-Level Copy (Most Flexible)

The rsync method is the one I reach for when I want fine control over what gets copied, especially when the target SSD is much smaller than the source and I need to exclude large directories.

1. Partition and format the target SSD with GParted. Create an EFI System Partition (if UEFI), a root ext4 partition, and a swap partition if you want one.

2. Mount the target root partition at /mnt and the target EFI partition at /mnt/boot/efi.

3. Run rsync to copy everything from the source root filesystem to /mnt, excluding pseudo-filesystems.

sudo rsync -aAXv / /mnt/ 
  --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"}

After rsync finishes, generate new UUIDs with sudo blkid, edit /mnt/etc/fstab to use them, then chroot into the new system and reinstall GRUB.

Post-Clone: Fix UUIDs and fstab

Every partition has a UUID, and fstab references partitions by UUID instead of by device name. After cloning, the new SSD has different UUIDs than the old one, so the kernel will fail to mount the root filesystem on boot.

1. Boot the live USB again and mount the new SSD root partition.

2. Run sudo blkid and copy the UUID of the new root partition.

3. Open /mnt/etc/fstab in a text editor and replace the old UUID with the new one for every entry.

4. Save the file and unmount.

If you skip this step, you will get dropped into an initramfs shell on the next boot. Updating fstab before rebooting prevents that entirely.

Reinstall or Update GRUB Bootloader

GRUB lives in a small dedicated area of the disk and needs to know where the new root filesystem is. After any block-level or partition-level clone, you should reinstall it.

1. From the live USB, mount the new SSD root partition at /mnt and the EFI partition at /mnt/boot/efi if you are on UEFI.

2. Bind mount the kernel filesystems: sudo mount –bind /dev /mnt/dev, then the same for /proc and /sys.

3. Enter the chroot: sudo chroot /mnt.

4. Run sudo update-grub to detect the new kernel and root filesystem.

5. For BIOS systems, run sudo grub-install /dev/sdX where sdX is the target SSD. For UEFI, run sudo grub-install –target=x86_64-efi –efi-directory=/boot/efi –bootloader-id=ubuntu.

6. Exit the chroot, unmount everything, and reboot.

Resize the Filesystem on a Larger SSD

Most users migrate to a bigger drive. Once the clone finishes, the partition on the new SSD will match the size of the old one, leaving unallocated space behind.

Boot from the live USB, open GParted, right-click the last partition on the new SSD, choose Resize/Move, and drag the right edge to fill the empty space. Apply the change. The filesystem will grow to fill the partition automatically.

Migrating a Working Ubuntu Install to a New SSD by Cloning the Root Filesystem: Troubleshooting

Even with a perfect clone, things can go wrong on the first boot. Here are the issues I see most often, and the fixes that have worked for me.

System drops to initramfs shell. This almost always means fstab still points to the old UUID. Boot the live USB, fix the UUID entries, and reboot.

Black screen with no boot menu. GRUB is not installed on the new drive. Boot the live USB, chroot into the new root, and reinstall GRUB to the correct device.

GRUB rescue prompt with unknown filesystem. The BIOS or UEFI is looking for GRUB on a drive that no longer has it. Enter the BIOS, change the boot order so the new SSD is first, and try again.

LVM volume not found. If your old install used LVM, run sudo vgchange -ay inside the chroot to activate the volume group before mounting or running update-grub.

Clone is suspiciously fast (under a minute). You probably cloned an empty disk or accidentally swapped source and target. Verify with lsblk and start over.

FAQ

Conclusion

Migrating a working Ubuntu install to a new SSD by cloning the root filesystem is one of those tasks that feels intimidating the first time and routine the fifth time. Pick the method that matches your setup, back up first, and remember the post-clone essentials: new UUIDs in fstab, a fresh GRUB install, and a resize step if you went bigger.

Take it slow, verify each step with lsblk and blkid, and you will end up with a faster, healthier Ubuntu system and zero lost data.