I presume you already got though the task one way or the other but if not (and for other future readers): You cannot go from UFS to ZFS in place either while running live or from a separately booted disk. Depending on the size of the drive, layout of partitions, and used space, there might be things you can do. 1st party software allows UFS and ZFS partitions/pools to grow in size. 3rd parrty software can move and resize (grow only?) UFS. Converting partitions in place, though theoritally possible, is not something I have seen with either UFS or ZFS support. Might be able to move ZFS but I haven't seen anything offering to shrink it which is what is needed to do this in place easily (assuming <50% disk consumed).
In addition to an external drive and ramdisk, consider if you have enough space in separate partitions & unallocated space to hold the data. If you have a swap partition but nothing swapped then you could use swapoff and then repartition it to temporarily/permanently hold data. If you have multiple UFS partitions, think about if you have enough space in them to temporarily hold data. Any partition you can empty is now usable to reformat to be a ZFS pool. It would be best to not resize a ZFS pool and if you need to do it then minimizing the amount it is resized by is best but you could grow a ZFS partition and its containing pool by extending its end (don't think start can be moved/resized).
If you need <50% of the drive for the data, make sure you don't make a partition bigger than that and then if it is at the back you can make a new one in the front to copy data to 1 last time and resize it to full size (or keep it in 2 halves for easy internal data shuffling in the future). ZFS dedupe is likely not too beneficial to get a good savings but is another consideration to "temporarily" make the migration happen. You will need to recreate any deduped ZFS data to remove the dedupe. ZFS block cloning would be an alternative to save disk space if you have duplicates but will require manual intervention (enabling the feature, then manually ordering a copy of data to create the 2nd copy appropriately).
Think about how much of the data you need vs what is just downloaded from the internet. Things that can be readily redownloaded could be deleted/uninstalled to get back space for the temporary task. For programs, most you can put back when you are done (as long as official packages aren't removed before install command). While there, think about if you have unneeded data that you would remove but only when you usually get around to it: .core files from crashed programs, /tmp entries that aren't set/scheduled to autodelete, logs you don't need, etc. Depending on the data, you can consider if ZFS filesystem compression or 3rd party compressors (xz,. zpaqfrans (has its own deduplication capability), etc. could make data fit in a small enough space to successfully wiggle things around. 3rd party comressors can get better results iwth special options passed to them, custom disctionaries, and preprocessing steps. ZFS compression may be improved by altering the record size but depending on the data its not always the biggest for smallest filesize.
Similarly, you could temporarily or permanently reformat some types of data to take less space. Undoable lossless changes can be done to jpeg with jpeg-xl or a lossless (different data but pixel perfect recreation of the jpeg) with jpegtran. audio/wavpack can losslessly store wav files in a compressed format that can be undone or audio/flac can store files at a similar but slightly smaller size with better compression settings, some less compatible settings, and some trial+error. graphics/optipng, graphics/oxipng, graphics/pngquant, and graphics/pngrewrite can help with lossless (were some of these lossy?) png pixel perfect shrinking. There are other lossless reoptimizers for mp3, zip, xz, etc. files though I don't know which tools we have available directly on FreeBSD for it. Windows has fileoptimizer which runs each compatible file through a collection of utilities to optimize the file; manual efforts can still sometimes beat it. If you have a lot of open document format (libreoffice/openoffice/etc.) files, some programs write a (png?) thumbnail to each file, which can make a file significantly larger than otherwise needed; you have to open+resave each file manually after changing a (somewhat hidden) setting in libreoffice to remove them. If you have a lot of zip or other compressed files/archives, they normally compress to take less space if you extract them and compress them all into 1 file; other than manual workflow to do it+undo it you wuold need software like precomp (not yet ported to FreeBSD) to handle it (works for zlib created zip streams+a few other things).
If using a ramdisk, keep in mind that data that is only stored there is at risk of being lost from any computer failure until rewritten to disk. If you increased ZFS filesystem zstd compression, you may need a lot of RAM for it to work and ZFS dedupe definitely needs RAM.
If you do a migration instead of a reinstall (external disk or not), review if you need to make startup changes: fstab vs zfs properties to mount things, does ZFS need to be manually loaded, etc. for legacy/CSM/MBR booting, you need to make sure you use the ZFS compatible loader if you don't keep a small UFS around just for booting.
