A Computer Manufacturer Retired Its Warranty Repair FTP Server With Files.com—Without Changing the Address

A global computer manufacturer designs and builds laptops, desktops, displays, and Chromebooks for businesses, schools, and consumers. What it does not do is repair every one of those machines itself. Warranty service in the Americas runs through the company's own repair centers and authorized service providers within its worldwide network: independent shops and technicians who fix its hardware under the manufacturer's warranty.

Every one of those repairs runs on files. A technician rebuilding a laptop needs the right driver package. A Chromebook repair needs a recovery image. A repair center needs the diagnostic utilities the manufacturer's engineers produce. The company's engineering group builds those files, and outside technicians the company does not employ have to be able to download them on demand, or warranty repairs stop. That service model put a one-to-many file distribution channel at the center of the regional operation, reaching across the Americas.

The Whole Repair Channel Ran Through a Server the Manufacturer Kept Alive

Until 2017, that channel was a single self-hosted FTP server: hundreds of gigabytes of drivers, OS images, and repair utilities on a box the company's infrastructure team ran on premises. The protocol was not the problem. FTP still served a distributed population of repair shops. The problem was everything underneath it. The uptime, capacity, and maintenance of that hardware belonged to the company's own team, and repair work at external service locations depended on the one box staying up. Growing the repair-tool library meant growing a server the manufacturer maintained itself.

The server also survived longer than anyone would have designed it to, for a reason any infrastructure team will recognize: it was live, and its users were outside the building. Technicians across two continents already reached files through the company's hostname. Replacing the server meant relocating the entire data set and re-serving the same population over the same protocols without disrupting the endpoint the repair network relied on. A botched migration would not be an internal incident. It would land on every service provider in the channel.

So the replacement had a specific job: take the whole data set, answer over FTP, FTPS, and SFTP the way the old server did, and answer at the same hostname, so that from a repair shop's side nothing changed at all. The manufacturer selected Files.com to take the server's place.

The Full Data Set Moved Over a Weekend, on the Same Address

The company's infrastructure team ran the cutover itself in spring 2017. Using the Files.com desktop sync application, the team pushed the full local FTP data set up to its Files.com site in a window that opened at end of day on a Friday and ran through the weekend. A DNS CNAME pointed the company-branded hostname partners had always used at the Files.com site, so technicians kept logging in at the same address, over the same protocols, and now reached a branded web login as well. The team validated access on the branded domain the following week, and the old server's job was done.

The steady-state workflow is the same channel with no server under it. The manufacturer's engineering group uploads drivers, OS images, and repair utilities, including the recovery images Chromebook repairs depend on. Authorized service providers and repair centers across the Americas log in and download what a repair needs, over FTP, SFTP, or the browser.

In Production, With No FTP Server Left to Maintain

With the cutover complete, the manufacturer replaced a distribution channel it had to operate with one it only has to use.

• The on-premises FTP server was retired outright. The company runs no file transfer infrastructure of its own for this channel, and the server's uptime, capacity, and patching stopped being the infrastructure team's job in 2017.
• The repair network changed nothing. The same hostname and protocols carried over, so a migration whose risk sat outside the company's own walls landed without asking anything of the partners on the other side.
• The site has run continuously for years, serving the company's infrastructure, digital services, and web development teams and its repair network across the Americas.

The Address Outlived the Server

Today, a technician at an authorized service provider who needs a driver package or a Chromebook recovery image pulls it from the same address the repair network has always used. What changed is everything behind that address. Before 2017, that download depended on a server the company's infrastructure team kept alive, and a failure on that one box was a problem for warranty repairs across two continents. Since the cutover to Files.com, nobody at the company operates the machinery at all.

The migration proved something worth stating plainly: the partner-facing endpoint and the server behind it were never the same thing. The hostname and protocols were what service providers across its footprint actually depended on, and both survived the weekend untouched. Only the server was retired.