A Foodservice Packaging Distributor Replaces Self-Hosted SFTP on AWS EC2 With Files.com as Accounts Multiply

A North American foodservice packaging distributor supplies packaging, janitorial and cleaning supplies, and industrial packaging across the United States and Canada, serving customers in segments that run from restaurants and grocery to healthcare.

That footprint was built one deal at a time. 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 an FTP server, and the infrastructure team moved on to a self-hosted SFTP instance on an AWS EC2 machine, which brought an operational problem of its own. 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 the 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. The distributor selected Files.com to be that endpoint.

One Files.com Platform Across Systems and Counterparties

The initial request was modest: a small set of 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. Hosts across the company’s different server platforms 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 one acquired 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 Modest 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.
• A small set of accounts at signing has grown many times over, with new accounts every month accommodated without adding transfer infrastructure as acquisitions and facility openings continued to add counterparties.
• Several 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.
• Off-pattern work lands on the same platform without capacity planning. On one high-priority project, terabytes of material were pushed to SFTP and pulled back down by the receiving team 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 users in front of you is the wrong foundation for a company that buys another business every few weeks.