Everon is definitely right, ZFS is great at compression for compressible files and uses dynamic record sizes (ZFS equivalent of a cluster) so small files don’t waste space and you can set record sizes up to 1MB so large files are stored much more efficiently as well.
As for migrating TO ZFS, depending on how sensitive you are to redundancy eating capacity and also to performance, ZFS can be pretty easy to migrate into piecemeal using mirroring. If you’re going to do any level of RAIDZ (parity modes like RAID5/6), you really want don’t want to have to expand that much as it’s best done in multiples of the same number of disks. But, if you start with 2 drives in a mirror, and then simply add disks 2 at a time as you migrate data into it from your old system, it’ll be fine. It’s not optimal doing it that way as you end up with data unevenly distributed between vdevs, but it’ll work and you’ll gain all but the performance benefits of ZFS in the process. It won’t be too slow, you’ll still get the performance of a 2 drive mirror which is more than enough to max out most home network connections.
If the data is backup worthy, then ideally you could either restore from that backup to a fresh, full size ZFS array. Or if you did the piecemeal import and you want to rectify that to optimal performance, build a large enough ZFS array on your backup system and then you do a ZFS send to the backup system, then rebuild/empty the primary servers ZFS pool and ZFS send the backup copy back to the primary. This could also be done on a single server as well.
The point is, you get a ton of flexibility with ZFS which makes it pretty fantastic in my view, for most any kind of file serving duty.