Checklist: move a file server to the cloud

Who this is for

Checklist: move a file server to the cloud is for IT leads, system administrators, and operations managers who still depend on Windows file shares or network drives. It fits teams that are closing an office, replacing aging hardware, or moving line-of-business workloads to cloud infrastructure.

It is not only a storage decision. File servers carry permissions, shortcuts, scan-to-folder paths, backup jobs, and applications that open files by UNC path. The checklist assumes you want users to keep working with familiar drive letters while the storage moves.

Before you begin

Start with an inventory, not a cloud service pick. List every share, folder, file count, size, growth rate, and owner. Note the shares that hold home drives, department data, archives, and application data. Pull last access times so you can separate active data from files that only need cheap archive storage.

Document identity and permissions. Capture NTFS permissions, share permissions, Active Directory groups, local groups, and direct user grants. Find broken inheritance and orphaned SIDs. Decide how those groups will exist in the target environment before you copy a single file.

Check the path users and applications take to the server. Record mapped drives, DFS Namespaces, DNS aliases, VPN links, firewall rules, and backup windows. Test upload bandwidth from the main office to the chosen cloud region. For large datasets, plan a physical seeding option or a long initial copy window.

The checklist

Work in phases: discover, pilot, migrate, verify, and retire. Do not start with the largest share. Pick a pilot group that can tolerate a short disruption and will give useful feedback.

The order matters because permissions and namespace design are harder to fix after users reconnect. Use the items below as gates. A gate is complete only when someone has checked the result and recorded it.

• Name a business owner and success criteria for each share, including who uses it and how fast it must feel.
• Export the share list, folder paths, file counts, sizes, and last access dates from the current server.
• Map NTFS permissions to Active Directory groups and remove direct user grants before the copy starts.
• Choose the target service by protocol and workload, using SMB for Windows file shares and NFS for Linux workloads.
• Design a stable namespace with DFS Namespaces or a DNS alias so mapped drives and UNC paths survive the move.
• Check line-of-business applications for hard-coded server names, SMB protocol versions, file locking, and open-file behavior.
• Set up domain join, Kerberos, or cloud identity as required, then test authentication from a normal workstation.
• Size throughput and IOPS from real workload data, not from raw capacity alone.
• Turn on versioning and backup for the target service, then restore a test folder and compare its permissions.
• Run a pilot copy with the chosen tool and compare file counts, timestamps, permissions, and share paths.
• Plan a maintenance window with a final delta copy, a share freeze, and a written rollback point.
• Update DNS records, DFS links, mapped drive scripts, scan-to-folder paths, backup jobs, and monitoring.
• Test open, save, rename, search, offline files, and permissions with users from each department.
• Keep the old server read-only for an agreed period, then decommission it after a final backup and sign-off.

What good looks like

A good migration leaves users with the same drive letters, working shortcuts, and access. Permissions come from groups, not from a long list of named users. File owners can find their data, and help desk tickets do not spike after cutover.

Performance should be measured from real clients on the real network. Test open, save, rename, search, and large file copies. For CAD, video, or database files, test file locking and latency carefully. Cloud file services can be a poor fit for workloads that need local block storage or heavy random I/O.

Backup and restore matter more than the copy itself. Confirm that versioning, snapshots, and backups cover the new file service, and that you can restore a folder and its permissions. Watch storage growth, egress charges, and backup retention costs. Set alerts for capacity, latency, and failed sync jobs.

What to do next

Write a cutover runbook with named owners, start and stop times, and a rollback trigger. Freeze the source share before the final copy. Keep the old server reachable but read-only until users sign off.

After cutover, review access logs, backup reports, and help desk tickets for two weeks. Remove temporary sync jobs and old DNS records. Update the disaster recovery plan so it names the cloud file service, not the old server.

If you need a target architecture and a phased plan before you commit, Cloudverg offers the Discovery and roadmap sprint at a fixed price of $9,500 over two weeks, as one option among others. You can also run the checklist internally or with another integrator.

Frequently asked questions