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

Waters Corporation designs and sells the analytical instruments and software that pharmaceutical, life-science, materials, and food-testing labs run on: chromatography systems, mass spectrometers, and the informatics behind them. Waters operates globally with roughly 16,000 employees.

Around the instruments sits a business that runs on systems of record. Waters 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, Waters works over SFTP with a large roster of vendors and partners because, as Principal Cloud Engineer Stewart Beel puts it, “it’s easily usable by everybody.” At the same time, Waters’ 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 Waters was always going to have. Waters 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 Waters 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.

Waters 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 Waters’ own Azure tenant under Waters’ 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.

Waters built that layer with Files.com.

Azure Storage in the Back, Files.com in Front

Using Files.com Remote Server Mounts, Waters 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 Waters’ 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 Waters’.

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, Waters rolled out nothing at all. Because the storage account is Waters’ own, the same data reaches employees as a normal network share.

“It’s quite a good one for us because we can then have that data available to our users via a network share, but make it available to a third party via SFTP.”

Sorting the inbound traffic is automated too. Files.com Automations run each evening, 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, Waters 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 each evening. Nobody at Waters 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 Waters’ Azure tenant. Exchanged data sits under Waters’ own backup and retention rather than being parked on a transfer platform’s storage.
• The integration became a pattern rather than a project. Waters 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.

Waters’ 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 to 16–17 TB.

An Exchange Layer in Front of Data That Never Left Waters’ Azure Tenant

Today, when a third party needs data out of SAP or Salesforce, or has data to send back, Waters 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 Waters already governs. A Waters 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 Waters’ Azure tenant.

Waters 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 Waters’ Azure tenant.