Liscaragh Migrate › Files and folders to SharePoint

Migrate file shares and local storage to SharePoint and OneDrive

A Windows file server, a NAS, or just a folder on someone's laptop, moving it into Microsoft 365 sounds simple until you actually try it at scale. Here is what catches people out, and the approach that avoids it.

Why drag-and-drop does not scale

For a handful of files, copying into a synced OneDrive or SharePoint folder in File Explorer works fine. For a real file share, whether it is a few hundred gigabytes on a Windows Server or a decade of accumulated folders on a NAS, it falls apart. There is no record of what actually copied, no handling of the names SharePoint rejects until the sync client silently skips them or throws an error you have to go hunting for, and no way to prove to a client or an auditor that everything arrived intact.

Sync clients are also built for ongoing use, not for a one-time bulk migration. They throttle unpredictably, struggle with very large folders, and give you a sync status icon rather than a per-file audit trail.

What trips a file share migration up

Three things catch nearly every migration into Microsoft 365, whatever tool you use. They are worth understanding before you start.

• The names SharePoint will not accept. Reserved names, illegal characters and a 400-character path limit that a Windows file server never enforced. Files and folders that have worked for years, sometimes over a decade, are simply rejected. The file and folder names SharePoint won't accept.
• OneDrive or SharePoint. A personal user folder and a shared project folder look identical sitting on a file server, but personal files belong in OneDrive and shared content belongs in a SharePoint site, and getting it wrong is expensive to unpick later. OneDrive or SharePoint? Decide before you migrate.
• Speed is not your bandwidth. Migration throughput is set by Microsoft 365's own API rate limits and how fast the source can be read, not your internet connection, so a faster line does not make it finish sooner. Your internet speed is not your migration speed.

Case-only duplicates: the one that is specific to file shares

Windows file systems are case-insensitive, so Report.docx and report.docx cannot exist in the same folder, but two files whose names differ only by case elsewhere in a folder tree, or a folder and a file that would collide once case is ignored, sometimes slip through on network shares assembled from multiple sources over the years. SharePoint is also case-insensitive, so these collide on arrival unless they are caught first. A proper migration flags them before copying, not after two files have silently overwritten each other.

The approach that works: read directly, tidy as you go

The reliable way to move a file share into Microsoft 365 is to read the source directly, whether that is a local drive, a mapped drive or a network path, and write straight into SharePoint or OneDrive over the Microsoft Graph API. Each file is read, uploaded, verified and recorded, one at a time, with reserved names, illegal characters and over-length paths corrected automatically before they cause a failure rather than after.

Linux, Mac and NAS sources

Liscaragh Migrate itself runs on Windows, and it reads a source the same way Windows Explorer would: a local path, a mapped drive letter, or a network path. That has a useful consequence. It does not need a Linux, Mac or NAS-specific connector, because it does not need one. Anything that can present itself to Windows as a network share, a Synology or QNAP NAS running its usual SMB service, a Mac with file sharing turned on, or a Linux server sharing a folder over Samba, is reachable the same way any Windows file server is. If you can already browse it from a Windows machine, Liscaragh Migrate can migrate it.

This is also where a specific pitfall lives. Linux and NAS devices usually run a case-sensitive filesystem underneath, so Invoice.pdf and invoice.pdf can genuinely exist side by side as two distinct files. Windows, and SharePoint, are not case-sensitive, so this is precisely where two real, different files collide into one on arrival if nothing catches it. Liscaragh Migrate flags case-only collisions before copying, rather than letting the second file silently overwrite the first. The same source systems are also more permissive about characters and trailing spaces or dots in a name than SharePoint is, which is exactly what the automatic name tidying is for.

If the share needs its own sign-in rather than the one you are already running the tool as, for example a NAS with a dedicated backup or migration account, that is stored once in Windows Credential Manager the first time you connect, the same way a normal mapped network drive would ask. See how to use the files and folders source and how we store your credentials for the detail.

Before you start

Whichever way you migrate, a short bit of planning saves a lot of rework. Decide which folders are personal (OneDrive) and which are shared (a SharePoint site) before you copy anything. Run a preview and review the list of names that will be tidied and any case-only collisions that get flagged. Run the migration close to the data, on a wired connection to the share rather than Wi-Fi, and without a VPN in the path if you can avoid one, since that does far more for speed than a faster internet line. And be aware that source share permissions and NTFS-level metadata do not come across the API, so plan for them separately if either is a compliance requirement.

Wondering whether this needs outside help at all? See migrating a file server without hiring a consultant for what a consultant actually does and which parts an internal team can safely handle alone.

Ready to look properly? Read about Liscaragh Migrate, check the FAQ, or ask us a question.