An Apparel Distributor Moves an Acquired Company’s FTP Footprint to Files.com, One Account at a Time

A North American wholesale distributor of blank apparel buys undecorated T-shirts, hoodies, and hats in bulk, by the container or trainload, and sells them on to the screen printers, embroiderers, and promotional product distributors who turn them into finished goods for end consumers.

It does this at serious scale, with distribution centers across North America. It reached that position in part by acquisition: its purchase of a competitor combined two of the industry’s largest suppliers into one company.

A business like this runs on machine-to-machine file exchange. Every order, every inventory update, and every invoice with the garment vendors who produce the clothing travels as an EDI file over FTP, and the distributor runs that exchange on Files.com.

Thousands of files a day, across dozens of vendors transacting around the clock, all under the distributor’s own branded domain. And a company that grows by acquisition inherits more than warehouses and brands. It inherits the acquired company’s file exchange too—creating the risk of running two parallel file-transfer infrastructures indefinitely.

An Acquisition Arrives With a Very Large FTP Footprint

The deal came with the acquired company’s entire external file-exchange operation: a standalone legacy FTP service, its own user accounts, and its own partners and customers wired directly to it.

That meant two platforms to secure. Two to administer. Two to pay for. And one of them was a legacy service the distributor never chose, carrying counterparties who had never heard of the distributor’s own systems.

The inherited estate could not simply be switched off, because the endpoints of an FTP estate belong to other people. The acquired company’s partners and customers had their own automation pointed at the old service: scheduled jobs, scripts, and transfer clients configured long ago. Shut the service down and every one of those transfers breaks on the same day, for counterparties the distributor did not control and could not coordinate. Meanwhile, the destination platform was not idle. The distributor’s own vendor EDI operation had to keep moving thousands of files a day the entire time.

So the consolidation had a specification before it had a tool. The destination had to speak the protocols the inherited counterparties already used, so nobody outside the company had to install or rewrite anything. It had to present under the distributor’s own name. It had to keep each migrated account in its own segregated path. And it had to let accounts move one at a time, over months, rather than in a single synchronized cutover.

The distributor already ran a platform that fit that specification. Its existing Files.com site became the destination for the combined estate.

One Account at a Time, With Only the Address to Change

Because Files.com speaks FTP, FTPS, and SFTP natively, an inherited counterparty could be repointed at the distributor’s site and keep connecting exactly as it always had: same protocol, same client, same scheduled jobs, with only the address changing. And since that address is the distributor’s own branded domain, what a partner connects to reads as the distributor, not as a third-party service.

That protocol compatibility is what made an incremental migration possible at all. Each inherited account could move on its own schedule. Accounts that had not yet moved kept working against the old service. Nothing forced independent counterparties to cut over on the same day.

On the Files.com side, folder permissions and root paths kept each migrated counterparty isolated in its own directory, separate from the distributor’s vendor EDI traffic and every other account’s data.

All of it ran alongside production. The same site carried the daily vendor exchange while the inherited footprint came across.

Half Again as Many Users, Still One Platform

As the inherited footprint moved to Files.com, the user base grew by roughly half in a single year, and the existing site absorbed that growth. Nothing new was stood up to receive the migrated accounts.

Those accounts were live, transacting counterparties, not carried-over dead weight. This was a working exchange changing address, not an archive changing hands. At the same time, the production EDI operation—thousands of files a day across dozens of vendors—kept running on the same Files.com site.

On Files.com, that growth did not create a second destination environment. The team that administered one exchange still administers one exchange. It is simply half again as large.

Growth by Acquisition, Without a Permanent Second Estate

Today, the accounts already migrated from the acquired company connect to the same Files.com site the distributor’s garment vendors do, under the distributor’s own name, while the remaining footprint continues moving across.

The distance traveled shows in what the acquisition first looked like: a second infrastructure to secure, administer, and pay for, serving counterparties the distributor could not disturb. The distributor did not have to choose between a risky one-day cutover and keeping two infrastructures indefinitely. Because Files.com already spoke the protocols those counterparties used, each account could move on its own schedule without requiring changes to its protocol, client, scripts, or scheduled jobs.