A Healthcare Document Processor Built a Cloud SFTP Perimeter on Files.com Without Moving Its Document Pipeline

A healthcare document processing provider is the digital mailroom for healthcare payers. Health plans, managed care organizations, and government agencies send it their incoming paper and electronic documents; the provider digitizes, classifies, indexes, and validates them, and returns finished data for claims adjudication, member communications, and compliance work. The operation is large: many millions of documents and claims a year, handled by a workforce of more than a thousand people across US locations and an offshore delivery center. The work is HIPAA-regulated end to end, and its digital mailroom carries HITRUST certification.

Most of the provider's client services are recurring and daily. A client's documents arrive every morning, and the finished product goes back the same way, over SFTP. For a business that is literally its clients' mailroom, client-facing file transfer is not a supporting system. It is the front door.

Every Client, Provisioned by Hand

That front door ran on the provider's own Windows infrastructure: several separate self-hosted SFTP sites, each serving a different audience with its own rule set, in front of on-premises file storage. Roughly a hundred clients and their individual user accounts ran through them, and every one of those clients had been set up by hand.

Bringing on a new client meant repeating the same manual sequence: build the folder structure, create a group, assign permissions and an IP whitelist, wire up the sync relationships to the on-premises shares, then create and assign the user accounts. The estate had been built one client at a time, and it could only be administered one client at a time. Onboarding pace was capped by engineer time, and at a book of roughly a hundred regulated healthcare clients, manual provisioning had become the binding constraint on moving the business forward.

Availability was chained to the same servers. When a host needed Windows updates or a restart, the client endpoint went down with it. For clients delivering documents daily, a maintenance window was a client-facing outage.

The Pipeline That Could Not Move

The obvious fix, moving everything to the cloud, was not available. The provider's imaging, indexing, and validation pipeline requires files to land on-premises, so the on-prem shares had to stay in the path. And those shares are not a simple target: the drive holding the SFTP folder structure sits behind an SMB Transparent Failover Cluster and is visible only on whichever node currently hosts the file share, switching between two hosts. That is why the self-hosted estate had survived as long as it did. It lived next to the pipeline it fed.

As the provider moved infrastructure to AWS, it needed to modernize its client-facing perimeter without moving its processing pipeline. It wanted client file transfer in the cloud, with identity running through Azure AD instead of hand-managed accounts. The replacement had to give clients an endpoint that stayed available regardless of on-prem maintenance, make the per-client setup standard enough to script a hundred times over, stay in step with a processing tier that failed over between hosts, and carry the evidence regulated healthcare clients required, including a BAA and a SOC 2 report their HITRUST auditors could keep on file.

The provider selected Files.com to be that client-facing transfer layer.

The Same Three Folders for Every Client

Clients on Files.com connect over SFTP, the protocol they already use, and every client gets the same shape: a client root containing an inbound folder, an outbound folder, and a test folder, with the client's account pinned to that root so the structure above it never drifts. A uniform tree is what makes the rest repeatable. Because every client looks the same, the sync relationships to the on-prem shares follow the same template, and a per-client group carries that client's permissions and IP whitelisting.

The provider's engineers then made the pattern executable. PowerShell scripts against the Files.com API create the folders, groups, users, and syncs, built to one target shape across the client book. A new client is a scripted run of the standard template rather than a procedure someone follows.

During onboarding or major changes, two-way sync is temporarily enabled in the client's test folder so both teams can exchange test decks and outputs, then disabled when testing ends. Around the whole endpoint, staff access runs through Azure AD single sign-on with two-factor authentication, and GeoIP blocking and brute-force protection sit in front of the site.

An Agent That Fails Over With the File Share

The harder problem was the bridge to the processing tier. The provider installed the Files.com Agent on both nodes of the Hyper-V failover cluster and tied it to the failover share as a clustered service. The cluster starts the Agent on whichever host has the active share, so the Agent follows the storage it serves and synchronization survives node failover. Because the Agent connects outbound only, nothing on the processing tier had to be opened to the internet.

The provider deliberately chose two-way syncs over a live mount for the client folders. With a mount, the on-prem server would sit inside every client request; with a sync, the files themselves live on Files.com, so clients keep reading and dropping files even while the on-prem server is down for updates or restarts, and the sync reconciles both sides when it returns. The Agent has run on the cluster this way since it was installed, and node failover has not stopped the syncing.

The compliance layer moved with the architecture. Files.com operates under a BAA with the provider, its SOC 2 report sits in the evidence the provider's HITRUST auditors review, and the provider's third-party risk assessment firm has run its own penetration test of the platform as part of its regular testing obligations.

For Clients on Files.com, Maintenance Windows Stopped Being Outages

With the Files.com workflow in production, the provider had a cloud endpoint and a repeatable per-client pattern for the clients migrated to it. The rollout remained parallel: new clients onboarded directly to Files.com while existing clients moved across on a schedule, easiest first, and the original on-premises sites stayed in service during the migration.

• Bringing on a new client is a scripted run of the standard template, covering the folders, group, permissions, IP whitelist, users, and syncs, instead of a manual sequence designed anew for each relationship.
• A maintenance window is no longer a client outage for clients on Files.com. Files live on Files.com, so clients keep delivering and retrieving documents while the on-prem server restarts, and the two-way sync catches up when it comes back.
• Cluster failover no longer threatens the transfer layer. The Agent has moved between nodes with the file share, with syncing continuing across each transition.
• The evidence regulated clients ask for is standing rather than assembled on demand: a BAA in place and a SOC 2 report on file for HITRUST auditors.

The Perimeter Moved Without the Pipeline

That is the part worth carrying away. The provider did not have to modernize its pipeline to modernize its perimeter. Files.com took over the client-facing side for each migrated client first, and the client book can now grow at the pace of the business rather than the pace of hand administration, while the pipeline that does the actual work stays exactly where it has to be.