The answer to this depends on the filesystem being used. I've been using UFS for / for ever since I started using FreeBSD (2.0.5) in 1995. At some point in the 1990's rather than install a new machine from scratch I started restoring, using dump piped to restore via rsh and later ssh, all my filesystems from one machine to the new machine, simply updating fstab and rc.conf to have a cloned machine with little effort.
My current laptop, which its filesystems trace their lineage back to that day I cloned my now "prod" machine to my laptop, cloned its new 1 TB SSD from 1 TB hard disk using the same basic approach until this last time.
This time around I used gmirror after booting my old hard disk off USB. gmirror create (not gmirror label) allowed me to do the same while multitasking.
ZFS pools are copied using zfs send | zfs receive.
With this last migration I removed the hard disk, installing it into a USB enclosure and installing the new SSD into the laptop. Then boot my FreeBSD off the USB enclosure -- I use UFS labels while ZFS discovers the zpool. I partitioned the new SSD.
I copied the Windows partition using dd(1).
I then removed the USB and booted each partition to make sure each worked, which they did.
The amount of work I had to was minimal. Though it took most of the night (or maybe not, the zfs send | zfs receive probably finished long before I woke) to copy from hard disk to SSD while I slept.
For ZFS I had to export the pool. Then import the new pool using the old pool's name -- renaming pools on import is a handy feature. That had to be done in single user state because the zpool cache file resides in /etc/zfs. I suppose a person could have done this after the export/import and simply copied the file, saving a reboot. Though the approach I took guarantees that the rename will take without unforeseen problems.
Booting each partition, the three FreeBSD partitions first and finally the Windows partition, it's like the laptop never missed a beat.
Because I use this approach, I haven't installed a new FreeBSD from ISO on my physical hardware for a long time. It's the lazy approach and I'd rather it copy my data while I sleep.
BTW, I've used this same approach back in the day for Solaris UFS and Tru64 UFS when migrating or updating those operating systems too. This approach was not initially developed for FreeBSD. We can do the same with Linux albeit boot blocks are handled differently because of GRUB but copying /boot using this approach and Linux's LVM pvmove will work just as effectively. I've used this approach on not just FreeBSD professionally at $JOB for decades. The idea was borne out by the fact that this is how IBM mainframe upgrades or patches operating systems and the first complaint I made to UNIX vendors when my career switched in the 1990's. It's a time saver. On the mainframe we typically clone, then upgrade. Sun developed the boot environment approach initially to address this problem for UFS and later when ZFS was introduced, and now in FreeBSD.
I tend to think my constant griping and complaining to the Sun systems engineers back in the day may have interested someone enough to send the dissatisfaction upstream to their Online Disksuite developers. Then again, maybe not.
The old hard disk was repurposed for backups.
