A National Medical Association Moves Publishing from SharePoint to Azure Files with Files.com

A national medical association with tens of thousands of physician members is also a publisher. Its largest operating department produces the books and journals its specialty runs on, and publishing is one of the association's main revenue drivers. That business is made of files: manuscripts in progress, moving back and forth between association staff and the outside authors, editors, and designers who shape them. Most of those collaborators are practicing clinicians. Their work is seeing patients, not managing software.

Files.com gave the association a way to carve publishing out one library at a time, moving its files from SharePoint to Azure Files while the rest of the association stayed put. It became both the migration engine and the browser-based workspace for publishing staff and outside collaborators.

Publishing Could Not Work in SharePoint

Three years earlier, the association had moved the whole organization off on-premises storage and onto SharePoint. For most departments it worked. For publishing it did not. The department's primary document library held hundreds of thousands of files, and at that scale SharePoint's syncing broke down, with large files making it worse.

The sharpest edge was external. Sharing a manuscript with an outside author meant a SharePoint or OneDrive link, and for the clinicians on the receiving end, those links failed often enough that staff gave up on them.

One of the association's main revenue drivers was operating around its file platform instead of on it, and its review cycle with authors was collapsing into paper and postage.

The Way Out Was Blocked at 100,000 Files

The association's IT team knew where the department's files belonged: Azure Files, real file storage that publishing could work against directly. Getting them there was the problem. The team tried to run the migration with PowerShell and Power Automate, and both stalled. Power Automate stops at 100,000 files, against a library holding far more than that. Neither tool reported which files errored, so a partial run left the team guessing about what had actually moved. And the primary library was only the start: several terabytes were spread across the document libraries that had to move.

The move also had to be contained. The rest of the organization stays on SharePoint, so replacing it wholesale was never the plan. Publishing had to be carved out one document library at a time, without disrupting anyone else's storage.

That defined what the fix had to do: move hundreds of thousands of files and terabytes of data, with logging and per-file error visibility; keep SharePoint live while each library moved; sign staff in through the Entra ID identity the association already ran; and give an outside author a link that works in any browser. The association selected Files.com to do all of it, as both the engine that ran the migration and the platform the department works on now.

Files.com as Migration Engine and Daily Platform

Files.com mounted both sides of the move. With Remote Server Mounts, the SharePoint libraries and the Azure Files destination appeared as folders on a single Files.com site, which turned the migration into a transfer between two folders rather than an export project.

The migration itself ran as Files.com sync automations, one department library at a time. Sync was chosen for reliability against large file counts and deeply nested folder structures, and it carried no file-count ceiling. Every run landed in the automation log, recording what moved and what errored: the visibility PowerShell and Power Automate never provided. SharePoint access stayed live in parallel through each move, until the sync completed and the department confirmed the transition, and delta syncs verified each cutover afterward. No one stopped working while their library moved.

Publishing staff now use their existing association sign-in, with group-level permissions deciding who reaches which folders. Behind the sign-in, their workspace is Azure Files, presented through Files.com as ordinary folders.

For outside authors, Files.com Share Links replaced the link that never worked. An editor shares a work-in-progress book as a project-scoped link; the author opens it in a browser, downloads the manuscript, and uploads the marked-up version back through the same page. No account, no client software, nothing to sync.

Three Libraries Moved, and a Pattern for the Rest

With the first cutovers complete, the association replaced a migration that could not run and a sharing workflow that ended at the post office.

• Three SharePoint sites are migrated to Azure Files, verified with delta syncs and confirmed by the staff who work in them. The association's Power Automate approach could not perform the move past its 100,000-file limit.
• The migration is now a pattern instead of a project: mount the next department library, sync it, confirm it. The remaining libraries follow a process already proven.
• Outside authors get a link that works in any browser and send their changes back through the same page. The print-and-mail fallback is gone.
• Publishing was carved out without touching anyone else. The rest of the association kept working in SharePoint through every cutover.

A Department on the Right Infrastructure

Today, an editor at the association shares a book in progress with its author as a Files.com link, and the author, a practicing clinician, opens it in a browser and sends the marked-up chapters back through the same page. Nobody prints a manuscript. Nobody mails one. Behind that link, files from the migrated libraries live in Azure Files, fronted by Files.com and reached through the same sign-in as everything else at the association.

The association did not have to move the whole organization off SharePoint. Files.com became both the engine for each library’s move and the workspace publishing users land on as their libraries cut over.