Migrating 60+ TB of a company's production storage to TrueNAS as a one-person IT team — a live staged sync, integrity verified before the switch, a weekend cutover, and a rollback that was designed rather than hoped for.
As the sole IT person at a ~25-person bioinformatics software company, I migrated 60+ TB of production storage from an aging pair of Windows-based Dell NAS units onto TrueNAS. The business ran normally the entire time: I staged the data across while the old systems stayed authoritative, verified integrity before anyone was pointed at the new hardware, cut over on a weekend, and kept a cheap, explicit rollback path in my back pocket the whole way. The result was zero data loss and no lost workday — the storage the whole company depends on moved underneath them without an outage.
The company ran an on-premise datacenter rack alongside an AWS environment, with a production hypervisor cluster on site. Storage was central: user shares, company data, and test data, mostly over SMB with some NFS. The industry deals in massive files and large data volumes, so if the storage is unavailable, everyone feels it immediately.
This migration wasn't triggered by a failure. The company kept a strict hardware end-of-life policy — anything in the rack was retired at seven years and replaced. Retired gear could stay on board for experiments or special projects, but nothing critical was allowed to run on it. The storage pair reached that line, so this was a planned, proactive replacement: a pair of Dell NAS devices running Windows storage stacks, moving to TrueNAS. I bought new hardware for the primary — chosen to integrate cleanly with TrueNAS — and later converted the older of the two Dell units into the new secondary. All of this happened in 2024.
Three things shaped every decision:
The cutover itself got a weekend window to keep impact off business hours. Everything leading up to it ran live, against a system people were actively using.
The shape of the work was one phase per week: about a week to stand up the new primary and move onto it, then a week to convert the old secondary and bring it into line. In order:
The interesting part is step 2, because the old NAS never stopped serving users while I copied off it. I ran the bulk copy as a rate-limited rsync so it wouldn't saturate the network during business hours. After that first bulk pass, a nightly sync captured each day's deltas. Once most of the data was across, I added the new primary into the company's existing Syncthing cluster as a node that pulled updates, which kept it continuously current right up to cutover. That's why the final switch could be "hard" without being risky — by the time I flipped it, the delta was minutes, not days, and no one had been locked out to get there.
Fixing the tooling before depending on it. That Syncthing cluster already existed when I took this on, but it wasn't working properly. I repaired it before ordering the migration hardware — which turned out to matter twice over. It's what kept the new primary current during the migration, and it's what saved me when the built-in replication plan fell through.
What went wrong, and how I handled it. My plan for keeping the primary and secondary in sync afterward was TrueNAS's built-in replication. It didn't work: a misunderstanding on my part during setup left the two devices with slightly different pool configurations, and the built-in replication wouldn't run across that mismatch. Rather than tear down and rebuild a 60 TB pool, I used the Syncthing cluster I'd already fixed to handle primary-to-secondary replication instead. It worked around the mismatch cleanly, and I corrected the underlying configuration misunderstanding permanently on the next refresh cycle, when that secondary was itself replaced. (I'm leaving the specifics of the pool difference out here, for my former employer's operational security.)
The other rough edge was permissions. I recreated the shares and ACLs by hand on the TrueNAS side, and some of the configuration got misunderstood in translation — which is exactly what surfaced Monday morning as a handful of users hitting permission errors. I fixed those in the ACLs the same day.
I verified integrity two ways before pointing anyone at the new system, rather than assuming a copy is a copy. First, repeated scans comparing md5 checksums of the migrated files against the source. Second, functional spot checks by the power users — the people who knew the data best exercised their own shares and workflows and confirmed things worked from their side. My go/no-go bar was simple: cut over only once both kinds of check came back solid across successive runs. They were clean from the start — no discrepancies in either the checksums or the user checks.
I'd told users what was coming all week — email, Slack, and in-person — so no one was surprised Monday. The cutover itself was short, because the staging had done the hard work:
Monday morning, a handful of users hit the permission problems mentioned above; I corrected them in the ACLs, and the business was largely back to normal by Tuesday. My success check was twofold: checking in directly with users on what did and didn't work for them, and reviewing the dev team's weekly and nightly automation runs against the new storage to confirm the machine-driven workloads were happy too.
I want to be precise about the "no downtime" claim: the storage service never went down, and nobody lost a day's work — but a few people did need a same-morning permission fix. That's real user-facing friction, and I'd rather name it than pretend the switch was invisible to everyone.
Rollback was cheap on purpose. Clients reached storage through DNS and
Group-Policy-managed mounts, so reverting meant changing DNS back to the old hardware,
reverting the GPOs, and having users reboot or run gpupdate /force — a
name flip and a policy refresh, not a re-migration. And because the old and new systems
were both in the Syncthing cluster, the old hardware stayed current with anything written
after cutover, so falling back wouldn't have cost the work done since the switch.
The trigger was explicit: if it became clear the business as a whole couldn't be functioning by noon Monday, I'd cut back. Monday's scattered ACL fixes stayed well under that bar, so I never had to. I also kept the insurance in place long enough to be sure — nothing got wiped until the week after cutover had proven itself. Only then did I convert the older Dell into the new secondary, and the newer Dell stayed on board afterward under the same EOL policy that started all this.