S&S Activewear Moves alphabroder’s FTP Footprint to Files.com, One Account at a Time

S&S Activewear is a wholesale distributor of blank apparel. It buys undecorated T-shirts, hoodies, and hats in bulk, in what VP of Engineering Brian Tanquary calls “containers or trainloads,” 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 18 distribution centers across North America, S&S is the second-largest supplier in the promotional products industry. It reached that position in part by acquisition: its 2024 purchase of alphabroder combined the industry’s second- and third-ranked 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 S&S runs that exchange on Files.com.

“We use Files.com for our FTP as a service, and we’re exchanging thousands of files with these vendors every day.”

Thousands of files a day, across 40 to 50 vendors transacting around the clock, all under S&S’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

In 2024, S&S acquired alphabroder, and the deal came with that 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 S&S never chose, carrying counterparties who had never heard of S&S’s own systems.

The inherited estate could not simply be switched off, because the endpoints of an FTP estate belong to other people. alphabroder’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 S&S did not control and could not coordinate. Meanwhile, the destination platform was not idle. S&S’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 S&S had to install or rewrite anything. It had to present under S&S’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.

S&S 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 S&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 S&S’s own branded domain, what a partner connects to reads as S&S, 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 S&S’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 40 to 50 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 alphabroder connect to the same Files.com site S&S’s garment vendors do, under S&S’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 S&S could not disturb. S&S 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.