One Counterparty at a Time, Jockey Moves Off Its Progress Ipswitch FTP Server With Files.com

Jockey International invented the brief. The company began in 1876 making wool socks for lumberjacks, sold the world's first brief at a Chicago department store in 1934, and is still a third-generation, family-owned business headquartered in Kenosha, Wisconsin. Today it is the leading undergarment brand in the U.S. department store channel. Jockey designs and develops its garments in-house and produces them through a contract manufacturing network concentrated in Asia and Central America, and Jockey-brand products sell worldwide through distributors and licensees.

That structure runs on file exchange with companies Jockey does not control. A garment designed in Wisconsin reaches production as a spec sheet downloaded by a contract manufacturer overseas. Jockey's business applications move data with trading partners across the internet. For years, nearly all of it passed through one front door: a secure FTP server Jockey hosted itself. Because those counterparties could move only on their own schedules, replacing it would require a parallel migration rather than a single cutover.

Patching a Server the Outside World Depended On

That server was a Progress Ipswitch FTP server, running on-premise under Jockey's own domain. It did the job for a long time, and it charged for it. Every maintenance window had to cover its patching, and its storage kept growing on hardware Jockey owned. The deeper cost was structural: Jockey's applications, fronted by a legacy Microsoft BizTalk integration layer, needed to move data to trading partners on the internet, and those partners ran no SFTP service of their own. As long as that was true, Jockey had to keep hosting one for everybody.

“We've run our own in-house FTP server from Progress, the Ipswitch FTP server, so we had secure FTP, but it's getting to be more of a problem to keep it patched throughout the windows, and it's using up this storage.”

The server also could not simply be turned off. Its dependents were other companies: trading partners with automated jobs, garment vendors across Asia-Pacific, each pointed at an endpoint they had used for years, each needing to be moved on its own schedule. The server stayed, and its patching and storage burden stayed with it on infrastructure Jockey no longer wanted to be in the business of running at all.

What the Replacement Had to Do

Retiring the server meant finding a replacement that suited the counterparties as much as it suited Jockey. It had to be hosted, so patching stopped being Jockey's job. It had to speak the SFTP and FTP that partners' jobs and Jockey's applications already speak, so moving a counterparty meant changing a hostname and a credential rather than re-engineering a workflow. It had to support accounts scoped to read-only for vendors with no IT staff. It had to log every transfer as a matter of course, because the question of who pulled which file only ever arrives after the fact. And it had to run alongside the old server for as long as the migration took, because the migration would happen one counterparty at a time.

Jockey selected Files.com as that hosted endpoint. Tim Anderson, the senior engineer in Jockey's infrastructure group who owns the migration end to end, brought Files.com up in parallel with the old server and began moving workloads in order of who could move: the application flows Jockey's own IT controlled first, then the external vendors. The migration remains underway: the marketing group and remaining third parties still use the old endpoint, while each move is one more workload the on-premise server no longer carries.

A Clearinghouse Between BizTalk, AS400s, and the Internet

The first workloads to move were the ones where only Jockey had to change anything. Applications behind the BizTalk layer now deliver their output to Files.com over SFTP, and trading partners collect it from the same place. Files.com sits between the two as a clearinghouse. For those flows, Jockey no longer hosts an SFTP service for partners to reach, and the partners, who never had one, never have to build one.

The same pattern absorbed Jockey's AS400 systems. The AS400s are capable of secure FTP, but configuring the key files and identities it requires on them is a project in itself, and specifying that work to AS400 consultants proved harder still. Instead, AS400 output is staged internally and goes out to the world through Files.com, so nobody has to configure an SSH key on an AS400 at all.

“AS400s can do secure FTP, but it is using key files, identities. It's very difficult to explain to an AS400 consultant what an SSH key is. If I wasn't already bald, I'd be pulling out my hair.”

Spec Sheets for Vendors With No IT Department

The second wave was the supply chain itself. Jockey's contract manufacturers in the Philippines and across Asia-Pacific produce garments from Jockey's plans, and a spec sheet is Jockey's design in its most portable form. Many of these vendors have no IT staff, and language barriers make technical instruction difficult, so the workflow had to be the simplest thing that still left Jockey in control of how its plans travel.

On Files.com, that is a read-only account. A vendor connects over SFTP and downloads the spec sheets for the garment it is producing, and it can do nothing else: no uploads, no changes, no way for a plan to move "outside how the business has decided to transmit those plans," as Anderson puts it. Control is enforced by the account's permissions rather than by instructions a vendor would have to read, understand, and follow.

A Record Before Anyone Thinks to Ask

Moving a workload also puts every transfer on the record before anyone thinks to ask. Files.com's access logs show who pulled which file, at what time, and from where, and Jockey has used them to answer questions after the fact.

“They did pull this file at this time. This is where they did it.”

A Retirement Without a Cutover

Today, when a trading partner collects a file from one of Jockey's applications already moved to Files.com, no Jockey server sits on either end of the exchange. And when a maintenance window arrives, the traffic already moved to Files.com is traffic the on-premise server no longer has to be kept alive for.

The migration never depended on a cutover date, because a server with years of external dependents never offers one. Jockey put Files.com alongside the old endpoint, moved the counterparties it controlled first, and let every move shrink what the server still carries. The old system did not have to go all at once. It only had to stop being the front door.