I'm the only sysadmin at a small staffing agency in Germany with around 15 internal users. We're moving away from a legacy on-premises setup toward Microsoft 365 Business Premium, Entra ID, Intune, and SharePoint. Our HR line-of-business application is also being replaced with the vendor's SaaS platform, so that data will be cloud-hosted regardless.
The backup design includes a third-party Microsoft 365 backup, a local NAS with immutable snapshots, and an encrypted external drive rotated offsite. We also need to meet 10-year retention requirements.
Management and an external IT adviser still want to keep a physical Windows file server, mainly because it is on-site and supposedly allows us to take daily backups. I'm not convinced that adds meaningful protection. It would create another system to patch, license, monitor, refresh, and restore, while the key business application will already be unavailable if the internet or SaaS provider is down. As a single administrator, I'm also concerned about being the only person responsible when something breaks while I'm away.
Our files are mostly Office documents, PDFs, scanned contracts and certificates, and some images. There's no CAD, video editing, or other obviously storage-heavy workload. Are there any practical reasons a company this size would still need an on-premises file server? For people who moved similar businesses to SharePoint, what caused the most trouble? I'm especially expecting issues with path lengths, permissions, sync limits, legacy UNC paths, and retention.
3 Answers
Don’t let the 10-year retention requirement turn into an argument for a file server. Retention should be designed explicitly with the appropriate Microsoft 365 retention controls and an independent backup strategy. A server sitting in the office is not automatically a compliant archive or a reliable backup.
There is still a reasonable availability argument for local storage if staff must keep working during an internet outage, but in this case the main HR application is SaaS anyway. If losing connectivity stops the important work regardless, a local file server may not improve business continuity. Make management define the specific failure scenario they want the server to solve; often the answer is simply wanting a physical box nearby, which the NAS already provides.
For the workload you described, a dedicated file server sounds unnecessary. Office documents, PDFs, scans, and images are exactly the sort of content SharePoint handles well. A NAS that stores independent Microsoft 365 backups and provides immutable local snapshots gives management the physical, in-house copy they seem to want without adding a second production file platform.
The real exceptions would be legacy applications that require SMB or UNC paths, databases stored directly on shares, very large or latency-sensitive files, or workflows that depend on traditional file locking. None of those appear to apply here. Keeping a full Windows server would mostly mean extra patching, licensing, hardware maintenance, and restore testing.
The migration details matter more than the server-versus-cloud argument. Audit the existing share before moving it. Long paths can usually be addressed by flattening the folder structure, but permissions are often the bigger problem because years of one-off exceptions and broken inheritance have accumulated.
Also look for Access databases, accounting files, scripts, scanner destinations, label printers, shortcuts, and anything hardcoded to a UNC path such as a server-based scan folder. Those dependencies are easy to miss and can cause trouble after cutover. Check the total item count and sync design as well; a decade of scanned documents can create a surprisingly large library, and forcing everything onto every workstation is usually a mistake.
The old share really has become an electronic storage room full of material nobody has reviewed in years. Cleaning up ownership, retention, and obsolete permissions may be more work than the actual migration.
That’s essentially where I landed: a local NAS for backup and recovery makes sense, but I haven’t found a workload that justifies a separate Windows file server.