Waters Retired SolarWinds Serv-U and Made Files.com Its Company-Wide External File Exchange

Waters Corporation builds the instruments that analytical science runs on. Its liquid chromatography and mass spectrometry systems sit in pharmaceutical, life-science, materials and food-testing laboratories around the world, supported by roughly 16,000 employees.

An instrument maker's product is hardware, but a large share of its daily business is data. Instruments in customer labs produce raw data sets that customers need delivered back to them. A global service operation supports the installed base. And a wide estate of vendors and partners exchanges data with the systems Waters runs its business on, SAP and Salesforce among them. Files cross the company boundary constantly, and many of them are large: a single raw data file runs 1 to 5 GB, and a whole project can run to many hundreds of gigabytes.

A SolarWinds Server Waters Would No Longer Host, and Data It Could Not Deliver

Corporate file transfer ran on Serv-U, an on-premises FTP/SFTP server from SolarWinds, inside Waters' own data centre. Waters' external file exchange depended on a server the company no longer wanted to own, surrounded by workarounds that could not carry the data.

The team had already wanted out of self-hosting a transfer platform, with its own server to run and keep patched for a job that is not Waters' business. Then the vendor question closed itself. SolarWinds carried one of the best-known security histories in the industry, and Waters decided to remove SolarWinds products from its data centre entirely. The transfer server was on that list.

“At the time there was this big data breach at SolarWinds, and we wanted to remove all SolarWinds products from our data center.”

The server was only half the problem. Even while it ran, Waters had no workable way to deliver large scientific data to the people outside the company who needed it. OneDrive was impractical for 1 to 5 GB files, let alone projects of several hundred gigabytes, and file exchange with customers and vendors ran through manual processes. The workflow at stake was not internal housekeeping. It was returning customers their own instrument data, and it was throttled by tools that were never built to carry it.

What a Single Replacement Had to Serve

The reason no one tool had ever covered this traffic is that it has two very different audiences. On one side sit machines and counterparties: vendors and partners pulling data extracted from SAP and Salesforce for analytics, accounting and auditing, and pushing results back, over SFTP. On the other side sit ordinary employees who need to send a customer a data set and cannot be asked to install and drive an SFTP client.

Stewart Beel, the Principal Cloud Engineer who owned the replacement, wrote the requirements accordingly. The platform had to be hosted, not another server in the data centre. It had to integrate with Azure Active Directory for single sign-on, so identity and MFA stayed in the directory Waters already ran. It had to give business users a web front end. And it had to speak SFTP anyway, for the counterparties who would use nothing else. All of it had to hold across a workforce of more than 7,000 employees when Waters selected the platform, of whom hundreds would need access, which meant administering accounts one at a time in a GUI was never an option.

Waters selected Files.com to be that single external exchange layer.

One Hosted Exchange Layer on Waters' Own Domain

What Waters built is one platform through which files cross the company boundary, running under Waters' own branded domain, with identity owned by the corporate directory and nothing left in the data centre.

Identity came first. Files.com authenticates users through Azure AD single sign-on, with MFA enforced upstream in Azure. Waters created more than 500 accounts in a single CSV upload and used Files.com groups and scripted permissions to govern access at that scale, rather than administering accounts one at a time.

For the human side of the traffic, Files.com Share Links became the delivery mechanism for customer data sets. A project of hundreds of gigabytes goes up through the Files.com desktop app and goes out as a link on Waters' own domain. Every link requires an internal note recording what it is for, carries an access log, and expires, so the business can account for every file it has ever sent out. Files.com Inboxes receive data from the other direction, and Files.com Automations route what arrives: uploads sort into date-stamped folders on a schedule, and files a customer uploads against a support case flow onward into the internal service desk.

For the machine side, SFTP on Files.com carries the vendor and partner estate. Third parties pull data originating in Waters' SAP and Salesforce systems and push data back over standing credentials, with SFTP key management handled on the platform, replacing the manual handling that used to sit in that path.

Users moved off the old platform in stages over several months rather than in a single cutover. Then the Serv-U server was turned off.

Volume Doubled on a Platform Nobody at Waters Hosts

With the Files.com workflow in production, Waters replaced a data-centre transfer server, and the manual and makeshift sharing around it, with one governed exchange layer. The results:

• Returning a customer's raw data is a standard workflow instead of a struggle: files of 1 to 5 GB and projects of many hundreds of gigabytes go out as branded, logged, expiring links.
• The SolarWinds server is gone and nothing took its place in the data centre. Waters no longer hosts or patches a file transfer platform.
• Every external exchange is accountable. Share links carry mandatory internal notes and access logs, and vendor traffic runs over managed SFTP credentials instead of manual processes.
• Adoption spread across the business without new infrastructure: customer service, HR, field and service engineering, network operations, finance and the EMEA informatics team all run workloads on the platform, and storage and transfer volume doubled year over year, from roughly 8 TB to more than 16 TB.

The compounding result matters as much as the immediate one. Because identity flows from Azure AD and provisioning runs in bulk, bringing a new team onto the platform is a CSV upload and a group assignment, not a project. That is how a system bought to replace one server became the exchange layer for the whole company.

The Exchange Layer the Old Server Never Was

The larger point is what Waters actually replaced, because it was never just Serv-U. Retiring an on-premises transfer server is also the moment to fix external large-file delivery, since the general-purpose sharing tools that grew up beside the server were never going to carry that traffic. Files.com took both jobs at once: the server's, and everything the server never did.