Imagenet Built a Cloud SFTP Perimeter on Files.com Without Moving Its Document Pipeline

Imagenet is the digital mailroom for healthcare payers. Health plans, managed care organizations, and government agencies send it their incoming paper and electronic documents; Imagenet digitizes, classifies, indexes, and validates them, and returns finished data for claims adjudication, member communications, and compliance work. The operation is large: more than 175 million documents and over 40 million medical claims a year, supporting payer clients that serve more than 150 health plans, with a workforce of over 1,000 people across ten U.S. locations and a delivery center in Manila. The work is HIPAA-regulated end to end, and its digital mailroom carries HITRUST certification.

Most of Imagenet'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.

One Hundred Clients, Provisioned by Hand

That front door ran on Imagenet's own Windows infrastructure: around seven separate self-hosted SFTP sites, each serving a different audience with its own rule set, in front of on-premises file storage. Roughly 100 clients and 200 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 100 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. Imagenet'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 Imagenet 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.

Imagenet 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.

Imagenet's engineers then made the pattern executable. PowerShell scripts against the Files.com API create the folders, groups, users, and syncs, built to a target shape of roughly 100 groups, 200 users, and 200 sync relationships 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. Imagenet 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.

Imagenet 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 May 2024, and node failover has not stopped the syncing.

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

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

With the Files.com workflow in production, Imagenet 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. By October 2024, more than a dozen clients and vendors were live with over 40 sync relationships running.

• 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 since May 2024, 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. Imagenet 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.