An Instrument Manufacturer Replaced SolarWinds Serv-U Beneath Hundreds of Hardwired Lab Instruments Without Touching One

A global analytical instrument manufacturer builds the instruments that regulated science runs on. Its chromatography and mass spectrometry systems do the quantitative work in pharmaceutical QA/QC, life-science, and materials labs.

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 service engineer works from it. Those instruments stay in service for decades, so whatever server they upload to has to stay reachable just as long.

The company also grows by acquisition. One acquired instrument maker 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 carry the server's connection settings in decades-old software and already trust its SSH host key. The company needed to replace the server without touching the instruments.

The Acquisition Came With a Server the Company Had Already Left Behind

The on-premises SolarWinds Serv-U FTP/SFTP host in the acquired company's own environment received diagnostic uploads from hundreds of medical and scientific instruments in the field. The manufacturer 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. It wanted the inherited traffic on the same governed platform as the rest of its file exchange.

The traffic made the timing matter. An acquired instrument only uploads a diagnostic package when a customer reports a fault, so every file crossing that server is a customer waiting on a fix. The uploads are infrequent, but each one is urgent.

Hundreds of Instruments That Could Not Be Repointed

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 connection settings built into it. Changing those settings means a visit to the instrument. Repointing 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 accounts, 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.

The manufacturer chose to absorb the acquired company 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

The manufacturer created a Files.com child site that kept the acquired company'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 carried the fleet's accounts onto the child site exactly as the instruments already use them. 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: the manufacturer 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 the acquired company runs as a child site rather than a separate product, its traffic lives under its own domain and its own settings, while the manufacturer 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, the manufacturer 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 inherited Serv-U server is out of the estate. Diagnostic uploads now land on the same platform that carries the rest of the manufacturer's file exchange, logged and administered from the parent site.

The larger result is a pattern the manufacturer 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 one of the acquired instruments 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 service engineer now works from data that arrived on the platform the company governs, instead of on a server inherited with the acquisition.

Before the cutover, retiring that server looked impossible without repointing a fleet spread across hundreds of customer labs. What the manufacturer proved is that the fleet was never loyal to the server. It was loyal to a hostname, an account and a host key, and all three moved to Files.com while the machine behind them was switched off.