Trucordia Retired Its Own FTP Servers by Putting Files.com in Front of SharePoint

Trucordia, the national insurance brokerage formerly known as PCF Insurance Services, was built at speed. It grew into a nationwide organization with about 4,000 employees. Alongside its commercial, personal, and benefits lines, it operates benefits-administration subsidiaries, Direct Care Administrators and Paylogics, 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 Trucordia and outside parties.

Internally, Trucordia 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. What Trucordia had instead was blind uploads: external clients dropping files into shared, undifferentiated folders, with staff manually syncing the contents over to SharePoint. Clients were not isolated from one another, and manual handling sat in the middle of exchanges that included protected health information.

The gap was structural, not procedural. As Thomas Turney, Trucordia's Senior Systems Engineer, put it:

“Microsoft does not have an FTP service that connects to it, and you guys do, so that was easy.”

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, and that was the trap. A self-hosted FTP server is internet-facing infrastructure, and owning it means owning its DDoS protection, its hardening, and its exposure to compromise. For a small IT team running a deliberately cloud-first estate, that was exactly the liability the whole architecture existed to avoid.

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 Trucordia. Trucordia selected Files.com to be that endpoint.

One Isolated Container Per Client, Feeding the Right Library

Files.com runs as Trucordia'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, Trucordia 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, Trucordia replaced blind shared-folder uploads and hand syncing with a repeatable pattern, and retired the FTP infrastructure it had been securing 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, with critical folders refreshed every 15 minutes.

“The biggest thing is that by setting up an FTP server, I own the infrastructure. I don't have to worry about people trying to DDoS my FTP server or the server infrastructure itself getting compromised. All I have to deal with is accounts.”

SharePoint on the Inside, Files.com on the Outside

Today the division of labor at Trucordia 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 left a small team managing blind shared folders and defending 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.