Waters Replaced SolarWinds Serv-U Beneath Hundreds of Hardwired Lab Instruments Without Touching One

Waters Corporation builds the instruments that regulated science runs on. Its chromatography, mass spectrometry, and thermal analysis systems do the quantitative work in pharmaceutical QA/QC, life-science, and materials labs. Today Waters is a roughly $6.4 billion business with about 16,000 employees.

An instrument company is also a service company. That support runs on data. An instrument in a customer's lab uploads a diagnostic package when a fault occurs, and a Waters engineer works from it. Those instruments stay in service for decades, so whatever server they upload to has to stay reachable just as long.

Waters also grows by acquisition. Wyatt Technology came with its own installed base of instruments in customer labs and an on-premises SolarWinds Serv-U server receiving their diagnostic uploads. Hundreds of those instruments had the server's address and credentials hardwired into decades-old software and already trusted its SSH host key. Waters needed to replace the server without touching the instruments.

The Acquisition Came With a Server Waters Had Already Left Behind

The on-premises SolarWinds Serv-U FTP/SFTP host in Wyatt's own environment received diagnostic uploads from hundreds of medical and scientific instruments in the field. Waters knew the product well. It had retired the same software from its own data centre years earlier and moved its corporate file exchange onto Files.com; the acquisition put a copy of it right back into the estate. The team's verdict on the inherited server was blunt: they deemed it insecure.

The cost was not hypothetical. Every day the server ran, Waters was self-hosting a transfer product it did not trust, outside the platform where the rest of its file exchange is governed and logged. And the traffic it carried was the worst kind to gamble with. A Wyatt instrument only uploads a diagnostic package when a customer reports a fault, so every file crossing that server was a customer waiting on a fix. The uploads are infrequent, but each one is urgent.

Hundreds of Instruments, Hardwired to a Server Nobody Could Repoint

The obvious retirement path was closed. To move traffic off a server, you normally repoint the clients at a new one. But the clients here are scientific and medical instruments whose software shipped 15 to 20 years ago, with the server's address and the credentials for a single service account embedded in it. Those credentials cannot be changed from the instrument side. Re-credentialing the fleet would have meant visiting hundreds of customer labs, one instrument at a time. And the endpoint could not simply go dark in the meantime, because uploads arrive at exactly the moment a customer has a broken instrument.

So the problem had a strange shape: the server had to change underneath a fleet that would never know it changed. The replacement had to answer at the same hostname, accept the same account name and password, and present the same SSH host key, because an SFTP client that sees an unfamiliar host key refuses to connect. Miss any one of those and hundreds of instruments start failing silently, at exactly the moment their owners need them heard.

Waters chose to absorb Wyatt onto Files.com, the platform already carrying its corporate file exchange, as a child site built to stand in for the old server completely.

A Child Site Built to Answer as the Old Server

Waters created a Files.com child site that kept Wyatt's domain, users, accounts, and security settings separate while allowing the team to administer it from the parent account. The team gave it the retiring server's own hostname as its custom domain, so the address embedded in the instruments would lead to the child site the moment DNS moved.

Then came the identity work. The team recreated the fleet's service account on the child site with the exact credentials the instruments already carry. Files.com can import an existing server's SSH host key, so the child site presents the same cryptographic identity the fleet has trusted for two decades. A connecting instrument sees not just a server that accepts its login, but the server it has always known.

The cutover itself was a DNS change, made in a low-traffic window: Waters pointed the old hostname's DNS record at the child site, and the next diagnostic upload landed on Files.com. There was nothing to migrate. The on-premises Serv-U server was switched off and retired.

The structure matters beyond the cutover. Because Wyatt runs as a child site rather than a separate product, its traffic lives under its own domain and its own settings, while Waters administers it from the parent site next to the rest of the company's file operations. The acquired entity gets hard separation, and administration stays in one place.

Four to Five Weeks From Kickoff to a Retired Server

With the DNS change made, Waters had replaced an inherited, self-hosted transfer server with a governed Files.com child site, and no instrument anywhere knew anything had happened.

• The acquired company's file transfer infrastructure was retired in four to five weeks from kickoff, with no data migration. A server retirement that looked like a fleet-recall problem ran as a configuration project.
• Not one of the hundreds of instruments in customer labs was touched. Equipment that has been in the field for up to two decades kept uploading exactly as it always had.
• The Serv-U product the team deemed insecure is out of the estate. Diagnostic uploads now land on the same platform that carries the rest of Waters' file exchange, logged and administered from the parent site.

The larger result is a pattern Waters can reuse for future acquisitions: isolate the acquired entity on a child site while bringing its file transfer under central administration.

What Absorbing an Acquisition Looks Like Now

Today, when a Wyatt instrument in a customer's lab develops a fault, its diagnostic package lands on Files.com. The address in its twenty-year-old software has not changed, and neither has the account or the key it trusts. What changed is everything behind them: a Waters engineer now works from data that arrived on the platform the company governs, instead of on an inherited server the team did not trust and could not turn off.

Before the cutover, retiring that server looked impossible without re-credentialing a fleet nobody could reach. What Waters proved is that the fleet was never loyal to the server. It was loyal to a hostname, a credential and a host key, and all three moved to Files.com while the machine behind them was switched off.