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

A US apparel manufacturer designs and develops its garments in-house and produces them through a contract manufacturing network overseas, and its products sell worldwide through distributors and licensees.

That structure runs on file exchange with companies the manufacturer does not control. A garment designed at headquarters reaches production as a spec sheet downloaded by a contract manufacturer overseas. The company'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 the company 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 the company'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 the company owned. The deeper cost was structural: the company'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, the company had to keep hosting one for everybody.

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 the company 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 the company. It had to be hosted, so patching stopped being the company's job. It had to speak the SFTP and FTP that partners' jobs and the company'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.

The company selected Files.com as that hosted endpoint. The senior engineer in the company'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 the company'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 the company 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, the company 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 the company'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.

Spec Sheets for Vendors With No IT Department

The second wave was the supply chain itself. The company's contract manufacturers across Asia-Pacific produce garments from its plans, and a spec sheet is the company'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 the company 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. 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 the company has used them to answer questions after the fact.

A Retirement Without a Cutover

Today, when a trading partner collects a file from one of the company's applications already moved to Files.com, no company-hosted 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. The company 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.