A Reverse-Logistics Provider Moved Its Partner File Exchange to Files.com Without Re-Integrating a Single Partner

A wireless reverse-logistics provider runs the after-market machinery of the wireless industry. When a phone is returned, damaged, or claimed under warranty, the company's reverse-logistics operation receives it, repairs or refurbishes it, and reports every step back to the carrier, manufacturer, or distributor that sent it.

What set the company apart from an ordinary repair operation was its information layer. Clients could see, at any time, where their devices stood. That means the product the company delivers is as much data as hardware: every device that moves generates records a customer is waiting for. And the primary channel for delivering that data, in both directions, was FTP. For the company, file transfer was not back-office plumbing. It was the front door of the service.

The company ultimately retired the servers without rebuilding those partner integrations. One carrier has used the same endpoint structure for more than ten years, with automated feeds moving thousands of XML files a day between systems.

A Primary Delivery Channel on Servers the Company Had to Operate

That front door ran on the company's own FTP servers. The company wanted its primary customer channel on infrastructure it did not have to run, with every login and every file encrypted in transit and at rest. The company also wanted every login and file action on the channel recorded, so it could show a partner exactly what was delivered and what was collected.

Because FTP was the primary delivery method, keeping the endpoint online was part of delivering the service, and the company wanted that job off its own hardware.

Every Partner Was Wired to the Old Servers

The servers were not internal plumbing. An entire partner base connected to them, and no two counterparties connected the same way. Electronics manufacturers, carriers, and vendors reached the sites from command-line clients, desktop tools, and fully automated ERP transfers with the address and credentials baked in. Moving off the servers meant moving every one of those counterparties to a new endpoint, with new IP addresses and new firewall rules, without interrupting data flows customers depended on every day.

So the replacement had to do four things at once. Encrypt credentials and data in transit, and store files encrypted at rest, meeting the HIPAA and Sarbanes-Oxley requirements that apply to the data. Keep speaking the FTP-family protocols every partner client already used, so nobody had to re-integrate. Present a fixed, publishable set of addresses that partner network teams could whitelist once. And run on infrastructure that stayed up without the company operating a single server.

The company selected Files.com to be that endpoint.

A Parallel Run, a Published IP List, and a Hard Deadline

The director responsible for the estate ran the cutover in spring 2012. The old and new sites operated in parallel while partners moved, with a hard shutdown date for the legacy servers at the end of April 2012. Every one of the company's FTP accounts was recreated on Files.com as a secure FTPS account: logins encrypted, data encrypted in transit over TLS, files encrypted at rest on the platform.

The company's director wrote the partner-facing migration notice, explaining exactly what was changing and why. Partners could whitelist the platform's published endpoint once and continue using their existing clients and automations.

Because Files.com speaks FTP, FTPS, and SFTP natively, the partners' existing clients and automations kept working. Each needed a new address and, at most, a switch to explicit TLS. Nothing about how any partner worked had to change. Only where they pointed.

Encrypted in Transit and at Rest, and Nothing Left to Patch

By the end of April 2012, the legacy FTP sites were shut down and every customer feed ran through Files.com.

What changed for the operation:

• Credentials and customer data travel encrypted, and files sit encrypted at rest on the platform.
• Every login and file action against the site is recorded, and the company pulls file history over the Files.com REST API to confirm that uploads arrived and to reconcile exactly what a partner did or did not collect.
• There is no box for the company to patch, monitor, or bring back up; keeping the endpoint online became Files.com's job.
• The old estate did not linger. The legacy sites were fully retired within weeks of the cutover instead of surviving as a parallel channel.

The replacement also did things the old servers never could. When a client needed one specific file, without deserving a login to the whole site, or a file was too large to email, the company could hand them a single URL.

That one-off URL is what Files.com now calls a Share Link, and the company put it to work both for ad hoc deliveries and for a recurring process where the file had outgrown email entirely.

The larger result compounded. Bringing a partner onto the exchange became a repeatable motion: a folder tree, a credential, and a whitelist entry against a published endpoint. One carrier has used the same endpoint structure for more than ten years, and the site went on to carry the automated feeds behind the company's carrier programs, moving thousands of XML files a day between systems.

The Protocol Stayed, the Servers Didn't

Today, delivering data to one of the company's customers means writing to a folder on Files.com and letting the partner collect it: encrypted, logged, and sitting on an endpoint nobody at the company has to keep alive. It used to mean owning and operating the servers. The distance between those two states was a single migration: a notice, a published IP list, and a deadline.

That is the takeaway for anyone still running their own FTP estate. Retiring the server did not mean retiring the protocol or re-integrating the partner base. Every partner kept the client, the script, and the workflow they already had. What went away was the one thing the company never wanted to own: the servers it all pointed at. Files.com took over that job in spring 2012, and the old servers were gone within weeks.