The file share is the workload that looks simple and then eats a week if you treat it as a bulk copy. People open paths they have memorized. Shortcuts live on desktops. Scanners write to a fixed UNC. An Access front end points at a folder that has not moved since 2014. A migration that only copies bytes and flips a DNS name will leave half the office unable to find yesterday's work for several days, and the helpdesk will spend that week reconstructing muscle memory one ticket at a time.
The honest starting point is that the share is not one thing. A typical regional office share has a handful of top-level folders that people live in every day, a longer middle tier that gets opened a few times a month, and a deep archive that nobody has touched in years. Treating those three layers the same way is how a cutover that should take a weekend becomes a recovery project. The active folders need a careful move with a parallel-run window. The archive folders need a copy to long-term storage and a clear rule about how someone retrieves something if they need it. Mixing the two is how you pay for premium sync on dead PDFs from a closed matter.
Map the share the way people use it
Before any tool runs, walk the top two levels of the share with the people who actually open files. The IT inventory is not enough. Ask the office manager, the bookkeeper, and one person from each practice group which folders they open without thinking. Write those down with the real path, not the friendly name on a mapped drive. Then ask who else writes to those folders. The scanner at the front desk may be writing into a folder that nobody mentioned because nobody thinks of the scanner as a user. The overnight export may be dropping CSVs into a folder that looks empty during the day. Those writers matter as much as the readers.
While you are mapping, capture the hard dependencies that a file sync will not fix. Mapped drives that point at a letter rather than a DFS namespace. Desktop shortcuts that hard-code a server name. Templates in Word that open from a fixed path. Line-of-business apps that store a data directory in a config file. Print-to-file destinations. Backup jobs that pull from the share. Each of these is a small change on its own and a cascade of broken mornings if they are discovered after the old server is powered down.
Also measure what is actually changing. Last-write dates on the top-level folders tell you which trees are alive. A folder that has not been written to in eighteen months is a candidate for archive, not for real-time sync. A folder that changes every hour during business days needs a cutover plan with a freeze window and a final delta copy. The difference in effort between those two is large, and the audit is where you capture it.
Move the active folders with a freeze, not a hope
For the active folders, run a first full copy to the new location while people are still working on the old share. Most offices can do this overnight or over a weekend without anyone noticing. Then keep the new location current with scheduled delta copies until cutover day. The goal of the parallel window is not perfection. The goal is that the final cutover copy is small enough to finish inside a planned freeze, usually Friday evening through Sunday morning for a modest firm.
The freeze itself has to be written and communicated. Tell people the exact windows when the active folders will be read-only or unavailable. Tell them what to do with work in progress: finish it before the freeze, save a local copy if they must keep editing, and know who to call if something cannot wait. Offices that skip this step get a Monday morning where half the staff edited files on the old share after the last sync ran. That is how you lose a week of work even though the bytes mostly arrived.
On cutover, do one last delta, flip the access path, and leave the old share read-only for a short overlap rather than deleting it. Two weeks of read-only access on the old server is cheap insurance. People will find a forgotten path. Someone will open a shortcut that still points at the old name. A vendor integration will write to the old location once. Read-only overlap turns those events into recoverable mistakes instead of silent data loss.
Validate with real people, not with a file count. After the first full copy, have three or four daily users open their usual folders on the new path and confirm that the files they expect are there and openable. After the final cutover, repeat that check on Monday morning before the office is fully busy. A mismatch between file counts is a useful signal, but the signal that matters is a person finding the brief they filed on Thursday.
Retire the archive without pretending it is active
The archive layer is where migrations waste money. Copying every old matter folder into a hot cloud share preserves access patterns nobody needs and creates a monthly bill for storage that should have been cold. Move the archive to a cheaper long-term store, document how a person requests a restore, and put a date on when the old copy on the server will be removed. If a folder has not been opened in years and is only kept for retention, it does not belong in the same sync job as the current client files.
Be careful with "archive" that is not really archive. Scanned closed files that counsel still opens quarterly are active enough to keep in the hot share. A folder named Archive that the paralegals use every week is not an archive. The last-write date and a five-minute conversation with the people who work in those folders will sort this faster than a storage policy document.
Permissions deserve their own pass. Cloud shares and traditional NTFS ACLs do not map one-to-one. A folder that was open to "Domain Users" on the old server may need an explicit group on the new platform. A folder that was locked to one practice group may silently widen if the default share permissions are left alone. Rebuild the permission model from the written map, then spot-check the sensitive folders with a user account that should be denied as well as one that should be allowed. The failure mode to catch before cutover is the accidental grant, not only the accidental lockout.
What "done" looks like
The file share migration is done when people are working on the new path without thinking about it, the writers (scanners, exports, apps) are pointed at the new path, the old share is read-only or gone on a published date, and the archive has a retrieval path that someone other than the original IT person can follow. Until those are true, the share is still mid-migration no matter how complete the copy report looks.
Write the cutover as a short project with owners and dates: mapping complete, first copy complete, freeze window, final delta, path flip, read-only overlap end, old server decommission. Put the dates on a calendar the office can see. The technical work is mostly copy and path changes. The week you lose, when you lose it, is almost always the week of unclear freezes, forgotten writers, and shortcuts that still point at a server that is no longer authoritative.