ONTAP 9.19.1 expands Foreign LUN Import (FLI) by adding iSCSI backend support, giving more SAN teams a built-in, no-cost, ONTAP-native path to move block workloads from qualified third-party and ONTAP source arrays to modern NetApp storage. Since the first introduction in ONTAP 8.3, FLI has simplified LUN migrations by keeping data movement in the storage layer instead of pushing complexity to each host. Until now, many Ethernet-standardized and iSCSI-centric environments could not use that workflow without Fibre Channel (FC) connectivity. With ONTAP 9.19.1, FLI supports both FC-based and iSCSI-based migration designs across ONTAP SAN platforms, including AFF, ASA and FAS. This helps customers preserve existing network standards, reduce host-side effort, and bring more storage migration projects into a consistent, ONTAP-managed process. It removes the operational complexities when upgrading from legacy third-party storage from vendors such as Dell, HPE, HDS, and Pure Storage to ONTAP by making migration simpler, faster, built in, and less dependent on host-by-host cutover work.
For Ethernet-standardized SAN teams, this reduces host-side effort, simplifies migration sequencing, and improves operational control. Figure 1 shows FLI migrating one or more LUNs from a foreign source array to an ONTAP destination over either iSCSI or FC.
Figure 1) Foreign LUN Import network topology.
Problem Context
Many SAN environments are iSCSI-first and either do not have, or do not want to deploy, a Fibre Channel fabric. These teams still face the same migration pressures as FC environments:
- Move production LUNs from aging arrays on tight timelines.
- Minimize disruption to business-critical applications.
- Avoid host-by-host migration mechanics that expand risk and labor.
Customer Benefits
Customers gain greater migration flexibility with less operational friction. Instead of ruling out FLI because FC infrastructure is unavailable, teams can assess it based on workload fit and migration risk.
Expected outcomes in supported environments include:
- Accelerate migration programs by running storage-led LUN imports in parallel.
- Reduce host migration overhead and simplify change coordination across application teams.
- Preserve host-facing protocol flexibility because the backend import transport does not dictate the final host-access protocol after migration.
- Scale execution with governed parallel imports that account for latency, workload priority, and migration sequence.
- Improve cutover predictability through a repeatable LUN-level workflow.
A Practical Example
A mid-sized enterprise runs VMware and SQL Server on a third-party iSCSI SAN array and has no Fibre Channel infrastructure. The team must move dozens of production LUNs from an aging array to a faster, more capable NetApp system within a narrow maintenance window. With ONTAP 9.19.1, it can preserve its Ethernet SAN architecture, use iSCSI-based FLI backend connectivity, and migrate multiple LUNs through a consistent ONTAP workflow. This enables faster migration, simpler maintenance planning, and far less host-side effort than host-based copy methods.
Technical Breakdown
FLI remains a storage-led copy workflow. ONTAP uses iSCSI to discover and mount the foreign LUN, creates a same-size destination LUN, establishes the import relationship, and copies blocks in the background to keep the source and destination aligned during the import.
FLI operates at the LUN level rather than the volume level, so it applies whether customers use a strict 1:1 volume-to-LUN model or place multiple LUNs in the same volume.
Operational Guidance
During online imports, host I/O and import copy operations compete for backend resources, so plan concurrency conservatively and validate it before production waves. Treat the FLI concurrency limit as specific to a source-controller-to-ONTAP-destination-controller pair, not as a cluster-wide, SVM-wide, portal-wide, or universal planning value. Although FLI can support up to 32 concurrent imports for that pair, it’s not recommended to size migration waves to the maximum by default. NetApp typically finds the performance sweet spot between 8 and 16 concurrent imports. Start with 8 concurrent imports per validated source-destination controller pair, then adjust only after dry-run testing confirms acceptable application latency, import throughput, source-array utilization, destination-array utilization, and network behavior for the source array and workload mix. If multiple source or destination controllers are used, validate and plan each source-destination controller pair independently.
Run several dry migrations before scaling to verify the configuration and establish a realistic performance baseline:
- Confirm that FLI is configured correctly and that the source and destination arrays can communicate.
- Use dry runs to measure import performance and identify a concurrency level that balances throughput, migration duration, and application latency.
If latency affects production workloads, FLI can be paused and resumed from its last checkpoint.
Getting Started
Use this quick-start path to operationalize iSCSI-based FLI:
- Confirm ONTAP 9.19.1 prerequisites before planning the migration wave. Verify interoperability for the required ONTAP platforms—FAS, AFF, ASA r1, and ASA r2—and confirm that the intended FLI transport, whether iSCSI-based, FC-based, or both, is supported across the source array, ONTAP target, and network or fabric configuration. Validate source-array qualification before proceeding.
- Identify the workloads and migration candidates in scope.
- Map all LUNs associated with each workload.
- Build an import schedule by workload and LUN group, accounting for criticality, size, and maintenance windows.
- Validate iSCSI backend pathing, initiator settings, and security controls.
- Run dry tests on non-critical or test LUNs to verify configuration, measure latency and throughput, and confirm the procedure.
- Set concurrent import counts based on application latency guardrails, not theoretical maximums.
- Execute production waves with defined cutover criteria and pause/resume checkpoints.
- Define success criteria for each wave—latency thresholds, copy time, and host validation checks—before scaling to larger batches.
For More Information
For more information about FLI, visit the FLI documentation hub.