File-Server Migration: From an Old NAS to a New Solution

Summary: A file-server migration — moving from an old NAS or Windows file server to new hardware, SharePoint Online, or a hybrid cloud — is a project SMEs take on once every 5–10 years; done poorly, it causes weeks of production loss. A proper migration: inventory the files, map permissions (NTFS ACL → the target format), pre-stage (copy ahead of time), run the final sync at cutover, redirect via DFS namespaces, and let the old server "fade out". At SME scale, a 1–5 TB dataset can be moved in a planned 1–3 day window.

The 5-to-7-year-old QNAP or Synology in many SMEs holds 80% of production data — folders accumulated over years, tangled permissions, drives whose warranty has long expired. The decision "we need a new solution" lands easily; but "how do we migrate?" stalls the project. A poorly run migration: permissions break, files vanish, employees spend weeks bouncing between the old and the new server.

In this article we cover the step-by-step plan for an SME file-server migration, permission management, and common pitfalls. Target audience: IT managers, system administrators, and decision-makers moving legacy file servers to a modern infrastructure.

Migration Scenarios

The most common paths in SMEs:

Scenario 1: Old NAS → New NAS

Version upgrade within the same vendor (QNAP, Synology). The simplest path; the vendor often provides their own migration tool.

Scenario 2: NAS → Windows File Server

For Active Directory integration and NTFS ACL strength. Move the data with robocopy; manage via GPO.

Scenario 3: NAS → SharePoint Online

Comes with Microsoft 365 Business Premium. Cloud-based, mobile access, modern UI. Migration tool — SharePoint Migration Tool (SPMT).

Scenario 4: NAS → OneDrive for Business

For user-specific files. For team files, SharePoint is the better fit.

Scenario 5: NAS → Hybrid (NAS + Cloud)

Hot data in the cloud, cold archive on the NAS. Automatic tiering (stub files).

Scenario 6: Same Vendor, New Hardware

QNAP-to-QNAP, Synology-to-Synology — hot migrate, snapshot replication.

Pre-Migration Preparation

To do before the move:

1. Existing-System Inventory

• Total data size
• File count (a very high count slows migration)
• Top 10 folders
• Stale / untouched files (e.g. unopened in 3 years)
• Active user count
• Most-accessed folders

2. Permission Inventory

NTFS ACL or Linux POSIX permissions:

• Which group has access to which folder?
• Which user has direct permission (bad practice — to be reviewed)
• Folders with broken inheritance?
• If "Everyone — Full Control" exists, fix it

3. Data Hygiene

A migration is not a chance to carry junk data forward:

• Delete stale / unnecessary files
• Collapse duplicate copies to one
• Personal files moved to OneDrive
• Clean temp / test folders

4. Target-System Preparation

• New hardware installed and networked
• Domain-joined (if Windows)
• AD groups created
• Disk layout planned (RAID, volume layout)
• Backup configured

5. Downtime-Window Planning

• Weekend or overnight?
• Notify employees in advance
• Rollback plan ready

Permission Mapping — the Most Critical Step

The most common point of failure.

Old → New System Mapping

Source	Target	Method
Linux NAS POSIX	Windows NTFS ACL	Manual mapping, Microsoft File Server Migration Toolkit
Windows file server	Windows file server	robocopy /COPY:DATSOU or /COPY:DAT
NAS → SharePoint	SharePoint permissions	SPMT, ShareGate, AvePoint
NAS → OneDrive	OneDrive folder	Mover (Microsoft), per user

Preserving NTFS ACL with robocopy

robocopy "\\old-nas\Share" "\\new-server\Share" \
  /MIR /COPY:DATSOU /DCOPY:T /R:1 /W:1 /MT:16 /LOG:C:\migrate.log

/COPY:DATSOU preserves permissions (DACL, SACL) and ownership info; /MIR mirrors.

Permission-Audit Tooling

To verify permissions have transferred correctly after the migration:

• AccessChk (Sysinternals)
• Get-Acl (PowerShell)
• ShareGate (commercial, automatic comparison)

Pre-Staging — Copy Ahead of Time

Trying to copy 5 TB in one shot won't fit in a weekend. Pre-staging is essential.

The Typical Flow

1. 1–2 weeks before: full data copy (initial sync) runs overnight
2. Daily incremental: only changed files
3. Cutover night: final sync (hours)
4. User cutover: path change, DFS redirection

Pre-Staging with robocopy

