Pillr Health Moved 340B Workflows Off Axway MFT One at a Time

Pillr Health, formerly RxStrategies, administers the federal 340B drug pricing program for more than 300 hospitals, health systems, and federally qualified health centers across the United States. 340B lets eligible providers buy outpatient drugs at steep discounts, and the savings fund care for uninsured and low-income patients.

Administering 340B is, underneath everything else, a data-movement business. Pharmacy claims, drug pricing files, prescription records, and patient data move continuously between the covered entities Pillr serves and the major wholesalers and payers on the other side. None of that data originates with Pillr, and none of the systems on either end belong to Pillr. The company's product is the exchange itself: files arriving on time, decrypted correctly, and delivered exactly once. For years, the engine underneath that exchange was Axway, a legacy on-premises managed file transfer system running in Pillr's own infrastructure.

Axway Was Failing at Exactly the Jobs the Business Ran On

The failures were not occasional and they were not internal. Every one of them landed on a trading partner.

Inbound partner files arrived PGP-encrypted, and Axway's decryption failed on a handful of files out of every batch of roughly a hundred. Each failure meant a person finding the file and re-submitting it by hand so it could be decrypted again. That was not an incident; it was a routine, repeated on every batch.

The largest transfer in the estate, a file that takes hours to run, repeatedly got stuck in Axway and duplicated, which meant duplicate deliveries going out to the partner on the other end. One of the country's largest pharmaceutical wholesalers hit timeouts pulling files from the origin server. The estate had also outgrown the engine in plainer ways. Files too large for Axway to handle were routed through a separate transfer utility on the side.

Taken together, the diagnosis was simple. The engine carrying the exchange between hundreds of healthcare providers and their wholesalers had become unreliable at exactly the jobs the business depended on.

Hundreds of Live Connections and No Way to Cut Over at Once

A problem that visible does not survive for years without a reason. Pillr's exchange was several hundred automated file flows across six-plus major wholesaler and payer partners: AS2 trading connections with exchanged certificates, PGP key relationships negotiated per partner, and an on-premises Windows file server that was the origin or destination for many of the workflows. Every connection had an external counterparty on the other end, and none of those counterparties could be asked to break, retest, or reschedule for Pillr's convenience. A single synchronized cutover would have put the entire partner base at risk on one weekend.

So the replacement had to work differently. It had to speak the protocols the partners already used, SFTP, AS2, and PGP among them. It had to reach the on-premises server without re-architecting the workflows built around it. And it had to take over the estate one workflow at a time, running alongside Axway for as long as that took.

Pillr Health selected Files.com as that platform and ran the two side by side across several years, lifting each workflow as it came up in priority.

Bridge the Server, Then Lift the Workflows

The first move was to bridge the on-premises world. Pillr installed the Files.com Agent on the Windows file server and surfaced its folders inside Files.com through a Remote Server Mount. That meant workflows rooted on the server could move onto Files.com without changing where the data lived or what downstream systems expected.

A high-visibility workflow went next: the weekly pricing feed delivered to a major pharmacy benefit manager was run directly from the Agent. From there, the partner connections moved individually. An AS2 trading connection came off Axway and onto Files.com's built-in AS2 endpoint. The outbound connection to the large wholesaler was reconfigured so the wholesaler pulled directly from Files.com instead of reaching back to the origin server, which removed the timeouts from the path entirely. The multi-hour file that kept sticking in Axway was moved over.

PGP decryption itself moved into the platform. Inbound partner folders on Files.com were configured to decrypt automatically as files arrived, so decryption became a folder setting rather than a processing engine with its own failure modes and manual recovery step.

Several hundred Files.com Automations and Syncs now route and archive files across the estate. A dedicated staging child site let the team validate each workflow before it touched production. The pattern through every step was the same: Files.com became the partner-facing layer of the exchange, while the on-premises server kept its role behind it and Axway kept running until each workflow no longer needed it.

Clean Runs on the Transfers That Used to Fail

With the migrated workflows in production, Pillr Health replaced failure-prone paths with ones that complete without anyone watching them.

• The multi-hour transfer that repeatedly stuck and duplicated in Axway has run cleanly since it moved to Files.com.
• Inbound decryption happens automatically on the folder, and the re-submission work that Axway's decryption failures created on every batch is gone with it.
• The wholesaler that hit timeouts pulling from the origin server now pulls directly from Files.com.

The scale of what runs on the platform tells the rest. Several hundred Automations and Syncs move claims, pricing, and reference data across six-plus major wholesaler and payer partners, with more than 4,000 X12 EDI files uploaded in a single week.

“95% of Rx Strategies customers are going through files.com.”

Axway still handles a residual intake folder and some downstream consumption as Pillr continues moving the remaining workflows. But the approach compounds. The bridge to the on-premises server and the per-partner workflow pattern already exist, so standing up a new partner exchange is configuration on Files.com rather than a project against an appliance, and each workflow that moves follows a path that has already been proven in production.

Replacement Without a Cutover

Today, the migrated workflows carry the files of hundreds of healthcare organizations on Files.com, and the people who used to spend part of every batch re-submitting failed files spend that time on none of it. A stuck multi-hour transfer used to mean duplicate deliveries and an apology to a trading partner. Now the transfer runs, and nobody thinks about it.

What Pillr Health never did is schedule a cutover weekend. Each migrated workflow moved when it was ready, proved itself alongside Axway, and took its traffic with it, while the exchange stayed live for every partner the whole way through. That is the portable lesson in this story: a legacy MFT engine does not have to be replaced in one high-risk move. It can be displaced one workflow at a time, for as long as that takes, until the old engine simply has nothing left to do.