I'm the sole sysadmin for a small staffing agency in Germany with about 15 internal users. We're migrating away from a legacy on-premises environment. The planned setup is Microsoft 365 Business Premium with Entra ID and Intune, SharePoint replacing the file server, and our line-of-business HR application moving to the vendor's cloud.
For backups, I'm planning a dedicated third-party Microsoft 365 backup, a local NAS with immutable snapshots, and an encrypted external drive rotated offsite. We also have 10-year retention requirements.
Management and an external IT provider still want us to keep a physical Windows file server, mainly because it is on-site and supposedly allows daily backups. I'm not convinced that adds meaningful protection, since the application data will be cloud-hosted anyway. It would also mean maintaining and patching two environments, and the server becomes another system that can fail while I'm away. Restore testing is another concern because it rarely happens in practice.
Our files are ordinary office documents, PDFs, scanned contracts and certificates, and some images. We do not use CAD, video editing, or similar workloads. Are there any workloads at this size that genuinely justify on-premises file storage? For those who moved a 10–20-user business from a file server to SharePoint, what problems did you encounter? Path lengths and permission mapping are already on my list.
4 Answers
There is still a reasonable case for on-premises storage when the business has an application that requires a local SMB share, very large working files, strict local processing requirements, or a genuine need to keep working during an internet outage. However, if the main HR system is cloud-hosted, an internet outage already limits operations, so a local file server may not provide much practical continuity.
A NAS that receives protected copies from Microsoft 365 gives you local recovery without recreating the old production environment. I would ask management what specific task they expect the Windows server to perform on a bad day. If the answer is simply ‘we want data in the building,’ the NAS already meets that requirement.
The biggest migration risks are usually permissions and forgotten dependencies rather than SharePoint itself. Old file shares often contain years of one-off permissions, abandoned folders, scripts with hardcoded UNC paths, scanner destinations, and shortcuts pointing to the old server. Audit and simplify the permission structure instead of copying every exception into SharePoint.
Also look for Access databases or other application files sitting on the share. Those should not be casually opened through OneDrive or SharePoint sync because they can become corrupted or behave badly.
Check the volume of data and the number of files before migrating. A decade of scanned records can create a surprisingly large item count, and syncing everything to every workstation can cause performance and synchronization problems. Users should normally work through appropriate SharePoint libraries rather than downloading the entire archive.
The 10-year retention requirement should be handled deliberately with retention policies and a tested backup design. Keeping a file server just because it happens to contain the archive is not the same as having a retention strategy.
Based on those file types, SharePoint is a good fit. A dedicated file server usually remains justified only for things such as legacy applications requiring SMB or UNC paths, databases that cannot work safely with sync tools, large files needing local performance, or workloads requiring traditional file locking. Office documents, PDFs, scans, and images generally do not need it.
Your NAS already satisfies the argument that the business should have something physical on-site. It can store local copies and backup data without becoming another production file platform that needs licensing, patching, hardware maintenance, and restore testing.
One caveat is that local storage can feel faster for opening files, while SharePoint is usually better for search, sharing, version history, and simultaneous editing. The right comparison is the complete operating model, including administration and recovery, not just raw file-opening speed.