:: First large copy (overnight)
robocopy "\\old-nas\Share" "\\new-server\Share" \
  /MIR /COPY:DATSOU /MT:16 /R:1 /W:1

:: Subsequent days, deltas only
robocopy "\\old-nas\Share" "\\new-server\Share" \
  /MIR /COPY:DATSOU /MT:16 /R:1 /W:1 /XO

/XO = skip older — only newer files from the source.

Seamless Cutover with DFS Namespace

DFS (Distributed File System) makes the path change transparent to users.

Classic Flow (Without DFS)

• User: \\old-nas\Share
• After migration: \\new-server\Share
• Path links in every Excel / Word document break
• User sees "save failed" errors

DFS Flow

• User: \\firma\Share (a DFS namespace)
• DFS resolves it to the real location behind the scenes
• During migration, the DFS namespace points to the new target
• The user doesn't notice the path change

Setting up DFS in an SME yields large operational gains for small effort.

Migration to SharePoint

A cloud-based approach for SMEs on M365 Business Premium.

Microsoft SharePoint Migration Tool (SPMT)

• Free from Microsoft
• Supports file share and SharePoint 2013 / 2016 sources
• Maps permissions automatically (AD users / groups to AAD)
• Operates with user-based notifications

ShareGate / AvePoint

Commercial migration tools with more advanced features:

• Bulk edits (folder-name standardisation)
• Detailed reporting
• Version preservation
• Inheritance optimisation

Configuration Recommendations

• Sub-sites by topic instead of one giant SharePoint site
• A clear private vs public-site decision
• Version control on (older versions kept 30–90 days)
• Retention policy aligned with KVKK

Cloud-Migration Benefits

• Mobile access (apps)
• Real-time co-editing
• External sharing (with extra controls)
• Lower hardware cost

Drawbacks

• Large-file open speeds aren't as fast as a local NAS
• Access issues during internet outages
• Data residency for KVKK alignment (check M365 EU / Türkiye locations)

Cutover-Night Flow

Typical plan for a weekend cutover:

Friday 18:00

• Notice to employees: "we're moving to the new system on Monday morning"
• Users asked to close open files

Friday 20:00

• Write access to the old server closed (read-only)
• Final robocopy runs

Saturday 02:00

• Final sync complete
• Permission-verification test
• Spot checks (sample files opened)

Sunday 18:00

• DFS namespace redirected to the new target
• The old path stays read-only (a rollback safety)
• Test with pilot users

Monday 08:00

• All employees on the new system
• IT support stands by (for potential issues)
• First-day monitoring

Letting the Old Server "Fade Out"

Don't switch the old server off the moment migration ends.

A Typical Fade-Out Flow

Week	Old server state
1	Read-only, no new writes, old reads OK
2–4	Read-only, users acclimating to the new system
5–8	Access closed but data on hand (emergency case)
9	Final backup taken; powered off
10+	Disk-resident documents deleted; hardware decommissioned

That fade-out period is insurance for discovering forgotten files and tasks.

Common Migration Mistakes

Frequent SME mistakes:

• Permission mapping not reviewed; new system winds up with "Everyone — Full Control"
• DFS not used; users update paths one by one
• No pre-staging; the whole dataset gets copied overnight (doesn't fit)
• Old server cut off immediately, then "where did that folder go?" panic
• User training skipped; IT support flood on day one
• Backups not configured on the new system (running without a safety net)
• Office "Recent Files" keeps the old paths — confuses users

What Yamanlar Bilişim Offers

Our file-server migration support areas at SME scale:

• Audit of the current file server and permissions
• Target-system selection advisory (NAS, file server, SharePoint, hybrid)
• Migration plan and timeline
• Pre-staging and final-sync operations
• DFS namespace design
• SharePoint Online migration (SPMT / ShareGate)
• Cutover-day support
• Fade-out monitoring and old-system decommissioning

Frequently Asked Questions

Conclusion

A file-server migration is a 1–3 day operation when properly planned — and weeks of operational pain when it isn't. The keys: permission mapping, pre-staging, DFS transparency, and a slow fade-out for the old system. The most common modern SME approach is moving from an existing NAS to SharePoint Online, or a hybrid (hot cloud + cold NAS); both, when done right, deliver mobile access, redundancy, and a better user experience.

Yamanlar Bilişim runs migration projects tailored to your scale and target system — walking the whole chain with you from pre-staging through to old-system decommissioning.