A European Pharmaceutical Company Replaces Microsoft Azure SFTP and Workstation Staging With Direct-to-Azure Transfers Through Files.com

A European pharmaceutical company discovers, develops and manufactures its own medicines.

A company that originates its own compounds does not run its research alone. Its R&D depends on data produced outside its walls. Contract research organizations run studies, universities and sequencing labs generate omics data, imaging partners produce bioimaging files, and at the end of a trial, final statistical reports and SAS analysis output go out to the FDA and EMA. Every one of those relationships is a file crossing the company's boundary. The data is GxP-classified, some of it is patient-level, and much of it is enormous.

Across four R&D workflows, the company used Files.com to replace Microsoft Azure native SFTP, its self-hosted SFTP service, and the process that routed partner data through scientists' workstations. External partners now push terabyte-scale datasets through Files.com directly into company-owned Azure storage, while two groups per workspace govern access instead of the previous model's more than 100 IAM roles.

Terabyte Datasets, Downloaded to Workstations by Hand

A single sequencing file can reach a terabyte. A whole dataset can run to terabytes, and individual bioimaging files run to hundreds of gigabytes.

That data reached the company the hard way. The company hosted its own SFTP server for partner exchange and used Azure's native SFTP alongside it. On the bioinformatics side, each CRO or research institution sent a link, a scientist pulled the dataset over SFTP down to their own workstation, and then pushed it back up into the internal Azure application where analysis happens. At these file sizes, that meant duplicate copies and long manual transfers in both directions, with a scientist's time and bandwidth spent moving data rather than working with it.

Outbound sharing had requirements of its own. The company wanted every recipient to authenticate, every share to expire and archive on a schedule, and the rare, proprietary binary formats bioimaging and sequencing produce to go out without an administrator whitelisting each one, which a previous sharing service had required.

The diagnosis was simple: the company's research data exchange had grown as a collection of one-off arrangements, and the company wanted one path that answers the question GxP asks in a single place. Who has access to which dataset, and who uploaded or downloaded what?

The Data Had to Land in the Company's Own Azure

Consolidating it was difficult. The company controls none of its partners' environments. Some CROs speak only SFTP. Universities run locked-down networks where installing a transfer client is not an option. And the route for external access was heavy: on the clinical side, partner access ran through more than 100 distinct IAM roles, and creating a role took weeks. Access that takes weeks per partner does not scale to the number of collaborations the company runs. As dataset sizes climbed into the hundreds of gigabytes, with GxP and GDPR obligations on every transfer, the company wanted the workstation out of the path and a single audit trail across every exchange.

Incoming data had to land directly in the company's own Azure storage, not in a vendor's storage that would need copy operations afterward. Every recipient, internal or external, had to authenticate. Every access had to be logged. Accounts and shares had to expire on their own. The teams that own the data had to be able to onboard their own partners without opening an IT ticket. And partners had to keep whatever tools they already had, from a browser to a Python script to a plain SFTP client.

The company selected Files.com to be that layer: a governed front door on storage it already owned.

Partners Now Push Through Files.com Into the Company's Storage

The build inverted the flow. Instead of the company pulling datasets down from each CRO's SFTP endpoint, external partners now push data into the company.

Using Files.com Remote Server Mounts, the company mounted its own Azure Data Lake Storage containers into the folders of each research workflow. A file a CRO uploads through Files.com is written directly into the company's container in real time. There is no intermediate storage, no copy job afterward, and no workstation anywhere in the path. The landing zone stays a landing zone: data moves on to its master analysis systems within a set period.

Partners use the path that fits them: a credentialed browser upload link, an automated pipeline through the Files.com CLI or Python SDK, or SFTP for tooling that requires it. That SFTP traffic now points at Files.com instead of a server the company has to run.

The company stood up all four workflows — omics, bioimaging, clinical data, and ad hoc vendor sharing — in a five-week phased build.

Two Groups per Workspace, Instead of a Hundred IAM Roles

Internal users are provisioned from Entra ID, with single sign-on, group synchronization, and device-trust checks enforced upstream. Each workflow runs as a Files.com workspace with exactly two groups, workspace administrator and contributor. That two-group model replaced the more than 100 IAM roles the old partner-access approach required.

External users are created inside the one workspace that concerns them and nowhere else, and workspace and folder administrators onboard partners themselves. Patient-level clinical trial data got harder separation: its own Files.com child site with its own dedicated administrators, so managing clinical access never intersects with any other user group.

Lifecycle controls are automatic. Accounts disable after a period of inactivity, external accounts are time-limited, and shared data carries expiration. Every upload, download and permission change lands in Files.com's access logs and permission reports, which is the record the company's GxP workflows require. The data stays resident in the EU, with a BAA covering research data that may originate in the US.

Research Data That Never Touches a Workstation

With the four workflows in production, the company replaced its self-hosted SFTP server, Azure native SFTP, and the workstation staging workflow with one governed route into its own storage.

• Terabyte-scale datasets from CROs, universities and imaging partners arrive directly in the company's own Azure containers. No scientist downloads them to a workstation, and no one re-uploads them into the analysis environment by hand.
• Granting a partner access is done by the team that owns the workspace, under the two-group model, instead of a weeks-long role-engineering exercise for each new relationship.
• Within these workflows, inbound and outbound research data travels one path where every recipient authenticates, every access is logged, and access ends on its own through lifecycle rules and expiration.
• The pattern repeats. Each workflow is a workspace, a mount into the company's storage, and two groups, so bringing the next partner or the next data stream onto the platform is configuration, not a project.

One Governed Crossing at the Company Boundary

Today, a bioinformatician who once had to shepherd a sequencing run from a CRO's server through a workstation and back up into the analysis platform finds the data already in the company's own containers, complete and logged, without ever handling it. A study team brings its next imaging partner onboard from inside its own workspace, with no ticket to IT. And when a collaboration goes quiet, the access goes with it, because Files.com's lifecycle rules count down on their own.

The company did not buy another place to put files. It put Files.com in front of the Azure storage it already owned and inverted the exchange, so that partners push data across a boundary it governs, using the tools they already had.