Migrate a file server to Azure Files: identity, copy, cutover, and rollback

Choose a supported identity path, prove permissions with a pilot, and rehearse the final delta. Copying bytes is only one part of retiring a file server.

A successful migration preserves the access people should have, blocks the access they should not have, and gives applications a usable path to their files. Start with an inventory of shares, data size, file count, ACLs, applications, clients, network paths, and backup requirements. Do not begin by copying the entire server and hoping permissions will follow.

Choose the identity source before the destination share

Only one user identity source can be configured on a storage account at a time. Share-level permission and file/directory permission are separate layers, and network access must also work. A role assigned to a user does not automatically reconstruct every source ACL.

The service-specific Entra Kerberos documentation covers hybrid and cloud-only identities. It lists supported Windows clients and updates, Entra join requirements, regional restrictions, and storage-application prerequisites. Use that configuration guidance rather than relying on an unverified blanket general-availability date. Check the current support status for every client and cloud you intend to use.

Prove access with ordinary users

Select a small share containing ordinary files and representative permission patterns. Include nested groups, a read-only user, a writer, and a user who should be denied. Test with those identities, not just a storage-account key or an administrator account.

If identities change, copied security identifiers may no longer represent the intended users. Plan and validate the permission mapping; copying ACL bytes is not proof of equivalent authorization. Cloud-only identities also have a documented ACL-management path that differs from editing hybrid ACLs through Windows File Explorer.

An account key gives broad access and can conceal authorization failures. Prefer the supported identity-based path for normal users. If a chosen migration method needs a key, keep it out of source control, command logs, and screenshots, restrict its handling, and follow the organization's rotation procedure after use.

Confirm the network and application path

• SMB connectivity: test DNS and the required SMB route from actual client networks. A successful Azure portal connection does not prove a home or branch-office client can mount the share.
• Private access: where used, validate private endpoint routing and name resolution from each network.
• Applications: test locking, path assumptions, file names, latency sensitivity, and the features the application needs.
• Performance: choose a share configuration from measured access patterns and estimate storage, transactions, backups, and networking costs.

Azure File Sync can be relevant when a local Windows Server cache is part of the desired architecture. A direct cloud share and a cached hybrid arrangement have different operational requirements. Choose the migration pattern before selecting the copy tool.

Use a non-destructive copy rehearsal

Microsoft documents migration tools including Azure Storage Mover and RoboCopy. Choose one that preserves the fidelity your workload needs. Before a real copy, take a restorable source backup and test with a disposable source and destination.

robocopy "D:\MigrationPilot\Source" "\\storageexample.file.core.windows.net\pilot" /E /COPY:DATS /DCOPY:DAT /R:2 /W:5 /L /LOG:"C:\MigrationLogs\pilot-dry-run.log"

This illustrative Windows command uses /L to list proposed work without copying. Replace the paths and ensure the log directory exists. /E includes subdirectories; /COPY:DATS requests data, attributes, timestamps, and security. Permission preservation needs appropriate rights and validation; this example does not claim to preserve owner and audit information.

Review the log before adapting the command for a copy. A normal /E copy does not remove destination-only files. /MIR includes deletion behavior and can remove files from the destination; do not use it as an unexplained default. Back up both sides where needed and review a list-only run before any operation that deletes data.

Inspect failed and skipped files and the tool's exit code. RoboCopy exit codes of 8 or higher indicate a copy failure; lower values can still report differences that need review. A completed process and a similar folder size are not enough evidence.

Validate the first copy

Compare file counts, sizes, timestamps, and representative contents. For critical data, select an appropriate integrity check. Open files through the actual application. Verify read, write, and denied-access cases, including inherited permissions and renamed or mapped identities.

Restore a file from the destination's backup process before approving cutover. Record the recovery procedure and retention policy. A migration without a tested backup merely moves the risk to another address.

Cut over with one authoritative write location

1. Schedule a window. Communicate who is affected, how long writes pause, and where to report an access problem.
2. Stop source writes. Use an agreed procedure for users and applications. Confirm open handles and background jobs are accounted for.
3. Copy the final delta. Review errors and validate representative files and permissions again.
4. Change client paths. Update mappings or application configuration in a controlled order, then test ordinary users.
5. Observe and retain. Keep the source recoverable for an agreed period. Remove it only after acceptance and retention requirements are met.

Define rollback before cutover

Write the failure criteria: unacceptable access failures, application errors, missing data, or performance below the agreed threshold. Name the person who decides to roll back and the time limit for that decision.

Once users write to the destination, returning to the source requires accounting for those changes. Freeze destination writes, preserve the new data, and follow the rehearsed reconciliation procedure. Never point half the users at each location and assume the files will synchronize themselves.

Common questions

Will copying files preserve all user access?

Not automatically. Validate share-level permission, file ACLs, identity mapping, and actual allowed and denied cases.

Should I use an account key to test end-user access?

No. Test the intended identity-based method with ordinary users. A broad key can hide permission problems.

Can I delete the old server as soon as the copy finishes?

Wait for application acceptance, a tested backup, the agreed retention period, and a workable rollback decision. A successful copy alone is insufficient.

Sources and review

Reviewed 1 October 2026. Supported identity paths and copy semantics were checked against Microsoft documentation. The command is an illustrative list-only rehearsal; no customer migration or paid Azure deployment was performed.

• Azure Files identity-based authentication overview
• Entra Kerberos configuration and client prerequisites
• SMB Azure Files migration overview
• RoboCopy switches and exit codes

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.