Imperial Brady Replaces Self-Hosted SFTP on AWS EC2 With Files.com as Accounts Grow From 20 to 190

Imperial Brady distributes foodservice packaging, janitorial and cleaning supplies, and industrial packaging across the United States and Canada, serving more than 120,000 customers in segments that run from restaurants and grocery to healthcare and cruise lines. The company took its current form in 2026, when Imperial Dade merged with BradyPLUS. The merger combined two of the category’s largest distributors into a business with 13,000 employees, second in its market only to Uline. The Files.com work began at Imperial Dade in 2022, and that transfer environment continued into Imperial Brady after the merger.

That scale was built one deal at a time. Since 2007, the business has grown largely by acquisition. Acquired businesses keep operating as named divisions, and each one arrives with its own systems: its own ERP, its own trading partners, its own way of moving order, warehouse, and inventory files. A centralized infrastructure team absorbs all of it. Those systems have no direct connectivity to one another. The one thing every one of them can do is send and receive a file, which makes the file transfer layer the layer the entire company runs across.

A Hand-Built Transfer Layer Under a Company That Never Stops Changing

For years the company ran that layer itself. It began with a plain FTP server, which the infrastructure team started migrating away from because unencrypted FTP had no business carrying order and inventory data. The replacement was a self-hosted SFTP instance on an AWS EC2 machine, and it traded the security problem for an operational one. The instance supported only SSH-key authentication. Delivering password-authenticated SFTP in AWS meant assembling it by hand from multiple AWS services, and many trading partners expect nothing more exotic than a username and a password. Meanwhile a small infrastructure team owned everything about the server: the patching, the security, the management of a single machine that every EDI flow, ERP integration, and trading-partner exchange depended on.

What made that untenable was the pace of the business around it. The company opens new facilities constantly and acquires companies continuously; environments are stood up and torn down without pause. Every acquisition brought a new ERP with no connectivity to the rest of the estate and a new set of counterparties who needed accounts. All of it landed on one server that one team had to keep alive by hand, and the pace was never going to slow.

The replacement had to do specific things. It had to speak the protocols the partners and the legacy systems already used, so nothing on either side needed rebuilding. It had to offer password-authenticated SFTP as a native capability rather than a custom assembly. It had to keep each counterparty walled into its own space, and it had to take the patching and management burden off the internal team entirely. Imperial Brady selected Files.com to be that endpoint.

One Files.com Platform Across Systems and Counterparties

The initial request, in September 2022, was modest: around 20 accounts moving small CSV and text files. What was built on top of it made Files.com the common transport for the whole integration estate, a platform speaking SFTP, FTP, FTPS, AS2, and WebDAV under the company’s own domains.

Counterparty intake became provisioning instead of engineering. Each trading partner and acquired-division counterparty gets an individual SFTP or FTP account, rooted into its own subfolder with subfolder permissions, so a partner reaches its own files and nothing else. Password authentication is simply how the platform works, so the partners who could never manage SSH keys connect without anyone assembling anything.

Machine-to-machine traffic runs over the same platform. IBM iSeries, Windows, and Linux hosts connect directly over SFTP, while scheduled scripts automate cross-border collection between a Canadian operation and downstream systems in the US data center.

The EDI and ERP workloads sit on top of that transport. Trading-partner EDI files land on Files.com and feed the company’s BizTalk environment from there. Tibco, the integration platform that bridges the ERPs picked up through acquisitions, moves all of its data over Files.com SFTP, because those ERPs share no other path to one another.

When the American Paper & Twine division needed administration kept completely separate from the existing environment, the team used Files.com Child Sites to stand up a second, fully independent site with its own domain and its own administrators, under the same parent account.

The team migrated load-bearing internal, EDI, ERP, and trading-partner workloads in stages, with the heaviest wave running through 2023 and reaching its tail end by late 2024.

From a 20-Account Request to the Company’s File Backbone

With the migration through, Files.com replaced a server the team had to keep alive with a transport layer that absorbs the company’s growth on its own.

• The self-hosted infrastructure is retired. There is no FTP server and no EC2 SFTP instance to patch, secure, or manage, and password-authenticated SFTP stopped being a project.
• Fewer than 30 accounts at signing grew to roughly 190 by mid-2025, with about six new accounts a month accommodated without adding transfer infrastructure as acquisitions and facility openings continued to add counterparties.
• Six to eight distinct production workloads run on the platform: trading-partner exchange, the BizTalk EDI environment, Tibco’s ERP bridging, and cross-border scheduled collection among them. At the 95th percentile, the platform handled roughly 170,000 API calls per day.
• Off-pattern work lands on the same platform without capacity planning. On one high-priority project, over 4 TB of sensitive material was pushed to SFTP and pulled back down by the legal teams across a single weekend.

The Next Acquisition Lands on a Platform, Not a Project

Today, when a deal closes, the new division’s ERP and its trading partners connect to a transport that already exists. Each counterparty used to mean another account hand-built on a server the infrastructure team had to keep patched and running. Now it means provisioning an account on Files.com, rooted into its own folder, and where an acquired brand needs full separation, standing up its own site under the same parent. The team that once maintained the company’s transfer infrastructure now administers it.

A transfer server sized for the 20 users in front of you is the wrong foundation for a company that buys another business every few weeks.