Migrating WORM-Locked Data Without Breaking Compliance

You’re migrating 4TB of archived financial records. Every file is WORM-locked. If you commit a corrupted file to the destination WORM volume, you can’t fix it. You can’t delete it. You can’t overwrite it. Not until the retention period expires.

That could be seven years.

WORM migration isn’t like regular file migration. The stakes are different. One wrong step in the commit sequence and you’re either stuck with corrupted immutable data or you’ve broken the chain of custody that your compliance team needs for audit.

What WORM actually means

WORM stands for Write Once, Read Many. Once a file is “committed” to a WORM volume, it becomes immutable. No modifications. No deletions. The file sits there, untouchable, until its retention period expires.

This isn’t a nice-to-have. Regulatory frameworks require it:

• SEC Rule 17a-4: Broker-dealers must preserve records in non-rewritable, non-erasable format
• FINRA: Electronic records must be stored on WORM-compliant media
• HIPAA: Certain healthcare records require tamper-proof storage
• SOX (Sarbanes-Oxley): Financial records need immutable audit trails
• MiFID II: Investment firms in the EU must retain communications and transaction records on non-alterable media

If your organization falls under any of these, you probably already have WORM volumes. The question is how to migrate them without breaking the guarantees they provide.

How vendors implement WORM (and why it matters for migration)

Every NAS vendor does WORM differently. The concept is the same, but the commit mechanism, retention handling, and administrative controls vary significantly.

NetApp SnapLock is the most widely deployed. It comes in two modes:

• Compliance mode: Nobody can delete files before retention expires. Not the admin. Not NetApp support. Not even if you destroy the aggregate and rebuild it. This is what SEC 17a-4 requires.
• Enterprise mode: A privileged admin can delete files early using a documented process. Less strict, but still provides tamper-evident logging.

SnapLock commits files through an atime-based mechanism. You write the file, then set the access time (atime) to the desired retention date, then change permissions to read-only. That sequence triggers the WORM commit. The order matters.

Dell EMC SmartLock (formerly Isilon WORM) uses a similar atime-based commit but with its own retention clock and compliance clock features. SmartLock also has Enterprise and Compliance variants.

Synology WriteOnce is available on newer Synology models. It implements WORM at the shared folder level with configurable retention periods, but the admin tools and commit flow differ from NetApp and Dell.

QNAP WORM provides basic WORM functionality on QNAP enterprise NAS, primarily targeting smaller deployments with simpler compliance needs.

The migration order problem

Here’s where most WORM migrations go wrong.

In a normal file migration, you copy the file and verify it. If verification fails, you delete the destination copy and try again. Simple.

With WORM, you can’t do that. Once a file is committed, it’s committed. If you committed a corrupted file, that corrupted file is now immutable. Your only options are to wait for retention to expire (years) or, in some cases, destroy and rebuild the entire volume.

The correct sequence is:

1. Write the file to the destination WORM volume (uncommitted state)
2. Verify the file using checksum comparison against the source
3. Commit the file to WORM only after verification passes

Never, under any circumstances, reverse steps 2 and 3.

Source (committed WORM)          Destination (new WORM volume)
┌─────────────────────┐          ┌─────────────────────────────┐
│  file.pdf (locked)  │ ──copy──▶│  file.pdf (uncommitted)     │
│  retention: 2030    │          │  ↓                          │
│  checksum: a1b2c3   │          │  verify checksum == a1b2c3  │
│                     │          │  ↓                          │
│                     │          │  set atime → 2030           │
│                     │          │  chmod → read-only           │
│                     │          │  file.pdf (WORM committed)  │
└─────────────────────┘          └─────────────────────────────┘

This means your migration tool needs to support a multi-phase approach. It can’t just blast files across and commit them as it goes. Each file needs to land, get verified, and only then get committed.

Retention period preservation

The destination WORM volume must honor the same retention dates as the source. If a file on the source has a retention expiry of March 2030, the destination must enforce that same date.

This sounds obvious, but it breaks in practice for a few reasons:

