A Pharmacy Benefits Company Moves Partner Claims Feeds Off You've Got Files and Into Azure With Files.com

A US pharmacy benefits company administers health plans as a third-party administrator, manages pharmacy benefits, and runs its own mail-order pharmacy fulfillment for employer clients.

That business runs on data that arrives from outside. Eligibility and claims files exchanged with third-party administrators and employer groups determine whether a member is covered and whether a claim pays. Each of those feeds is a file crossing between the company and a partner whose systems the company does not control, and every one of them carries HIPAA-regulated data.

A Cloud Data Platform Fed by a Server in a Building

The company was modernizing its data platform around Azure. Partner files were destined for an Azure database, some ingested directly and some transformed first through the company's own ETL processes. But the transfer layer feeding that platform was You've Got Files, an on-premise SFTP service carrying the company's legacy partner connections.

The old service could receive a file, and that was the end of what it could do. It offered no alerting, no notifications, and no way to direct an arriving file onward into the Azure environment. A partner feed landed on a server on-premise and waited for someone to move it into the pipeline.

The company had outgrown a transfer layer that could accept files but could not participate in what happened to them. The company's Director of Infrastructure and Operations defined the requirement plainly: a secure file transfer system with alerting, notifications, and the ability to direct files into Azure environments, and it had to be cloud hosted. Just as important, it had to let the company migrate legacy connections one at a time while partners still on You've Got Files kept exchanging files.

Why the Estate Couldn't Move in One Cutover

The harder problem was not choosing a new platform. It was that many external partners each held a live SFTP connection and firewall rules pointed at the legacy service. These were regulated claims and eligibility feeds; a synchronized cutover that broke even a few of them would interrupt the raw material of the benefits-administration business.

The partners were also nothing like uniform. One required GPG encryption on its files. Others prohibited their own staff from touching outside storage sites at all, ruling out any web-based exchange. And the destination was not simply a new server: files had to flow onward into Azure Blob Storage for Data Factory ingestion, some straight to the database and some through ETL first.

So the replacement had to speak the SFTP the partners already ran, absorb each partner's constraints as configuration rather than exceptions, deliver files into the Azure pipeline on its own, and allow the estate to move one connection at a time. A data engineer at the company scoped exactly that, arriving with the SFTP requirements mapped and an architectural diagram of the data integration flow. The company selected Files.com to be that transfer layer.

The Front Door of the Azure Pipeline

Files.com became the managed file transfer layer wired directly into the company's data platform, not a file server sitting in front of it.

Using Files.com Remote Servers and directional Syncs, the company pulls inbound files from TPA-controlled SFTP endpoints into Files.com and pushes them onward to Azure Blob Storage, where Data Factory picks them up for database ingestion. Outbound movement runs the same way in reverse. For each migrated connection, a file now leaves a partner's server and arrives in Azure ready for ingestion with no one at the company touching it in between.

The migration itself was designed around partner firewalls. Before any connection moved, the company stood up its own branded transfer domain on Files.com, backed by dedicated IP addresses, and communicated those addresses to partners for whitelisting. That gave every partner a stable target to point at. With the front door in place, cutover ran partner by partner from November 2024, each connection remapped onto Files.com on its own schedule while the legacy service kept serving connections until their turn came. During the transition, a Files.com Automation archived copies of migrated feeds under a temporary retention window so files could be validated and reprocessed if anything looked wrong.

Per-partner requirements landed as folder configuration. When one partner required GPG, the company enabled Files.com's built-in GPG encryption on that partner's folders inside the same workflow. Partners whose organizations block access to outside storage sites were provisioned standard SFTP credentials, and the whole exchange runs under a signed HIPAA business associate agreement.

Business teams also send ad-hoc Excel and Word files through Files.com share links, so the documents that travel alongside the feeds move on the same governed platform.

A Repeatable Pattern for Every Partner Connection

With Files.com in production, migrated feeds now flow through a cloud platform that connects directly to the company's data pipeline.

• Eligibility and claims files flow from TPA-controlled servers into the Azure database, direct or through ETL, with nobody carrying them between systems.
• Onboarding the next TPA or employer feed follows a repeatable pattern: a remote server connection, a sync, and whatever that partner requires, whether GPG encryption or a plain SFTP credential, applied as configuration.

The compounding result is the pattern itself. Each additional partner feed now lands on an integration approach that already exists.

The Transfer Layer Became Part of the Data Platform

For each connection the company has moved, a partner feed used to end at a server in a building; now it ends in the Azure database, and the person who used to carry it does something else with that time. As the company adds or migrates an employer or TPA feed, it can point the platform at the partner's server and deliver the file where the analytics pipeline expects it.

The larger lesson is about the fear that keeps legacy SFTP servers running long past their usefulness: that too many partner firewalls point at them to ever move. The company treated that as the first problem to solve rather than the reason to stay. The stable domain and dedicated IPs went up before a single connection moved, and the company then migrated feeds endpoint by endpoint. You've Got Files continues serving the connections awaiting their turn while Files.com takes over the rest.