BroadTech Retired Its FTP Servers Without Re-Integrating Its Partner Network

BroadTech runs the after-market machinery of the wireless industry. When a phone is returned, damaged, or claimed under warranty, BroadTech's reverse-logistics operation receives it, repairs or refurbishes it, and reports every step back to the carrier, manufacturer, or distributor that sent it. Today the company is part of Assurant, the global specialty-protection provider whose device care network processes 20 million devices a year.

What set BroadTech apart from an ordinary repair operation was its information layer. Clients could see, at any time, where their devices stood. That means the product BroadTech 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 BroadTech, file transfer was not back-office plumbing. It was the front door of the service.

BroadTech 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 5,000 to 15,000 XML files a day between systems.

A Primary Delivery Channel Nobody Could Defend or Audit

That front door ran on BroadTech's own legacy FTP servers, and the company's primary customer channel ran on infrastructure it could neither defend nor verify. Each site was secured by a single login password, transmitted in plain text. Credentials crossed the internet in the clear, and so did the customer data behind them. Nothing in the channel was encrypted in transit.

Dennis Eldridge, the director responsible for the estate, put the problem in one sentence:

“Our old service was only secured by a non-encrypted login password. Although it was never hacked (to my knowledge)… how would I ever really know?”

That question had no answer, and it mattered beyond anyone's comfort. The data moving through the channel had to satisfy HIPAA and Sarbanes-Oxley requirements for protecting credentials and data in transit, and a plain-FTP configuration can meet neither.

The servers also went down. On several occasions the FTP sites were simply unavailable, and because FTP was the primary delivery method, every outage was visible to customers as an outage of BroadTech itself. A client waiting on the day's return data did not see a server problem. They saw their vendor not delivering.

Every Partner Was Wired to the Old Servers

The gap survived as long as it did for the usual reason: 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 Linux command-line clients, Windows desktop tools, and fully automated ERP transfers with the address and credentials baked in. Closing the security hole 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, so the channel could finally clear the HIPAA and Sarbanes-Oxley bar. 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 BroadTech operating a single server.

BroadTech selected Files.com to be that endpoint.

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

Eldridge ran the cutover himself 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 BroadTech FTP account 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.

He wrote the partner-facing migration notice himself, 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. Eldridge could tell his own partners, in the migration notice, exactly what they had gained:

“Your userid and password are no longer transmitted across the Internet in plain text, and the data that is transmitted is also encrypted. These security measures meet the requirements for both HIPAA and Sarbanes-Oxley.”

What changed for the operation:

• Credentials and customer data stopped crossing the internet in the clear. Both travel encrypted, and files sit encrypted at rest on the platform.
• The unanswerable question got an answer. Every login and file action against the site is recorded, and BroadTech 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.
• The customer-visible outages went with the servers. There is no box for BroadTech 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, BroadTech could hand them a single URL:

“The ability to generate a one-off URL that can be sent to a client to enable them to access one or more files on the FTP site – without having to give them a login access to the whole site.”

That one-off URL is what Files.com now calls a Share Link, and BroadTech 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 BroadTech's carrier programs, moving 5,000 to 15,000 XML files a day between systems.

The Protocol Stayed, the Servers Didn't

Today, delivering data to a BroadTech customer means writing to a folder on Files.com and letting the partner collect it: encrypted, logged, and sitting on an endpoint nobody at BroadTech has to keep alive. It used to mean owning the servers, the plain-text passwords, the outages customers noticed, and a question about interception that had no answer. 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 BroadTech never wanted to own: the unencrypted, unauditable box it all pointed at. Files.com took over that job in spring 2012, and the old servers were gone within weeks.