From NetApp ONTAP to TrueNAS

NetApp ONTAP is a capable platform, but it stacks per-capacity software licensing and per-feature add-ons on top of premium hardware, with refresh cycles tied to support contracts. TrueNAS (ZFS, from iXsystems) is the most common open destination for file and block storage: snapshots, replication, and compression on commodity hardware, with an optional Enterprise tier for HA and support. The migration is mostly data movement plus re-presentation, but sizing for performance is where teams get it wrong.

What maps, and what’s different

ONTAP and ZFS share concepts but not mechanics:

• Aggregates → ZFS pools (vdevs). Plan vdev layout (mirror vs RAIDZ) for your IOPS/latency target, not just usable capacity.
• SVMs / volumes → ZFS datasets and zvols. Datasets for NFS/SMB shares; zvols for iSCSI LUNs.
• Snapshots → ZFS snapshots, and SnapMirror → ZFS replication (zfs send/recv, or TrueNAS replication tasks).
• FlexClone → ZFS clones.
• Dedup/compression → ZFS inline compression (lz4 by default; dedup exists but is RAM-hungry, usually leave it off).

The gaps worth naming: ONTAP’s MetroCluster, some SnapMirror-to-cloud workflows, and certain NAS protocol edge cases don’t have one-to-one TrueNAS equivalents. Inventory the features you actually depend on.

Size for IOPS, not just terabytes

This is the classic storage-migration mistake. Match the new system to the IOPS, latency, and throughput you have today, not only the usable capacity. ZFS performance depends heavily on vdev topology, RAM (ARC), and an optional SSD/NVMe cache or SLOG for sync writes. Plan N+1 redundancy and budget 20–30% headroom for snapshots and replication overhead.

Getting the data across

There is no SnapMirror path that speaks ZFS, so the data moves at the host or protocol level, and the method depends on the workload. For NAS data, mount both the ONTAP share and the destination TrueNAS dataset on a staging host and copy with rsync, preserving ownership, ACLs, and sparse regions. Run it in repeated incremental passes while ONTAP stays live and serving clients, so the final cutover sync is small and fast. For VM datastores, let the hypervisor do the work with storage vMotion, drifting guests from ONTAP-backed datastores onto the new TrueNAS targets one at a time. For block LUNs consumed by physical hosts, a host-level copy from the old device to the new one is the reliable path. Working per workload keeps each move to a short, contained window rather than a single risky bulk copy.

Migration mechanics

1. Inventory LUNs, volumes, shares, capacity, IOPS/throughput, snapshot schedules, and replication/DR relationships. Confirm host connectivity (FC/iSCSI/NFS/SMB) and multipathing to TrueNAS.
2. Provision TrueNAS pools and datasets/zvols sized for performance; configure NFS/SMB shares and iSCSI targets.
3. Move data by the path that fits each workload: rsync for files (preserve permissions, ACLs, and sparseness), storage vMotion for VM datastores, or host-level copy for block. For object, use rclone.
4. Re-present LUNs/shares from TrueNAS, update mounts/initiators, and rescan/verify multipath.
5. Validate capacity, IOPS, and latency against the ONTAP baseline; run a snapshot/replication/DR test and a data-integrity check.
6. Cut over in maintenance windows, host-group by host-group, keeping the ONTAP array available as fallback through hypercare.

Wiring LUNs and shares back up on ZFS

The re-presentation step is where ONTAP habits meet ZFS mechanics, and it pays to be deliberate about it.

For block, each ONTAP LUN becomes a ZFS zvol exported through an iSCSI target. Recreate the target portal, the initiator groups (mapping the same host IQNs), and the LUN-to-target assignments on TrueNAS. Keep a one-to-one LUN-to-zvol mapping where you can, because it keeps rollback simple: the original ONTAP LUN stays intact and unmapped until the new copy is verified in production. After you re-point a host’s initiator, rescan and confirm multipath sees the expected number of paths before you put load on it.

For file, NFS exports and SMB shares become ZFS datasets with the appropriate share service enabled. Export policies and NFS client rules need to be rebuilt as TrueNAS NFS share settings; SMB shares need their share-level permissions and the underlying dataset ACLs recreated. This is the part that most often surprises teams, so treat it as its own validation step rather than an afterthought.

Proving the latency holds up

Sizing for IOPS is only half the job; you have to prove it. Capture the ONTAP baseline before you touch anything: IOPS, throughput, and read/write latency at the queue depths your workloads actually run. Then replay a representative load against the ZFS pool and compare latency under load, not just peak sequential throughput, because the two can diverge sharply.

ZFS latency behaviour depends on things ONTAP hid from you. Random-read latency leans on ARC (RAM) and any L2ARC; sync-write latency leans on whether a fast SLOG device is present. If your workload issues a lot of synchronous writes (databases, some NFS datastores), a proper SLOG is often the difference between acceptable and painful latency. Tune the vdev topology, RAM, and cache devices first, then benchmark, then trust the numbers.

A migration-day gotcha

SMB/NFS permission and ACL fidelity is where file migrations bite. Test a representative share end to end, including Windows ACLs and any cross-protocol (NFS+SMB) access, before mass-migrating, and confirm your backup/replication jobs re-establish on the new pool.

Is it worth the trade

NetApp ONTAP → TrueNAS removes the per-TB software tax in exchange for owning the storage design. The data movement is routine; the make-or-break decisions are vdev/IOPS sizing and ACL fidelity. Provision for performance, test one LUN/share end to end, then migrate host-group by host-group with the array as fallback. Model your per-TB savings in the calculator above, and treat them as illustrative until you validate performance against your real workload.