A 340B Administrator Moved Its Workflows Off Axway MFT One at a Time

A healthcare pharmacy program administrator runs the federal 340B drug pricing program for hundreds of 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 the administrator serves and the major wholesalers and payers on the other side. None of that data originates with the administrator, and none of the systems on either end belong to it. 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 the company's own infrastructure.

An Exchange That Had Outgrown Its On-Premises Engine

The exchange had grown past what the on-premises engine was built to carry, and every workflow on it had a trading partner on the other end.

Inbound partner files arrived PGP-encrypted, and Axway's decryption failed on a handful of files out of every batch. 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 is a file that takes hours to run, and the company wanted it to complete on its own and deliver exactly once. One of the country's largest pharmaceutical wholesalers pulled its files from the on-premises origin server, and the company wanted that partner pulling from a hosted endpoint instead. 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 requirement was simple. The engine carrying the exchange between hundreds of healthcare providers and their wholesalers had to move onto a hosted platform that ran PGP, AS2, and multi-hour transfers as configuration.

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

The scale of the estate set the terms of the replacement. The company's exchange was several hundred automated file flows across its major wholesaler and payer partners: AS2 trading connections with exchanged certificates, PGP key relationships negotiated per partner, and an on-premises 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 the administrator'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.

The administrator 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. The company installed the Files.com Agent on the 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. A partner pull no longer depends on a connection into the company's own infrastructure. The multi-hour file moved over as well.

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 Across the Migrated Workflows

With the migrated workflows in production, the administrator runs partner exchanges that complete without anyone watching them.

• The multi-hour transfer now runs on Files.com, completes on its own, and delivers exactly once.
• 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 large wholesaler now pulls directly from Files.com instead of from the origin server.

The scale of what runs on the platform tells the rest. Several hundred Automations and Syncs move claims, pricing, and reference data across its major wholesaler and payer partners.

Axway still handles a residual intake folder and some downstream consumption as the company 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 files spend that time on none of it. The multi-hour transfer runs on its own and delivers exactly once, and nobody thinks about it.

What the administrator 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.