File and storage migration
The copy itself is routine. Most of the work is deciding where the files should live and who should see them, and finding what will break before the client’s staff do.
We move a client’s files between file servers, SharePoint, OneDrive, Dropbox, Google Drive and Egnyte, in either direction, with the structure and permissions planned before anything is copied.
Request a quote for this project- A mapped drive letterSpreadsheet links, templates, shortcuts and some business apps point at
S:\or\\server\share. Those links break when the drive goes. - Access granted to named peoplePermissions set directly on this folder, for individuals rather than groups, with inheritance broken below it.
- An old structure still in useNobody wants to delete it and people still save into it. Someone has to decide where it goes.
- A leading spaceInvisible in File Explorer. SharePoint and OneDrive don’t allow names that start or end with a space.
The path gets longer after the move. When a SharePoint library is synced to a PC, S:\Accounts & Admin\ becomes C:\Users\jane.citizen\Example Pty Ltd\Accounts and Admin - Documents\. The same file now sits past the 260-character path that many Windows applications still can’t open.
Six platforms, six sets of rules
A migration runs between two of these, in either direction. Most of the trouble comes from the gap between what the old platform allowed and what the new one will accept.
File server
A Windows share, usually a mapped drive, built up folder by folder over many years.
When it’s the source
- Permissions were set by hand over years: named people instead of groups, inheritance broken deep in the tree, accounts that no longer exist.
- Drive letters and
\\serverpaths are baked into spreadsheet links, templates, shortcuts and line-of-business apps. - Some files don’t belong in a synced cloud library at all: Access databases, Outlook PST files, accounting company files.
- There’s no version history to bring. Only the current copy of each file moves.
When it’s the destination
- Deep folder trees from the cloud can run past the path lengths older Windows apps cope with.
- Google Docs, Sheets and Slides have to become Word, Excel and PowerPoint files first.
- Sharing links from the old platform don’t come across. Access is rebuilt as security groups on the share.
SharePoint
Sites and document libraries, including the ones behind Microsoft Teams, rather than one big drive.
When it’s the source
- Files are spread across many sites and Teams, often with the same folder names in each.
- Version history, custom columns and sharing links don’t carry across to a file server or another platform. The client decides what matters before it’s left behind.
- Files shared with people outside the business need their access arranged again on the new platform.
When it’s the destination
- Names can’t contain
" * : < > ? / \ |, can’t start or end with a space, and some names are reserved outright, such asCON,PRNanddesktop.ini. - The whole path, file name included, is capped at 400 characters.
- Access works best set on whole sites and libraries. Hundreds of folders with their own permissions become hard to manage and harder to audit.
OneDrive
One person’s files, in their own Microsoft 365 account.
When it’s the source
- Team files often live in one person’s OneDrive and are shared from there. When that person leaves and their account goes, so do the shares.
- Shared links sent by email point at the old location and need replacing.
When it’s the destination
- It’s the right home for personal working files, not for a team’s shared data, which belongs somewhere that doesn’t depend on one account.
- The same naming and path rules as SharePoint apply.
Dropbox
Team folders and member folders, usually with a long trail of shared links.
When it’s the source
- Shared team data and personal folders are often mixed together, and it isn’t always clear which is which.
- Mac users can name files with characters that Windows and SharePoint refuse.
- Dropbox Paper documents aren’t ordinary files and need converting.
- Shared links in old emails stop working once the data has moved.
When it’s the destination
- Team folders and who can open them are laid out before data lands, so nothing is shared by accident.
- Each person syncs what they need rather than the whole business.
Google Drive
My Drive for each person, shared drives for teams, and a lot of “Shared with me”.
When it’s the source
- Docs, Sheets and Slides convert to Word, Excel and PowerPoint. Formatting, comments and some formulas need checking afterwards.
- Drive allows two files with the same name in one folder, and slashes in names. Neither survives a move to Windows or SharePoint as is.
- Files in someone’s My Drive belong to that person, not the business, and “Shared with me” isn’t a folder structure anyone can copy.
When it’s the destination
- Team data goes into shared drives, so it stays with the business when people leave.
- Office files can stay as Office files or become Google files. The client decides that once, before the move, rather than leaving it to the default.
Egnyte
Shared and private folders, with access set folder by folder.
When it’s the source
- Egnyte’s access levels don’t line up one to one with NTFS, SharePoint or Google permissions, so each one is translated deliberately.
- Private folders per user sit alongside shared ones and need a home of their own.
When it’s the destination
- The shared folder layout and its groups are set up before data lands, rather than granted folder by folder afterwards.
The calls that decide whether it works
Every file migration comes down to a handful of decisions. Get them right and users barely notice the move. Get them wrong and the client has the same mess on a new platform.
-
Copy the old structure, or redesign it?
A straight copy is quickest, and keeps everything people dislike about the old drive. A full redesign turns into a project nobody has time to approve.
What usually works: redesign the top levels, where access differs between teams, and leave the inside of each folder as people already know it.
-
Who gets access to what?
Copying old permissions copies every grant to a person who changed roles or left.
What usually works: rebuild access around groups that match how the client works, such as Finance, Directors and All staff. Where one folder needs tighter access than its neighbours, it usually becomes its own library or shared drive instead of a folder with its own exceptions.
-
What shouldn’t move at all?
Moving everything means Access databases that corrupt in sync, PST files that never finish uploading, and years of closed work cluttering everyday folders.
What usually works: agree with the client what stays behind, what goes to a read-only archive location, and what needs its own plan. Agreed up front, so staff don’t find out after cutover.
-
Sync it, or open it from the web?
Syncing every library to every PC fills laptops and slows the sync client down for everyone.
What usually works: people sync the areas they work in each day and open the rest from the web or a shortcut.
-
When does everyone switch?
A weekend “big bang” copy of everything leaves no time to fix what the copy turns up.
What usually works: copy the bulk of the data while people keep working, then a final sync of recent changes at cutover. The old location is made read-only straight after, so nobody saves to the wrong place.
Staff keep working until the switch
The old location stays live while the new one is built, tested and filled. Only the last few changes move at cutover.
-
1Review and design
Old locationIn daily use. Structure, size and permissions reviewed.New locationStructure agreed with the client. Groups and permissions mapped. -
2Pilot
Old locationIn daily use.New locationA sample moved. A few users test opening, saving, links and sync. -
3Full copy
Old locationIn daily use.New locationThe bulk of the data copied in the background. -
4Cutover
Old locationFinal syncChanges since the full copy move across.New locationStaff switchAccess and sync set up for each user. -
5After
Old locationRead-onlyStill there to check against. Nobody can save to it.New locationWhere everyone works
The pilot is where the surprises turn up: names that won’t carry across, Google files that convert badly, a spreadsheet that links to S:\. They get fixed before cutover, while there’s still time.
What the client ends up with
Their files in a structure they agreed to, a record of who can open what and why, and a written account of everything that changed on the way.
Permissions map
| Was | Who had access | Now | Group | Access |
|---|---|---|---|---|
| S:\Accounts & Admin | Three named people, one disabled account | Finance site, Accounts library | Finance | Edit |
| S:\Accounts & Admin\Payroll | Two named people, inheritance broken | Finance site, Payroll library | Payroll | Edit |
| S:\Projects | Everyone | Projects site, Active library | All staff | Edit |
| S:\Clients - OLD do not use | Everyone | Archive site, Clients to 2019 | All staff | Read |
Payroll became its own library rather than a folder with an exception, so its access is visible at a glance.
Migrated files
Everything agreed, in the new structure, with access set through groups and each user connected the way they’ll work: synced, or opened from the web.
Migration report
- Renamed: leading space removed
␣Fee schedule and engagement terms FINAL v3 (signed).xlsx - Renamed: duplicate name in one Google Drive folder
Board pack.pdf → Board pack (2).pdf - Not migrated, by agreement
Thumbs.db, desktop.iniSystem files with no use on the new platform. - Flagged for a decision
Practice.accdbAn Access database doesn’t work reliably from a synced library. - Flagged: link to the old drive
Budget 2025.xlsx → S:\Accounts & Admin\Rates.xlsx
The report records what moved, what was renamed or left behind and why, so questions after cutover have an answer.
Delivered under your brand
We deliver it remotely as a white-label project, under your brand or as your named specialist partner. You keep the client and the ongoing support. We quote and invoice you a fixed price for the agreed scope.
Part of Microsoft 365 & data projects.