Dell Isilon Migration Guide: Complete Walkthrough for 2026

Dell EMC Isilon (now PowerScale) is one of the most widely deployed scale-out NAS platforms in enterprise environments. Whether you’re consolidating storage, refreshing hardware, or moving to a new platform, migrating off Isilon requires careful planning around OneFS-specific features like SmartConnect, multiprotocol ACLs, and access zones. This guide walks through the full migration lifecycle: from assessment through cutover and post-migration verification.

Pre-Migration Assessment

Before moving a single file, you need a complete inventory of what you’re migrating and how it’s configured.

OneFS Version and Cluster Inventory

Start with a full picture of your cluster:

# Cluster overview
isi status

# Node inventory with hardware details
isi devices list --format=table

# OneFS version (shown in isi status output, or use uname)
uname -a

# License inventory (what you're paying for)
isi license list

Document the OneFS version carefully. Version 8.x and 9.x have different ACL behaviors, protocol defaults, and API capabilities that affect your migration strategy.

SmartConnect Zone Mapping

SmartConnect is Isilon’s DNS-based load balancing. Every SmartConnect zone that clients use needs a cutover plan.

# List all SmartConnect zones
isi network pools list --format=table

# Detailed zone configuration
isi network pools view <pool_name>

# Get DNS settings per groupnet
isi network groupnets list --format=table

For each zone, note:

Field	Why It Matters
Zone name	DNS delegation target
Subnet	Network topology for destination
IP allocation method	Static, dynamic, or SmartConnect
SC DNS zone	FQDN clients use to connect
Connection policy	Round-robin, connection count, etc.

NFS Export Inventory

# List all NFS exports
isi nfs exports list --format=table

# Export details with security settings
isi nfs exports view <export_id>

# Check which zones serve each export
isi nfs exports list --format=json | python3 -m json.tool

Key fields to capture per export:

• Path — the directory being exported
• Clients — allowed client networks/hosts
• Root clients — hosts with root squash disabled
• Map root — identity mapping for root user
• Security flavors — sys, krb5, krb5i, krb5p
• Read-only status

SMB Share Inventory

# List all SMB shares
isi smb shares list --format=table

# Share details including permissions
isi smb shares view <share_name>

# Check share-level ACLs
isi smb shares permission list <share_name>

Quota Audit

OneFS quotas don’t migrate automatically. You need to recreate them on the destination.

# List all quotas
isi quota quotas list --format=table

# Export quota details
isi quota quotas list --format=json > quotas_export.json

Snapshot Audit

Snapshots cannot be migrated directly. Decide what to do with them before starting.

# List all snapshots
isi snapshot snapshots list --format=table

# Check snapshot schedules
isi snapshot schedules list --format=table

# Calculate snapshot space usage
isi snapshot snapshots list --format=json | python3 -c "
import json, sys
data = json.load(sys.stdin)
total = sum(s.get('size', 0) for s in data)
print(f'Total snapshot space: {total / (1024**3):.1f} GB')
"

Options for snapshots:

1. Delete before migration — reduces data volume, fastest approach
2. Export snapshot data — mount the .snapshot directory and copy specific point-in-time data
3. Recreate schedules on destination — new snapshots start after migration

Multiprotocol Considerations

This is often the hardest part of an Isilon migration. OneFS has a unified ACL model that stores both POSIX and Windows-style permissions on a single file. Most other platforms don’t.

How OneFS Handles Permissions

OneFS uses an internal permission model that bridges both Unix and Windows worlds. Files can be in either POSIX mode (standard Unix mode bits) or ACL mode (a richer ACL stored on disk). When accessed via NFS, OneFS presents POSIX mode bits; when accessed via SMB, it presents Windows-style security descriptors. The access zone’s ACL policy controls how changes from each protocol interact.

# Check the global ACL policy
isi auth settings acls view

# Check per-zone ACL settings
isi zone zones view <zone_name>

Three ACL policy environments:

Mode	Behavior
UNIX only	POSIX permissions are authoritative; prevents ACL creation; SMB sees synthesized ACLs
Windows only	NTFS ACLs are authoritative; chmod operations may be rejected
Balanced	Both coexist; OneFS merges permission changes from either protocol

