An Instruments Maker Gives Partners SFTP and Employees Network-Share Access to One Azure Copy With Files.com

A global analytical instruments maker designs and sells the instruments and software that pharmaceutical, life-science, materials, and food-testing labs run on: chromatography systems, mass spectrometers, and the informatics behind them.

Around the instruments sits a business that runs on systems of record. The company holds its commercial and operational data in SAP and Salesforce, and a wide ring of outside firms needs data from those systems: third parties pull extracts for analytics, accounting, and auditing, and push data back. For that exchange, the company works over SFTP with a large roster of vendors and partners because it is easily usable by everybody. At the same time, the company’s own employees need the same data on the internal network where they already work. One data set, two audiences, two entirely different ways of reaching it: that is the problem the company was always going to have. The company solved it by putting Files.com in front of a single copy in its Azure tenant, serving partners over SFTP while employees kept using a network share.

One Data Set, Two Audiences, and No Bridge Between Them

An SFTP endpoint for outside parties and a network share for employees are architecturally different worlds. Serving both from the same bytes normally forces a bad choice. Either the data gets duplicated, with one copy on a transfer server for partners and another on internal storage for staff, or one audience gets a workflow that does not fit it.

Duplication is a standing tax. Every new third-party feed adds another copy to shuttle and another sync to keep honest, and before Files.com, that movement at the company ran through manual processes. Worse, retention and backup only apply to the copy sitting in storage the company controls. The other copy lives wherever the transfer tool put it, outside the governance that covers everything else.

The company wanted none of that. The fix had to present partners a governed SFTP endpoint, present employees an ordinary network share, and keep a single copy inside its own Azure tenant under its own backup and retention. It also had to do this without a custom sync layer between a transfer server and internal storage, the kind of infrastructure that gets built once and then owned forever.

The company built that layer with Files.com.

Azure Storage in the Back, Files.com in Front

Using Files.com Remote Server Mounts, the company pointed Files.com folders at storage accounts in its own Azure subscription. A mount is a pass-through, not a copy. When a partner uploads over SFTP, Files.com writes the file straight into the mounted Azure storage, so the bytes land in the company’s tenant the moment they arrive. Files.com supplies the SFTP endpoint and the access controls; the storage, and the retention and backup rules that govern it, stays the company’s.

On the external side, each third party connects to Files.com over SFTP, with folder- and group-level permissions scoping what it can push and pull. On the internal side, the company rolled out nothing at all. Because the storage account is the company’s own, the same data reaches employees as a normal network share.

Sorting the inbound traffic is automated too. Files.com Automations run on a schedule, moving partner uploads out of a staging area into the correct folder by date stamp, so incoming data is filed with nobody touching it.

One Copy, Served Two Ways

With the mounts in production, the company replaced duplicate data sets and manual movement with a single copy of the data, served two ways.

• Third parties push and pull data tied to SAP and Salesforce over SFTP, and inbound files are routed into their destination folders automatically on a schedule. Nobody at the company moves partner data by hand.
• Employees reach the same files as an ordinary network share, without ever opening Files.com. There is no second copy, and no sync layer to build, monitor, or hand over.
• The stored copy never leaves the company’s Azure tenant. Exchanged data sits under the company’s own backup and retention rather than being parked on a transfer platform’s storage.
• The integration became a pattern rather than a project. The company has repeated the Azure mount quite a few times across workloads, so standing up the next third-party feed means configuring another mount and a credential, not building another server or another pipeline.

The company’s broader Files.com footprint has grown alongside the business: across all its Files.com workloads, including the SAP and Salesforce exchange, combined storage and transfer volume doubled year over year.

An Exchange Layer in Front of Data That Never Left the Company’s Azure Tenant

Today, when a third party needs data out of SAP or Salesforce, or has data to send back, the company does not stand up a server or open a copy pipeline. The partner gets an SFTP credential into Files.com. The files land in storage the company already governs. An employee opens them from a network share the same way they open everything else. And the question that hangs over external exchange—where does this data actually live, and whose retention applies to it—has a fixed answer, because the data never leaves the company’s Azure tenant.

The company did not migrate its data onto an exchange platform. It put Files.com in front of the data, and left the data exactly where it was: in its own Azure tenant.