Migrating from a local file server to cloud storage eliminates the maintenance, backup burden, and single point of failure that comes with keeping an on-premises server running. Your team gets access to files from anywhere, automatic version history on every document, and real-time collaboration features that a traditional file server simply cannot provide.
The migration itself is straightforward when planned well, but rushing it without cleanup and user training creates confusion and resistance. This guide walks you through the entire process, from auditing what you have today to shutting down the old server for good.
What You Will Need
- Microsoft 365 Business Premium licenses for all users. This is the license tier Athencia deploys, and it includes OneDrive for Business (1 TB per user), SharePoint Online, and Microsoft Intune for device management. If you are on a different license tier, confirm that OneDrive and SharePoint are included before starting.
- Admin access to the current file server and to Microsoft 365. You will need to read file server permissions and create SharePoint sites in the Microsoft 365 admin center.
- An inventory of what is on the file server and who uses what. This does not need to be a formal audit. A walk-through with department leads to identify active folders and stale data is enough.
- Time for data cleanup before the migration. This step is the most important part of the entire project.
Why Move to the Cloud
A local file server is a piece of hardware that needs power, cooling, maintenance, and replacement every five to seven years. It is a single point of failure. If the hard drives crash and your backups are not current, you lose data. If the office floods, the server goes with it.
Moving your files to SharePoint Online and OneDrive for Business eliminates those risks. Your data lives in Microsoft's data centers with built-in redundancy, and your team can access files from the office, from home, or from a mobile device without needing a VPN. Every file gets automatic version history, so the days of "Final_v3_REAL.docx" are over. And because SharePoint integrates directly with Microsoft Teams, your team can collaborate on documents in real time.
Step 1: Audit and Clean Up Your File Server
This is the most important step in the entire migration. Migrating junk to the cloud just creates cloud junk that is harder to find and costs time to manage.
Start by identifying what is actually being used versus what has not been touched in years. Check last-modified dates on folders and files. Most file servers contain 30 to 50 percent data that does not need to be migrated at all.
Work through the file server folder by folder with the people who use it. Delete duplicates, outdated drafts, and files that are no longer relevant. For old project files and historical data that you need to keep but nobody accesses regularly, create a separate archive location. You can set up a dedicated "Archive" library in SharePoint for this purpose, or simply keep a final backup of the file server after migration.
This cleanup typically takes longer than the actual migration, but every hour you spend here saves confusion and frustration later.
Step 2: Plan Your Cloud Structure
Do not replicate the file server's folder structure exactly. This migration is your chance to fix years of organic, messy folder growth.
The general rule is straightforward. Shared files that multiple people need to access go in SharePoint document libraries. Personal files that belong to one person go in that person's OneDrive.
Map your file server shares to SharePoint sites. Each department or major business function should get its own SharePoint site. For example:
- The "S:\Clients" share becomes a SharePoint site called "Client Projects" under Operations
- The "S:\Finance" share becomes a SharePoint site called "Finance"
- The "S:\Marketing" share becomes a SharePoint site called "Marketing"
- Individual "My Documents" folders become each user's OneDrive
Keep the folder hierarchy shallow. Two to three levels deep is ideal. Deeply nested folders become difficult to navigate and impossible to sync reliably. Where you previously used deep folder structures to categorize files, consider using metadata columns in SharePoint instead.
Document this mapping in a simple spreadsheet: old location on the left, new location on the right. You will use this document for the migration itself and as a reference guide for your team.
Step 3: Set Up SharePoint Sites and Libraries
Log in to the Microsoft 365 admin center at admin.microsoft.com and navigate to Active sites under Sites in the SharePoint admin center. Create each SharePoint site based on the mapping you built in Step 2.
For each site, configure permissions to match the access controls from the file server. Click on the site, then go to Site permissions to add the appropriate users or Microsoft 365 groups. Use Microsoft 365 groups rather than adding individual users whenever possible. This makes ongoing permission management much simpler.
Create the folder structure within each document library. Keep it shallow and logical. Then test with a small batch of files before you start the full migration. Upload a handful of files, verify permissions work correctly, and confirm the structure makes sense in practice.
Step 4: Migrate the Data
The migration method depends on how much data you are moving.
For smaller migrations (under 100 GB), use the OneDrive sync client. Sync the target SharePoint libraries to File Explorer, then drag and drop files from the file server into the synced folders. This is the simplest approach and works well for small offices.
For medium migrations (100 GB to 1 TB), use the SharePoint Migration Tool, which is free from Microsoft. Download it from Microsoft's website, point it at your file server, map the source folders to destination SharePoint libraries, and let it run. It handles large file counts more reliably than drag-and-drop and preserves file metadata.
For large or complex migrations, use a third-party tool like ShareGate or AvePoint, or engage your IT provider to manage the migration. These tools handle permission mapping, scheduling, and reporting more gracefully at scale.
Regardless of the method, run the migration outside business hours if possible. Uploading hundreds of gigabytes will saturate your internet connection and slow everything else down. Migration speed depends on your upload bandwidth and file count. Thousands of small files take significantly longer than the same total volume in fewer large files.
After migration, verify the results. Compare file counts between the source and destination. Spot-check files by opening them and confirming the content is intact, not just that the file name exists.
Step 5: Set Up OneDrive Sync for Users
Once data is in SharePoint, each user needs to sync the libraries they work with to their local File Explorer. This gives them the familiar folder experience they are used to from the file server.
Have each user navigate to the relevant SharePoint library in their web browser, click the Sync button in the toolbar, and approve the prompt to open the OneDrive sync client. The library will appear in File Explorer under the company name.
Enable Files On-Demand so that files do not fill up local storage. With Files On-Demand turned on, files show in File Explorer but only download to the device when someone opens them. This is especially important for laptops with smaller drives. If your devices are managed through Microsoft Intune (included with Microsoft 365 Business Premium), your IT provider can push the Files On-Demand setting to all company devices automatically rather than configuring it one computer at a time.
Step 6: Train Your Team
Training is where most migrations succeed or fail. If your team does not understand the new system, they will resist it, work around it, or create a mess of duplicate files.
Schedule a 30-minute session with your team and cover the following:
- Where files live now. Show them the File Explorer path and the SharePoint web interface. Walk through the mapping from old locations to new locations.
- How to share files. Demonstrate sharing a file or folder with a colleague using the Share button. Show the difference between "Can Edit" and "Can View" permissions. For external sharing, show how to create a link with an expiration date.
- How to use version history. Right-click a file in File Explorer, select Version history, and show how to view and restore previous versions. This feature alone eliminates a huge category of "I accidentally saved over my file" support requests.
- The cutoff date. Set a clear date and communicate it: "After [date], the old file server is read-only. All new work goes to SharePoint and OneDrive." This prevents the migration from dragging on indefinitely.
Provide a one-page quick reference guide with the old file locations mapped to the new ones. Post it in common areas and share it digitally.
Step 7: Decommission the File Server
Keep the old file server running in read-only mode for 30 to 60 days after the migration. This provides a safety net in case files were missed or something was not migrated correctly.
During this transition period, monitor for users who are still saving to the old server. If people are bypassing the new system, find out why and address it. It is usually a training gap or a permission issue.
After the transition period, take a final backup of the file server and shut it down. Store that final backup for six to twelve months in case anything surfaces later. Then cancel any maintenance contracts on the old server hardware. If you had an on-premises backup solution like Slide protecting the file server, work with your IT provider to redirect that protection to any remaining on-premises systems or to decommission it if everything has moved to the cloud.
Common Mistakes to Avoid
- Migrating without cleaning up first. Moving ten years of accumulated junk to the cloud just makes it harder to find what you need.
- Replicating the exact folder structure. Use this as an opportunity to simplify and reorganize.
- Skipping user training. If your team does not know how to use the new system, they will not use it, or they will use it badly.
- No cutoff date. Without a firm deadline, some employees will keep saving to the old server indefinitely.
- Forgetting to migrate permissions. Users who suddenly cannot access files they need will lose trust in the new system.
- Not testing with a small batch first. Always migrate one department or one folder set first and verify before doing the full migration.
Need Help?
Migrating a file server to the cloud is a project where a little planning goes a long way. If you would like guidance or hands-on support for your migration, contact Athencia and we will help you plan and execute it.
