An Analytical-Instrument Maker Retired SolarWinds Serv-U and Made Files.com Its Company-Wide External File Exchange

A global analytical-instrument maker builds the instruments that analytical science runs on. Its chromatography and mass spectrometry systems sit in pharmaceutical, life-science, materials and food-testing laboratories around the world, supported by a workforce of thousands.

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 the company 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 to multiple gigabytes, and a whole project can run to many hundreds of gigabytes.

A SolarWinds Server the Company 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 the company's own data centre. The company's external file exchange depended on a server it 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 the company's business. Then the vendor question closed itself. SolarWinds carried one of the best-known security histories in the industry, and the company decided to remove SolarWinds products from its data centre entirely. The transfer server was on that list.

The server was only half the problem. Even while it ran, the company had no workable way to deliver large scientific data to the people outside the company who needed it. OneDrive was impractical for multi-gigabyte 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.

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 the company 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 thousands, of whom hundreds would need access, which meant administering accounts one at a time in a GUI was never an option.

The company selected Files.com to be that single external exchange layer.

One Hosted Exchange Layer on the Company's Own Domain

What the company built is one platform through which files cross the company boundary, running under its 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. The company created hundreds of 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 the company's 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 the company's 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 the Company Hosts

With the Files.com workflow in production, the company 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: multi-gigabyte files 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. The company 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.

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 the company 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.