A Sequencing Instrument Maker Scales On-Prem NetApp Sequencing Deliveries with Files.com

A sequencing instrument maker builds a next-generation sequencing instrument that pairs sequencing with high-resolution imaging to produce spatial images of tissue at subcellular resolution. Academic medical centers, cancer research programs, and pharmaceutical companies use it two ways. Some run the instrument in their own labs, and the company has a fleet of them deployed at client sites. Others send the company their samples: its services lab sequences and analyzes biopsy and tissue samples and returns the results as datasets.

Either way, what the client is waiting for is data, and the quantities are enormous. A single sequencing run generates a massive volume of raw data, and a full client delivery runs to multiple terabytes. All of it is born on premises: sequencers write to the company's NetApp storage. Handing a multi-terabyte dataset to an outside institution is not a side task at the company. It is the last step of the client service.

With Files.com, that delivery workflow absorbed manyfold growth without added transfer engineering, leaving the same IT and InfoSec team to support the entire company’s infrastructure.

Every Delivery Was a Manual Upload

The path from sequencer to client had grown up one delivery at a time. The NetApp systems held sequencer output in deeply nested folder structures, and users mounted those directories directly on their own workstations. Sharing anything externally meant a manual upload, every time, and nothing in the process confirmed that the client had received what was sent.

The cost landed on both sides of the handover. Internally, the IT team was hand-carrying terabytes as a routine part of client service. Externally, the institution waiting for sequencing results was waiting on a person's availability rather than a process. For genomic data, the company also wanted every delivered dataset to carry an owner and an expiration date, so nothing stays in storage after its purpose has passed.

The Obvious Fix Had Already Been Tried

A managed SFTP service is the standard answer, and the company had already attempted one. A build on AWS Transfer Family went nowhere. The team found it complex and convoluted to operate.

The harder constraint was where the data lives. Sequencer output is born on on-prem NetApp, reached through two separate Active Directory domains. Any cloud transfer endpoint meant re-uploading terabytes before each delivery, which doubled the work the fix was supposed to remove. And the workload kept growing: every instrument in the field and every new services client added deliveries to a process running on individual effort.

What the fix had to do was specific. Reach the NetApp systems where the data lands, without copying everything to the cloud first. Give each client institution a governed account, a notification when files arrive, and a way to verify the transfer. Delete sensitive data on a schedule. And carry the compliance paper that genomic data demands: a HIPAA BAA and a GDPR DPA. The company selected Files.com to be that delivery layer.

An Agent on the Storage Where the Data Is Born

Files.com became the delivery layer between the sequencer estate and every client institution, sitting in front of the NetApp rather than replacing it.

The company installed the Files.com Agent inside its network, and Files.com Remote Server Mounts presented the sequencer-output directories on the NetApp systems as ordinary folders on its Files.com site. The Agent connects outbound only, so nothing on the sequencing network is exposed to the internet. A dataset sitting on the NetApp is already on the delivery platform. Nobody uploads terabytes to a transfer server anymore; the transfer platform reads the storage the sequencers wrote to.

Every delivery starts with a short intake, and one question in it decides the account's whole lifecycle: is this a one-time delivery or an ongoing relationship? One-time clients get an account that is deleted when the delivery completes. Ongoing clients keep a standing account, so the next dataset needs no setup at all. When files land, Files.com sends the client an automated notification, and the client downloads over SFTP or in the browser, on the company's own branded domain. MD5 checksums exported against the SFTP logs confirm the client received the exact files, which answers the question every delivery ends on: did the data actually arrive?

Governance runs on its own clock. Client-facing files expire after a set period under a Files.com retention policy, so delivered datasets clean themselves up. Internal access runs through Azure SSO with two-factor authentication enforced, and the activity log backs the quarterly access audits the team runs.

From Terabytes a Month to Tens of Terabytes

With the Files.com workflow in production, the company replaced a per-client manual upload with one automated delivery path for the entire deployed fleet.

Volume through the workflow grew manyfold within months, from a few terabytes a month at go-live to tens of terabytes stored and transferred in a single month, absorbed on the same workflow with no transfer engineering added. Institutional-scale handovers became routine, with multiple client deliveries in a single month.

Delivered files delete themselves on schedule. No genomic dataset sits in client-facing storage past its retention window.

Adding the next client is an intake decision and an account. Adding the next instrument to the fleet adds volume, not process, so delivery capacity scales with the fleet rather than with the IT team's hours.

The Handover Became the Dependable Step

Today, the last step of the company's service no longer depends on who is available to carry the data. A run finishes, the output lands on the NetApp, and the client's account and notification are already in place, with the expiration clock starting at upload. The team that once hand-carried terabytes to every client now watches deliveries go out, get confirmed, and expire without touching them.

The company never had to move its data to fix its delivery. The sequencer output stayed on the NetApp where it was born, and Files.com mounted that storage and ran the delivery on top of it. For a company whose product is a multi-terabyte dataset, that turned the handover into the most dependable step in the operation.