Why We Moved 15TB of Data from QNAP to Azure
The honest account of what pushed a 180-person firm off its QNAP NAS — the breaking point, the decision, the six-week migration, and what life looks like on the other side.
The decision to move 15TB of company data off a QNAP NAS and into Azure Files was not made in a planning meeting. It was made at 7:45am on a Monday morning in October 2025, when the IT manager received an automated email warning that Disk 7 in the QNAP TS-h1290FX was showing pre-failure SMART indicators — and then discovered that this was the third such warning in eighteen months. Two previous disk replacements, an unplanned rebuild cycle that ran over a weekend, and the growing understanding that the NAS hardware was approaching end of life on a five-year replacement schedule. The hardware replacement quote came back at $15,000. That number is what started the conversation about Azure.
This post is the story of that conversation — why the QNAP was no longer the right answer for this organisation, why Azure Files became the chosen alternative, and what the migration actually looked like from the first planning session through to the Monday morning after cutover when 180 users opened their mapped drives and nothing had changed. Except that the hardware that had been quietly worrying everyone for eighteen months was gone.
The breaking points — four problems that built up over time
No organisation moves 15TB of data because of a single bad day. The QNAP had served the firm well for four years. The decision to move came from four problems accumulating simultaneously, each manageable in isolation, collectively intolerable.
Why Azure Files specifically — and what the alternatives were
The organisation evaluated three alternatives before committing to Azure Files: a new QNAP appliance, SharePoint Online with OneDrive, and Azure Files. Each had a genuine case. Here is how the decision actually played out.
"The question was not whether Azure Files was cheaper than QNAP. It was not. The question was whether the total cost of QNAP — hardware, IT time, recovery risk, remote access friction — was higher than Azure Files. It was."
— Francis Avorgbedor | Azure Engineer, field notes from the planning sessionBefore and after — what the architecture looked like on both sides
The migration — step by step, with the honest commentary
Discovery: understanding what we actually had
Before touching the Azure portal, we spent two days mapping every share on the QNAP — sizes, file counts, last access patterns, ACL complexity, and who owned each share. This is the work most IT projects skip. We did not skip it, and it saved us from two problems that would have been catastrophic at cutover.
The first thing we found: the QNAP was not domain-joined. It used a local LDAP bridge to map its own user accounts to Active Directory. This meant every file's ACL contained QNAP-local security identifiers — not Active Directory SIDs. If we had simply copied files to Azure Files with the existing ACLs, every permission entry would have been broken. Users would have lost access to their own files on the morning after cutover.
The second thing we found: 23 files across the Projects share had colons in their names — date stamps formatted as "Report_2024:11:15.xlsx". Azure Files does not permit colons in file names. Those files would have been silently skipped during migration and would have been missing from Azure Files.
Azure provisioning: building the target before moving data
We provisioned three storage accounts in the UK South region — one Premium SSD for Finance, Projects, and HR (latency-sensitive, complex ACLs), one Standard HDD for Shared, Media, and Backups, and one Cool tier storage account for Archive2022 and Archive2023.
Critical sequence: Private Endpoints were configured before the Azure File Sync agent was registered. This is the step most guides leave as an afterthought and it causes re-registration problems if done in the wrong order. Private Endpoints ensure Azure Files traffic never traverses the public internet. We also configured AD authentication via Azure AD Connect — this is what allows users to authenticate to Azure Files using their existing domain credentials without any client-side changes.
SID mapping: fixing what the QNAP's local accounts broke
Because the QNAP was not domain-joined, its file permissions referenced QNAP-local security identifiers. We had to rebuild the permission structure on the Windows Server intermediate before uploading anything to Azure Files.
We created a mapping table: QNAP local user → Active Directory account. Then ran icacls recursively across all eight shares. Finance and HR took three days combined — Finance alone ran for 11 hours on the icacls script because of 1.4 million files. We ran the script overnight and checked the output logs each morning. No shortcuts here: every file's permission entry needed to reference an Active Directory identity that Azure Files could resolve.
Initial RoboCopy: 15TB over the local network
With SID mapping complete on the Windows Server, we ran the first RoboCopy pass — from the QNAP to the Windows Server over the local 10GbE network. Users continued working on the QNAP throughout. No disruption, no maintenance window, no user communication needed at this stage.
We ran Finance and Projects in parallel (the two largest shares) and serialised the rest. Eight days for all 15TB at approximately 300MB/s sustained throughput. The flags that matter: /COPY:DATSO (Data, Attributes, Timestamps, Security, Owner), /B (Backup mode, bypasses ACL read restrictions), /MIR (Mirror mode), and /UNILOG (Unicode log for non-ASCII filenames). Any flag set that omits Security or Owner will silently produce a copy with broken permissions.
Azure File Sync upload: Windows Server to Azure Files
Once the initial LAN copy completed, the Azure File Sync agent began uploading from the Windows Server to Azure Files over our 500Mbps internet connection. We configured the AFS bandwidth schedule to respect the client's existing traffic shaping — which cut upload throughput in half during business hours and let it run at full speed overnight. This extended Phase 4 by four days versus our initial estimate.
We monitored the AFS sync health dashboard daily and checked the Windows Event Viewer AFS log for silently skipped files. On Day 22 we found 23 files skipped due to illegal characters. We renamed them on the Windows Server and re-ran a targeted RoboCopy pass for those files. By Day 28, all shares showed SyncStatus: Healthy and PendingFileCount: 0.
Delta sync and cutover preparation
With all 15TB uploaded to Azure Files, we ran a second RoboCopy pass to catch changes made to the QNAP during the 11-day upload phase. This delta took four hours. We then notified users of a Saturday night maintenance window — communicated as "scheduled storage maintenance, no more than 4 hours, all shared drives will be back by Sunday morning."
We tested the DFS-N namespace redirect in a staging environment with a small test share to confirm that mapped drives on Windows 10 and 11 machines would reconnect automatically without user intervention. They did. We also confirmed that the three finance applications that access file shares via UNC path would continue to work after the DFS-N target change.
Cutover: Saturday night, 4 hours, no drama
22:00 — Final RoboCopy with /MIR ran and completed in 47 minutes. We waited for AFS to show SyncStatus: Healthy and PendingFileCount: 0 on all eight sync groups simultaneously before proceeding.
23:15 — DFS-N namespace targets updated: all eight shares redirected from the QNAP paths to the Windows Server AFS endpoint paths. QNAP shares set to read-only.
23:30 — Verified mapped drives on four test machines (Windows 10, Windows 11, two laptop models). All reconnected automatically within 90 seconds of the DFS-N change propagating. Ran through a checklist of 12 specific files across five shares — all accessible with correct permissions.
01:45 — Final verification complete. QNAP left online as read-only fallback. Migration complete.
Monday 08:00 — Zero support calls. Two users noticed their mapped drives had briefly disconnected over the weekend — both reconnected automatically and neither flagged it as an issue.
What changed for the organisation — before and after in plain terms
The cost reality — what the organisation is actually paying
We were transparent with the client that Azure Files would cost more annually than amortised NAS hardware. The conversation that mattered was not the raw cost comparison — it was the total cost comparison, including IT time, recovery risk, and hardware replacement cycles.
| Component | QNAP annual equivalent | Azure Files monthly | Azure annual |
|---|---|---|---|
| Storage infrastructure | $3,000 ($15K ÷ 5yr) | $315 | $3,780 |
| Support contract / warranty | $225/yr | — | Included |
| Backup infrastructure | $300/yr (NAS-to-NAS backup) | $90 | $1,080 |
| IT admin time (hardware) | ~12hrs/yr @ $62/hr = $750 | ~1hr/yr | $62 |
| VPN infrastructure / licensing | $475/yr | — | $0 (removed) |
| Egress + transactions | N/A | $135 | $1,620 |
| Total cost of ownership | ~$4,750/yr | $540 | $6,555/yr |
Azure Files costs approximately $1,790 more per year than the equivalent QNAP TCO — a 38% premium. The client accepted this because the premium buys the elimination of hardware risk, the recovery time improvement from 6 hours to minutes, the removal of VPN complexity for 68 remote workers, and the 99.99% SLA that the QNAP could never provide. If those things are not worth $1,790/year to your organisation, keep the QNAP. If they are — and for this client they clearly were — the business case works.
Six months after cutover, I asked the IT manager to describe the change in one sentence. His answer: "I used to spend every Friday afternoon checking the QNAP SMART status and hoping I wouldn't get a Slack message over the weekend. I haven't thought about storage once since the migration."
That is the real measure of a successful migration. Not the cost per gigabyte. Not the SLA percentage. The number of Friday afternoons the IT team can spend on something other than hoping the hardware holds until Monday.
- The decision point is usually a hardware event, not a planned refresh. Most organisations move when a disk fails, a quote comes back higher than expected, or a near-miss exposes the backup architecture. If you are waiting for a planned migration project, the near-miss will likely arrive first.
- Check whether your QNAP is domain-joined before planning anything. If it is not, SID mapping will be the most time-consuming part of your migration — and the one most likely to cause access failures if done incorrectly. Budget by file count, not share count.
- Azure Files preserves SMB semantics — mapped drives, UNC paths, and AD authentication all work identically. This is the critical difference from SharePoint. If your users are accessing files via mapped drives and applications are accessing shares via UNC paths, Azure Files is the correct destination. SharePoint is not.
- The migration does not require any user-side changes. DFS-N namespace redirect means users experience a brief disconnect and automatic reconnect. No new clients, no new credentials, no retraining, no Monday morning support calls — if the migration is executed correctly.
- Plan the cost conversation honestly. Azure Files is more expensive than amortised NAS hardware. The business case rests on total cost of ownership — hardware risk elimination, IT time freed, backup architecture improvement, remote access simplification. Have that conversation explicitly, not implicitly.
Get the Azure field notes — every week
Real migration stories, honest cost analysis, and the lessons that come from doing it in production. Written by Francis Avorgbedor.