Abcam Retired Its Self-Hosted FTP Servers With Files.com at MuleSoft’s Transfer Edge

Abcam supplies the raw materials of biological research: antibodies, proteins, assays, and the other reagents scientists use at the bench. The company supports roughly 750,000 researchers in more than 130 countries and was a pioneer of e-commerce in the life sciences. Its online catalog is the storefront, which makes Abcam 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 Abcam and companies it does not control. FTP was never Abcam’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. Abcam 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 Abcam’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 Abcam 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. Abcam 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 Abcam’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 Abcam has to run. They connect at an address on Abcam’s own domain, so the endpoint carries Abcam’s name rather than a vendor’s, and each external party works under its own scoped credential.

On the other side is MuleSoft, Abcam’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 Abcam’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 shared account for that flow recorded more than 300 distinct connecting systems or IP addresses in one 30-day period.

Abcam’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.

Ten-Terabyte Months With No Servers to Patch

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

“We used to run our own FTP service internally, but that involved us running servers and having to patch them, and we moved to you years ago. It’s been very successful ever since for those integrations that need FTP.”

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

• Abcam 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 Abcam’s annual autumn spike, which exceeded 10 TB transferred 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, Abcam’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.

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