It's all about how much risk you are willing to take. IIRC a failed ZFS (lose more drives than you have redundancy) is the same as a failed raid 0, data is effectively gone.
If this is the ONLY place you have data, I *personally* wouldn't degrade the volume to do a transfer. 60% full isn't anywhere near a critical problem, especially if you haven't done any housecleaning yet. If you have old (un needed) snapshots taking up space, or duplicate files you can *manually* clean up (ZFS de-dupe is powerful, but easy to screw yourself if you go in blind). IF you haven't turned on compression, DO SO (IIRC, you will need to re-add existing files to compress them but that could be done in batches).
If you DO have backups, or this is your backup for everything on the volume my *personal* path of balanced risk would be:
1. One by one pull AND VERIFY drives from each VDEV leaving one disk redundancy IF you need those drives for step 2
2 A. Assuming the volume is fairly under-filled: Build a new VDEV of at least raidz1 with compression on. If possible with drives you won't be using in the final volume. Verify everything transferred and create the new final volume (finally using the drives from the original volume if desired) and transfer again. If you are short on disks during the transfer (assuming raidz2 or raidz3), you can use a sparse file as a member of the VDEV and then *DELETE IT* before attempting to copy data. Once the transfer is complete add any disks required to restore redundancy.
2 B. Figure out your final pool (how many drives per VDEV, how many VDEVs), using spare drives of smaller sizes manually format the drives so that each one maintains a small bit of unused area (besides any cache, like 1GB or less should be enough, this could make life easier for you later) Use one or more of the existing pool's drives if needed, while maintaining at least one disk redundancy per VDEV. If you are short on disks during the transfer (assuming raidz2 or raidz3), you can use a sparse file as a member of the VDEV and then *DELETE IT* before attempting to copy data. Once the transfer is complete add any disks required, first priority is restoring full redundancy if needed, then upsizing the smaller disks with online replacements.
You could mix 2 A and 2B depending on the "drive math". I've actually done 2B in the past, in my case my "final design" included more large drives than I even had at the time of swap, I had to wait to upsize one of the VDEVs until later. Obviously, use drives you trust during the process.