A National Insurance Brokerage Retired Its Own FTP Servers by Putting Files.com in Front of SharePoint

A national insurance brokerage was built at speed into a nationwide organization with thousands of employees. Alongside its commercial, personal, and benefits lines, it operates benefits-administration subsidiaries that act as third-party administrators for self-funded employer benefit plans. That work means regulated files, including HIPAA-protected health information, routinely move between the brokerage and outside parties.

Internally, the brokerage standardized on Microsoft. SharePoint comes with its Office 365 licensing and is where its people work with files: several hundred SharePoint sites, supported by a small IT organization of administrators, cybersecurity staff, and help desk covering thousands of employees. That combination set the problem up. A business whose daily work is exchanging files with external clients had standardized on a stack with no way to receive them.

No Path From an External Client Into SharePoint

Files arrived from clients, carriers, and benefits counterparties, and every one of them needed to end up in the right SharePoint document library where an internal team could work on it. The brokerage wanted each client isolated in its own upload space and every file replicated into SharePoint without a person in the middle. External uploads and hand syncing into SharePoint were the arrangement it set out to replace.

The gap was in the stack. Nothing in the Microsoft stack exposes SharePoint to an external SFTP or FTP counterparty, so the stack could not close the loop on external transfer.

The obvious workaround was to keep running their own FTP servers. A self-hosted FTP server is internet-facing infrastructure, and owning it means owning its DDoS protection and its hardening. For an IT team running a deliberately cloud-first estate, that was exactly the work the whole architecture existed to keep off its plate.

What the fix had to do was clear before any product entered the picture: give each client a unique, password-protected, isolated upload container; sync those containers to multiple SharePoint document libraries; and be run and defended by someone other than the brokerage. The brokerage selected Files.com to be that endpoint.

One Isolated Container Per Client, Feeding the Right Library

Files.com runs as the brokerage's public-facing SFTP and FTP endpoint, with SharePoint behind it. Each external client gets its own credentialed upload folder with per-user isolation, so a client connecting over SFTP sees only its own container and never another client's files. From there, Files.com Syncs replicate each container into the correct SharePoint document library, one-way or two-way depending on the exchange, and internal teams keep working in SharePoint exactly as before.

Where a partner's automated script deletes files after collecting them, the brokerage converted the two-way sync to a Files.com Remote Server Mount, so there is a single authoritative copy without a replication cycle.

Each subsidiary's endpoint runs under its own branded custom domain, so the counterparties of a benefits administrator connect to that business's own name rather than the parent's, and never see Files.com at all.

All That Is Left to Manage Is Accounts

With Files.com in production as the perimeter, the brokerage replaced external uploads and hand syncing into SharePoint with a repeatable pattern, and retired the FTP infrastructure it had been running itself.

• Every external client lands in its own isolated, credentialed container and replicates into the right SharePoint library on its own, including the regulated PHI exchanges its benefits subsidiaries run.
• Nobody syncs files to SharePoint by hand. Replication runs unattended.

SharePoint on the Inside, Files.com on the Outside

Today the division of labor at the brokerage is clean. Internal users work in SharePoint, where they always have. Every external counterparty connects to Files.com, under the right subsidiary's brand, into a container only they can see. Before, external uploads meant the team syncing files by hand and running internet-facing infrastructure. Now onboarding a client is account work for that same team. A Microsoft-standardized company does not have to build and guard its own transfer infrastructure to give SharePoint a secure external perimeter. Files.com is the external file transfer service Microsoft never built for it.