For a deep dive into migrating these permissions correctly, see our Isilon multiprotocol permissions guide.

Identity Mapping

OneFS maps between Unix UIDs/GIDs and Windows SIDs using:

• Active Directory — for domain-joined clusters
• LDAP — RFC2307 attributes for UID/GID mapping
• Local users/groups — for standalone clusters
• Auto-mapping — algorithmic SID↔UID translation

# Check identity mapping configuration
isi auth ads list
isi auth ldap list
isi auth mapping view

Your destination must resolve the same identities. If you’re moving to a Linux-only platform, Windows SIDs won’t exist — you need a mapping table.

Migration Approaches

The Traditional Approach: rsync and Robocopy

Many admins start with rsync (for NFS) or Robocopy (for SMB). These tools are familiar and work, but they hit limitations quickly at Isilon scale:

• rsync is single-threaded — one directory at a time, no parallelism across exports. A 50TB cluster with 20 exports runs as one serial stream.
• Robocopy is Windows-only and has no checksum verification. You’re trusting the copy without proof.
• Neither tool provides a dashboard, ETA, or audit trail. You’re watching terminal output and hoping.
• No incremental awareness — both tools re-scan the entire tree on every run, which gets slow as file counts grow into the millions.

For small Isilon clusters (under 5TB, a handful of exports), these tools are fine. For enterprise-scale migrations, you need something purpose-built.

syncopio: Parallel Dataset Migration

syncopio approaches Isilon migration differently: each NFS export or SMB share becomes a separate dataset within a migration job. Datasets transfer in parallel across multiple workers, with per-file checksum verification.

Isilon Cluster                    syncopio                     Destination
┌────────────────┐              ┌──────────┐              ┌────────────────┐
│ /ifs/marketing │─── NFS ────▶│ Worker 1 │──── NFS ───▶│ /data/marketing│
│ /ifs/finance   │─── NFS ────▶│ Worker 2 │──── NFS ───▶│ /data/finance  │
│ /ifs/media     │─── NFS ────▶│ Worker 3 │──── NFS ───▶│ /data/media    │
│ /ifs/archive   │─── NFS ────▶│ Worker 1 │──── NFS ───▶│ /data/archive  │
└────────────────┘              └──────────┘              └────────────────┘
                                     │
                              ┌──────┴──────┐
                              │ Controller  │
                              │ Progress,   │
                              │ Checksums,  │
                              │ Audit Trail │
                              └─────────────┘

Why syncopio for Isilon migrations:

• Parallel transfers — multiple exports migrate simultaneously across workers
• Built-in discovery scans — inventory your data before moving it
• Checksum verification — every file verified during transfer, not as a separate pass
• Web UI — real-time progress, throughput, and ETA per dataset
• Audit trail — compliance-ready logs of what was moved, when, and verification status
• Incremental updates — only changed files transfer on subsequent runs

Cutover Planning

The cutover is the highest-risk phase. Plan it carefully.

Pre-Cutover Checklist

• Final incremental sync completed (delta < 1 hour of changes)
• Destination permissions verified on sample directories
• Destination quotas configured
• Destination snapshot schedules configured
• DNS TTL reduced to 60 seconds (do this 48 hours before cutover)
• Rollback procedure documented and tested
• Maintenance window communicated to users
• Monitoring configured on destination

SmartConnect DNS Cutover

This is the critical step. SmartConnect zones are typically implemented as DNS delegations from your corporate DNS to the Isilon’s SmartConnect service.

Step 1: Stop writes to Isilon

# Option A: Set exports read-only
isi nfs exports modify <export_id> --read-only=true

# Option B: Restrict client access at the export level
isi nfs exports modify <export_id> --clients=127.0.0.1

Step 2: Final sync

Run your final incremental transfer to capture any remaining changes.

Step 3: Update DNS

# Remove DNS delegation to SmartConnect
# Point the same FQDN to destination IP(s)