Clock skew. WORM volumes use a compliance clock that may differ from the system clock. If the source and destination compliance clocks aren’t synchronized, retention dates can drift. NetApp SnapLock has a ComplianceClock feature specifically for this. Dell has its own retention clock. They’re not interchangeable.

Minimum retention periods. Some WORM volumes have a minimum retention period configured at the volume level. If the destination’s minimum is longer than the source file’s remaining retention, the file gets locked for longer than intended. Not technically a compliance violation (you’re being more restrictive, not less), but it can cause problems when data needs to age out on schedule.

Cross-vendor translation. Moving from NetApp SnapLock to Dell SmartLock means translating retention metadata between two different formats. The atime encoding, the retention clock baseline, and the compliance state all need to map correctly. There’s no standard format for this.

Chain of custody

For compliance purposes, you need to prove that data wasn’t tampered with during migration. This means an audit trail that documents:

• What was migrated (full file inventory with paths and sizes)
• When each file was transferred (timestamps with timezone)
• Source integrity (checksum of the original WORM-committed file)
• Destination integrity (checksum of the written copy, pre-commit)
• Checksum match (proof that source and destination are identical)
• Commit confirmation (proof that the file was committed to WORM on the destination)
• Retention mapping (source retention date mapped to destination retention date)
• Who authorized and executed the migration

This audit trail itself needs to be stored on WORM or equivalent tamper-proof storage. If the audit trail can be edited after the fact, it doesn’t prove anything.

What can go wrong

Committing before verification. The most dangerous mistake. You lock in whatever you copied, including bit-rot, truncated transfers, or encoding errors. No way to fix it until retention expires.

Losing retention metadata. If your migration tool doesn’t extract and re-apply retention dates, every file on the destination gets the volume’s default retention. That might be too short (compliance violation) or too long (can’t age out data on schedule).

Breaking the audit trail. If there’s a gap in your chain of custody documentation, the entire migration’s compliance status is questionable. A regulator asking “prove file X wasn’t modified during migration” needs a clear answer.

Protocol-level corruption. NFS and SMB handle large files differently. Network interruptions during transfer can produce files that look correct (same size) but have corrupted content. Without per-file checksum verification, you won’t catch this until it’s too late. If you’ve already committed to WORM, it is too late.

Permission and ownership mismatches. WORM volumes often have strict permission requirements. If the destination uses different UID/GID mappings or ACL structures, files may be committed with incorrect access controls. Unlike regular files, you can’t fix permissions on a WORM-committed file.

Volume-level settings mismatch. The destination WORM volume needs matching configuration: autocommit periods, default retention, minimum/maximum retention bounds. If autocommit is enabled on the destination and set to 30 minutes, your files might get committed before verification finishes.

WORM migration planning checklist

Use this before starting any WORM volume migration.

Pre-migration

• Identify source WORM vendor and mode (SnapLock Compliance/Enterprise, SmartLock, etc.)
• Identify destination WORM vendor and mode
• Document the commit mechanism for both source and destination
• Export full file inventory from source with retention dates and checksums
• Verify destination volume configuration: retention bounds, autocommit settings, compliance clock
• Disable autocommit on destination volume
• Synchronize compliance clocks between source and destination (or document the offset)
• Set up tamper-proof storage for the audit trail
• Get written authorization for the migration from compliance officer

During migration

• Transfer files in uncommitted state
• Verify each file’s checksum against source before committing
• Apply correct retention date to each file during commit
• Log every operation: transfer, verification, commit, with timestamps
• Handle failures explicitly: do not commit unverified files, do not skip failed files silently
• Monitor for autocommit (in case it re-enables or a different policy applies)

Post-migration

• Run a full inventory comparison: source file count vs. destination file count
• Verify a statistical sample of committed files (checksums, retention dates, permissions)
• Confirm all files on destination are in committed WORM state
• Generate the final audit report with complete chain of custody
• Store audit report on WORM or tamper-proof storage
• Get compliance officer sign-off on the migration report
• Re-enable autocommit on destination if applicable
• Document any exceptions, failures, or manual interventions

Further reading

• Data Migration Compliance: Your GDPR, HIPAA & SOC 2 Checklist
• Why Checksums Matter: How syncopio Verifies Every File
• Data Migration: The Complete Guide