The old file server had been running long enough that nobody remembered exactly when it was installed. It was backing up to tape — not disk, not a VM snapshot, actual tape — while the rest of the environment had already started moving to virtualization. Replacing it wasn’t optional anymore. It was just a matter of when. This is the story of that file server migration — the timeline, the mistake, and the check that caught it before go-live.
This was in Germany, at the third company I’d worked for after my second job change — the same stretch of my career I wrote about in From Seoul to Frankfurt to Georgia. It was also the first project I’d ever put together that crossed €10,000 — enough that it needed a real proposal to management, not just a purchase request. I was still at the assistant manager level at the time, and being the one responsible for a budget that size, for the first time, added its own kind of pressure on top of the technical work.
The Setup
The plan was straightforward on paper: retire the old physical file server and its tape backup, and replace it with a proper VM-based setup — Windows on top, Dell storage on the backend, SMB for file sharing, and Veeam handling backup instead of tape rotation.
Getting there wasn’t quick. Writing the proposal for management took about a month on its own. After that came vendor selection, meetings, working out the configuration, and settling on the actual hardware model — another month or so on top of that. By the time everything was decided, roughly two months had gone by and nothing had even been ordered yet.
Then the equipment itself got delayed. Given the circumstances at the time, delivery didn’t happen for a while, and the project that was supposed to take two months of planning plus installation ended up taking about five months start to finish.
The Migration
Once the hardware finally arrived and the new server was configured, I moved the data over with robocopy, carrying over the same folder structure from the old server to the new one — same layout, same naming, same organization. It seemed like the safest way to do it: don’t change what doesn’t need to change.
What I didn’t fully account for was that SMB share permissions don’t stay clean over the life of a file server. This was HR’s file share, and looking into it, the mismatch wasn’t really a migration bug — it was years of accumulated history finally surfacing. Every new hire, every new folder, every new permission grant along the way had added something, and not everything that should have been removed along the way actually was. Robocopy just carried all of that forward exactly as it found it, stale entries included.
How We Caught It
Before opening the new server up for actual use, I went through a permissions check as part of the pre-launch process — the same kind of pre-launch discipline I later wrote about in Why Every Disaster Recovery Plan Needs Regular Testing. That’s where the mismatches turned up — not everywhere, just in a few folders, but they were the kind of folders where getting it wrong would have mattered.
We fixed it before go-live. No one outside the project ever had a chance to hit the wrong permissions, because the new server wasn’t live yet when we found the problem.
What I Took Away From It
Folder structure is easy to verify — you can see it. Permissions are not the same kind of thing. They can look right at a glance and still be wrong underneath, especially when the actual source of the problem isn’t the migration itself but everything that quietly built up in the years before it. It’s the same gap I kept running into in the pattern behind seven other incidents — something everyone assumed was clean, that wasn’t.
Since then, I’ve gotten into the habit of looking at old, existing policies whenever I take on a project like this — even when nothing in the process actually requires it. Permissions don’t just come from the migration in front of you. They come from every project before it that touched the same folder.
The Timeline
Old server identified as end-of-life → proposal written (~1 month) → vendor selection, meetings, and configuration decided (~1 more month) → equipment delayed → hardware arrives and new server configured → migration via robocopy and permission audit → mismatches found and corrected → go-live. Total project length: about five months, most of that waiting on hardware rather than doing the technical work itself.
Frequently Asked Questions
How do you avoid permission issues when migrating a file server?
Copying the folder structure isn’t enough on its own — SMB share and NTFS permissions need their own review, separate from the folder layout. A lot of permission problems aren’t caused by the migration itself; they’re old, stale grants that accumulated over years and get carried forward exactly as they were. A dedicated audit before go-live is what catches them while they’re still low-risk to fix.
How long does a file server migration project typically take?
The technical work itself — configuration and migration — can move fairly quickly, but the full project timeline depends heavily on procurement and hardware delivery. In this case, planning and vendor selection took about two months, and hardware delays pushed the total project to around five months.