# Example: update corporate DNS
# Old: isilon-data.corp.com → delegated to SmartConnect
# New: isilon-data.corp.com → 10.0.1.100 (destination)

Step 4: Verify client access

# From multiple client machines
ls -la /mnt/data/  # Verify mount works
touch /mnt/data/test_write  # Verify write access
rm /mnt/data/test_write

Client Mount Updates

Not all clients use SmartConnect DNS. Some may have hardcoded Isilon IP addresses in:

• /etc/fstab entries
• Autofs maps (/etc/auto.master, /etc/auto.nfs)
• Application configuration files
• Container volume mounts
• Kubernetes PersistentVolumes

Rollback Strategy

Always have a rollback plan:

1. Keep Isilon running for at least 2 weeks post-cutover
2. Don’t delete Isilon data until the migration is fully verified
3. DNS rollback — keep the old SmartConnect delegation config documented so you can re-enable it in minutes
4. Test rollback before the cutover window — verify you can switch DNS back and clients reconnect

Post-Migration Verification

Migration isn’t complete until you’ve verified the data.

File Count and Size Verification

# Source (Isilon)
find /mnt/isilon -type f | wc -l
du -sh /mnt/isilon

# Destination
find /mnt/dest -type f | wc -l
du -sh /mnt/dest

Differences in du output are normal due to filesystem block size differences. File counts should match exactly.

Checksum Verification

For critical data, verify file integrity with checksums:

# Generate checksums on source
find /mnt/isilon -type f -exec sha256sum {} + > source_checksums.txt

# Verify on destination
cd /mnt/dest
sha256sum -c source_checksums.txt | grep -v ": OK$"

This is slow for large datasets. syncopio performs checksum verification during transfer, eliminating the need for a separate verification pass. See why checksums matter for more on verification approaches.

Permission Spot-Checks

# Compare permissions on key directories
diff <(ls -laR /mnt/isilon/finance/ | head -50) \
     <(ls -laR /mnt/dest/finance/ | head -50)

# Check ACLs (NFSv4)
nfs4_getfacl /mnt/dest/finance/restricted/

# Check extended attributes
getfattr -d -m - /mnt/dest/finance/restricted/

Performance Baseline

Establish a performance baseline on the destination so you have a reference point:

# Sequential write
fio --name=seq-write --rw=write --bs=1M --size=10G \
    --directory=/mnt/dest --numjobs=4

# Sequential read
fio --name=seq-read --rw=read --bs=1M --size=10G \
    --directory=/mnt/dest --numjobs=4

# Metadata operations
mdtest -C -T -r -F -d /mnt/dest/mdtest -n 10000 -i 3

Migration Timeline Template

For a typical 100TB Isilon migration:

Phase	Duration	Activities
Assessment	1-2 weeks	Inventory, quota audit, permission mapping
Destination setup	1-2 weeks	Platform deployment, network config, export/share creation
Initial sync	3-7 days	Full data copy (depends on network bandwidth)
Incremental syncs	1-2 weeks	Daily syncs to reduce delta
Permission verification	2-3 days	Spot checks, access testing
Cutover	2-4 hours	Final sync, DNS switch, client validation
Monitoring	2 weeks	Performance monitoring, issue resolution
Decommission	1 day	Isilon shutdown (after verification period)

Common Pitfalls

1. Forgetting SmartConnect zones — every zone needs a cutover plan
2. Ignoring multiprotocol ACLs — POSIX flattening silently breaks Windows access
3. Not testing application access — applications may rely on Isilon-specific behaviors
4. Skipping incremental syncs — a single large cutover window is risky
5. Deleting Isilon data too early — keep it running until verification is complete
6. Overlooking snapshots — clients accessing .snapshot directories will lose access
7. Quota gaps — quotas don’t migrate; users may fill the destination without limits

Next Steps

• Isilon multiprotocol permissions guide — deep dive into ACL migration
• Scale-out NAS compared — Qumulo vs NetApp vs VAST Data
• Data migration compliance checklist — GDPR, HIPAA & SOC 2 requirements
• NFS vs SMB comparison — protocol performance and security trade-offs
• The complete migration guide — general migration planning framework