A Life-Sciences Supplier Retired Its Self-Hosted FTP Servers With Files.com at MuleSoft’s Transfer Edge

A global life-sciences reagent supplier provides the raw materials of biological research: antibodies, proteins, assays, and the other reagents scientists use at the bench. Its online catalog is the storefront, which makes the company a retail operation running at global scale as much as a science company.

A retail operation at that scale is also an integration operation. Payroll, banking, benefits, an Oracle ERP, and a CDN sitting in front of the public website all exchange data constantly, and much of that data moves as files between the company and companies it does not control. FTP was never the supplier’s first choice for any of it. But some counterparties support nothing else, and a bank does not change its protocols because a customer asks.

Running and Patching Servers for a Protocol Nobody Chose

For years, the answer was to run FTP in-house. The company operated its own internal FTP service, on servers its own team hosted and patched. The servers existed only because of protocol decisions made by other companies, yet the uptime, the patching, and the security of them were entirely the company’s to own. And the flows crossing them were not peripheral. Bank statements, payroll files, and benefits data all depended on that infrastructure, so a team whose job was integrations spent part of it being a transfer-server operator, keeping machines alive for a protocol the business never wanted to host.

The dependency could not be engineered away. The counterparties that required FTP set the terms of the exchange, and refusing the protocol would have meant refusing the payroll file and the bank statement along with it. The only real question was who ran the servers.

What the supplier needed was a place for those files to land that spoke FTP and SFTP natively to any counterparty, that its integration platform could drop into and collect from, that kept data in the United Kingdom, and that gave each outside party a credential reaching only its own files. The company selected Files.com to be that landing zone and retired its own FTP servers.

A Landing Zone Between MuleSoft and Every FTP-Only Counterparty

Files.com sits in the middle of the company’s integration layer: the place files land, are held temporarily, and are picked up.

On one side are the counterparties. Any third party that can only deliver or collect over FTP connects to Files.com instead of to anything the company has to run. They connect at an address on the company’s own domain, so the endpoint carries the supplier’s name rather than a vendor’s, and each external party works under its own scoped credential.

On the other side is MuleSoft, the company’s primary integration platform. MuleSoft places files on Files.com for a counterparty to collect, or picks up what a counterparty has delivered and routes it onward into the business. That pattern carries the flows a company cannot drop: bank imports, statements, and bank communications; payroll; corporate credit card feeds; the benefits system; several Oracle ERP integrations; and a set of feeds for the internal data team.

The heaviest single flow is logging. Akamai, the CDN in front of the company’s website and applications, delivers its traffic logs over FTP. Those logs land on Files.com and are staged there before a log aggregation platform ingests them downstream.

The company’s Files.com site is region-locked to the United Kingdom, so every file staged on the platform stays in the UK for as long as it sits there.

Multi-Terabyte Months With No Servers to Patch

With Files.com as the landing zone, the company replaced transfer servers it patched itself with a standing pattern its FTP-dependent integrations have run through ever since.

The pattern has been tested at every scale the business has thrown at it:

• The company has run its entire FTP-dependent integration estate for years without operating or patching a single transfer server.
• Files.com carried the Oracle ERP go-live and the hypercare period that followed, including the large data imports a go-live produces.
• The platform absorbs the company’s annual autumn spike, which pushes multiple terabytes through in a peak month. Most traffic moves through service accounts with no person in the loop.
• When a new counterparty turns out to support only FTP, the answer already exists: a folder on the landing zone and a scoped credential, not another server.

FTP Became a Routing Decision, Not an Infrastructure Obligation

Today, when a bank or a benefits provider can exchange files no other way, the company’s integration team points it at Files.com, scopes it a credential, and wires MuleSoft to the folder. The team that used to keep transfer machines alive because other companies would not change now spends that attention on the integrations themselves.

The company kept the protocol and gave up the infrastructure. Files.com holds the FTP edge, MuleSoft orchestrates around it, and the servers the company once patched have been gone for years.