move system to new SSD with dd command

Any time you use dd (a.k.a. disk destroyer) there is a potential for messing up your data. dd has no safeguards for accidentally writing your new drive over the old drive. The only thing keeping it working right is if you're VERY careful with typing the commands correctly and not mixing up the source and destinations. if= and of= are only one small mistyped keystroke away from each other!

The other problem is that dd is slow and puts unnecessary wear on your target SSD. Most partitions are typically no where near 100% utilization. Using dd to copy a partition with lots of free space ends up copying EVERY BYTE of said partition, even the bytes that aren't actually containing any allocated data!

Here's what I would do if it were my system:

1. Take a screenshot of your old SSD's partition table for reference later when we set up your new SSD's partition table.
2. Connect the new SSD to the computer and disconnect the old SSD. Keeping the old SSD disconnected makes it impossible to destroy any of our precious data while we do potentially destructive work.
3. Boot from the Ubuntu installation USB thumb drive in Linux live mode. Make sure your BIOS always boots the thumbdrive in legacy/MBR mode instead of UEFI mode, since it sounds like your old system is using MBR. If my assumption is invalid, make sure your BIOS boots the thumbdrive in UEFI mode instead. Mixing things up would make it a lot harder to get grub to install properly later on.
4. Use gparted to set up your new SSD with the desired partition table and format the filesystems. Try to keep everything the same as your old SSD's partition table (aside from partition sizes and UUID's). Don't forget to mark the / root filesystem as active / bootable, just like your old SSD.
5. Now that all the dangerous partition editing stuff is done, you can safely shutdown and add the old SSD connected to the computer.
6. Boot the Linux live USB thumb drive again with both drives connected this time. Do not boot from the old SSD (we need to keep that system inactive to make a good clean copy of it).

7. Once booted, open a terminal and start working through these commands to copy the data from your old SSD to your new SSD. Unlike using dd, the cp command is far more error-proof because you can't destroy anything copying an empty file system over top of your old file system -- there is nothing copied in that case! Plus, we can mount the old SSD in "read-only" mode to avoid any possibility of modifying the old SSD.

   mkdir oldroot newroot oldhome newhome
   sudo mount -o ro /dev/sda1 oldroot
   sudo mount -o ro /dev/sda2 oldhome
   ls oldroot
   ls oldhome
   

   Verify that you can see your old data. If all you see is an empty file system, perhaps you've got the wrong "/dev/sdXX" device...

   sudo mount -o noatime /dev/sdc1 newroot
   sudo mount -o noatime /dev/sdc2 newhome
   ls newroot
   ls newhome
   

   Verify that all you see is an empty file system as your destination. If everything is good, issue the following commands to copy all of your files while preserving all the permissions/ownership/SELinux context settings:

   sudo cp -Rfax oldroot/* newroot/
   sudo cp -Rfax oldhome/* newhome/
   

   Once that's done, unmount everything and sync cached writes to persistent storage:

   sudo umount oldroot
   sudo umount oldhome
   sudo umount newroot
   sudo umount newhome
   sync
   

8. Now you can safely shutdown and disconnect the old SSD so that we can't possibly destroy anything on it while we work through making the new SSD bootable.

9. Boot the computer using the USB thumb drive in Linux live mode with only the new SSD connected. Open a terminal and start working through these commands:

   mkdir newroot
   sudo mount -o noatime /dev/sda1 newroot
   sudo chroot newroot /bin/bash
   mount -t devtmpfs udev /dev
   mount -t proc proc /proc
   mount -t sysfs sysfs /sys
   nano -w /etc/fstab
   

   Now you need to modify the fstab file to match the UUID numbers to whatever they are on your new SSD. You can open gparted to look at your partition table and figure out what the new UUID's are. When done, hit CTRL-X and save the fstab changes to disk.

   update-grub
   grub-install /dev/sda
   

   If everything is working right, this should configure grub and install it into your new SSD's MBR. After grub is installed, you have to unmount all the stuff we previously mounted from within the chroot environment before exiting. Otherwise, Ubuntu will have a hard time unmounting the Linux partition cleanly when you shutdown.

   umount /sys
   umount /proc
   umount /dev
   exit
   sudo umount newroot
   sync
   

And there you have it! Hopefully your new SSD is bootable and everything is good now.

I just used gparted to migrate my ubuntu 18.04 from one SATA to another. Gparted provides an easy to use GUI with copy and paste options, and even the UUIDs are the same so I didn't have to update /etc/fstab or install grub on the new disk. It was very smooth, so I haven't check out what happened underneath yet, but during the copy-paste process, e2image(8) was actually invoked. Again, this was all based on my own experience, please correct me and thank you guys.

I would use partimage to copy the partitions one at a time. After you copy the first partition, increase its size. The resize will be very fast because you won't have to move any adjacent partitions. Then copy the second partition and resize it to fit the rest of the space.

The easiest way to do this is to boot from SystemRescueCD and do everything from that environment. You can make a bootable USB drive so you don't need an actual CD.