How to migrate file shares and NAS storage to the cloud

File shares are the quiet workhorse of every on-prem estate: a NAS or Windows file server that a decade of apps, scripts, and users depend on. Moving them is less about bandwidth and more about permissions, small files, and a clean repoint.

First decision: object storage or a managed file system?

This choice drives everything else, and the deciding question is how the data is accessed today.

	Object storage (S3, Blob Storage, Cloud Storage)	Managed file system (EFS, FSx, Azure Files, Filestore)
Access model	HTTP API (GET/PUT by key)	Mounted drive over SMB or NFS
App changes	Anything reading file paths must change	None; clients remount and continue
Permissions	IAM policies per bucket/prefix	NTFS ACLs (SMB) or POSIX (NFS)
Cost per GB/month	~$0.02 standard tier, less in cool/archive tiers	~$0.08 to $0.30 depending on service and tier
Scale	Effectively unlimited	Large but bounded; throughput tiers matter
Right for	App-served assets, backups, archives, data lakes	Lift-and-shift shares, user home drives, legacy apps

Rule of thumb: data that applications serve through code goes to object storage and gets cheaper and more durable. Data that humans and legacy apps reach through a drive letter or mount point goes to a managed file system, because rewriting every consumer of a UNC path mid-migration is exactly the scope creep that sinks projects.

Matching share type to service:

• Windows SMB shares with AD permissions: Amazon FSx for Windows File Server, or Azure Files with AD DS authentication. Both enforce NTFS ACLs natively.
• Linux NFS exports: Amazon EFS, Azure Files (NFS), or Google Filestore.
• App assets, media, archives: S3, Blob Storage, or Cloud Storage, with lifecycle rules pushing old data to cheaper tiers automatically.

Many migrations split one NAS both ways: home directories to Azure Files, the 6 TB of old project archives to cool-tier Blob. The archive half usually pays for the whole project.

Second decision: the transfer tool

Do not hand-copy terabytes with drag-and-drop or plain rsync over the internet. Use a tool that verifies, resumes, and reports:

Tool	Cloud	Good at
AWS DataSync	AWS	Scheduled, verified transfers from NFS/SMB into S3, EFS, or FSx; preserves ACLs and timestamps; ~$0.0125/GB
AzCopy	Azure	Fast bulk copy into Blob or Azure Files; free, resumable, scriptable
Azure File Sync / Storage Mover	Azure	Keeps a Windows file server syncing with Azure Files during a gradual cutover
Storage Transfer Service	GCP	Managed transfers into Cloud Storage from on-prem or other clouds
robocopy / rsync	Any	Fine for the final delta or shares under a few hundred GB; robocopy needs the /copyall flag to carry ACLs

Two physics notes before you schedule anything:

1. Bandwidth math. 5 TB over a saturated 500 Mbps link is roughly a day; over 100 Mbps, roughly a week, during which that link is doing nothing else. Above roughly 10 TB, or on thin links, a shipped device (AWS Snowball, Azure Data Box) beats the wire.
2. File count beats file size. A million 50 KB files transfers far slower than fifty 1 GB files, because every file costs metadata operations. Estates with millions of small files should benchmark a subset first and consider archiving cold directories into compressed bundles before the move.

Permissions: the part that fails silently

Data that arrives without its permissions is a security incident waiting to be discovered. Handle it deliberately:

• NTFS ACLs survive only if both the tool and the target support them. DataSync into FSx for Windows preserves them; AzCopy into Azure Files preserves them when the share uses AD-based authentication; anything into raw object storage does not, because buckets have no concept of an ACL on a path.
• Identity has to exist on both sides. ACLs reference SIDs from your Active Directory, so the target must be joined to the same domain (or a synced one; on Azure, see the identity section of the Azure guide). Migrating files before identity is plumbed leaves you with ACLs that resolve to nothing.
• POSIX mode bits and uid/gid carry over NFS transfers, but only stay meaningful if uid/gid mappings match on the new clients. Centralize them (LDAP/AD) rather than hand-maintaining /etc/passwd parity.
• Test as a restricted user, not as an admin. Admin accounts bypass the exact controls you are trying to verify.

The cutover, step by step

1. Inventory and baseline. File count, total size, largest directories, change rate per share. Save a file-count and checksum sample per top-level directory; you will re-verify against it.
2. Provision the target in the right VPC/VNet, joined to the domain if SMB, with backups enabled before data lands.
3. Bulk copy with the source still live. Expect this to take the days your bandwidth math predicted.
4. Incremental syncs, daily or continuous, until each delta pass runs in minutes. DataSync and AzCopy both copy only changes on re-run.
5. Final sync in a read-only window. Announce it, flip the source share read-only, run the last delta, verify counts and spot-check checksums. Minutes to a few hours.
6. Repoint clients. This is where a DFS Namespace (for Windows estates) or a DNS alias earns its keep: flip the namespace target and every mapped drive follows, with no visits to individual machines. Hardcoded UNC paths in scripts and app configs are the usual stragglers; you found them in step 1, fix them now.
7. Keep the source read-only for two weeks. The forgotten monthly process that writes to the old share will reveal itself. Then final snapshot, archive, decommission.

Costs worth naming

Ingress to all three clouds is free; the transfer tooling is cheap (DataSync on 5 TB is about $64). The recurring line is what to watch: 5 TB on FSx or Azure Files premium runs hundreds per month, the same data in object storage tens. And plan for egress fees in the design: data leaving the cloud costs roughly $0.09/GB, so architectures where on-prem systems repeatedly read cloud files can generate a surprising line item. Estimate before you move with the cloud bill guide.

FAQ

Should file shares go to object storage or a managed file system?

Ask how the data is accessed. If users or apps mount it as a drive (SMB or NFS paths, Windows Explorer, legacy apps reading file paths), use a managed file system: Azure Files or Amazon FSx for Windows for SMB shares, Amazon EFS or Google Filestore for NFS. If an application reads and writes the data through code, object storage is 5 to 10 times cheaper and scales without limits, but it is an HTTP API, so anything expecting a file path needs changes.

How do we keep NTFS permissions during the migration?

Use a target that understands them and a tool that copies them. Amazon FSx for Windows and Azure Files (with AD DS or Entra Kerberos authentication) both enforce NTFS ACLs. AWS DataSync and robocopy with the /copyall flag carry ACLs across; plain copy tools and object storage do not. Plan an AD-joined target and test with a real restricted user before cutover, not after.

How long does it take to move a few terabytes of files?

Bandwidth math first: 5 TB over a saturated 500 Mbps link is about a day, over 100 Mbps about a week. But file count matters more than size. Millions of small files are metadata-bound and can take several times longer than the raw math suggests. Over roughly 10 TB, or on thin links, shipped devices (AWS Snowball, Azure Data Box) are usually faster than the wire.

Can users keep working during the migration?

Yes, until the final sync. Run the bulk copy and repeated incremental syncs while the source share stays live. Only the last delta sync needs the share read-only, typically minutes to a few hours. A DFS Namespace (for Windows shares) or a stable DNS alias in front of the share makes the repoint invisible to users.

---

Moving a file server the whole company maps on login? Talk to a Webisoft cloud engineer. We’ll help you pick the right target, verify the permissions plan, and run the cutover window with you. The first conversation is free and specific.