Labatt Food Service Moved Partner File Exchange to Files.com Without Forcing a Single Partner to Upgrade

Labatt Food Service is an independent broadline foodservice distributor headquartered in Texas. The company supplies school districts, restaurant groups, and institutional customers across the Southwest, along with national accounts. It also writes software in-house, including the integration application at the center of its partner file exchange.

That habit matters here, because the connection between Labatt and its customers is software talking to software. Orders and invoices move as files, over FTP, FTPS, and SFTP, between Labatt's systems and whatever each customer runs. A distributor does not get to choose what its customers run. Labatt had no authority over the clients its counterparties used.

The Order Pipeline Depended on Automated File Exchange

For Labatt, file exchange is not a back-office convenience. It is the order pipeline. A district's ordering system drops a file, Labatt's software collects it and routes it into processing, and the traffic is almost entirely unattended: on Labatt's file transfer platform, system accounts far outnumber human ones. A file that does not move is an order that does not get picked and an invoice that does not get paid.

Moving that exchange to Files.com therefore meant preserving the behavior on which Labatt's customers and internal applications already depended.

More Than a Hundred Partners Labatt Could Not Upgrade

Moving was the hard part. More than a hundred of Labatt's counterparties connected with FTP clients old enough to use encryption ciphers that modern servers had retired. A distributor was in no position to make hundreds of customers upgrade their software so that it could change its own infrastructure.

The exchange also ran in both directions. Some partners pushed files to Labatt. For others, Labatt's own programs connected out to the partner's server, using credentials the partner issued, and pulled the files back. Much of the exchange was scripted, and Labatt's integration depended on folder structures and connection behavior staying exactly as expected. Any change to the transfer layer risked breaking partners one at a time, each with its own client, protocol, cipher, and schedule.

So the new platform had to meet the partner base where it was. It had to speak FTP, FTPS, and SFTP in one place. It had to keep accepting the ciphers the oldest clients used. It had to present every partner a folder whose shape never drifted, because automation read that shape. Labatt moved the exchange onto Files.com to be that hub.

A Login and a Locked Folder for Every Trading Partner

On Files.com, every trading partner has its own login and its own folder. Partners connect the way they always have: Files.com serves all three protocols from one site, and Labatt kept legacy cipher support enabled on the platform, so the hundred-plus partners on older FTP clients kept connecting with the clients and ciphers they already had. None of them moved on Labatt's schedule, because none of them had to move at all.

On the collection side, the integration application Labatt wrote in-house connects as each partner's user in turn, every five minutes. It checks the partner's folder, pulls whatever has landed, disconnects, and hands the files off for processing. Then it moves to the next user.

That automation only works if the directory structure it reads never changes, so Labatt used Files.com's folder-level permissions to lock it. Partners have write access without the ability to create subfolders: they can drop order and invoice files into their folder, and nothing about its shape can drift.

One Hub for a Diverse Partner Base

With the hub in production, Labatt brought diverse partner connections into one operating pattern without requiring the partners themselves to standardize.

• One Files.com site carries automated order and invoice exchange across a large base of trading-partner logins, from individual school districts to national retail accounts, with multiple terabytes of data on the platform.
• No partner was forced to upgrade. The old clients, old ciphers, and existing connections on the other end kept working because Files.com carried the compatibility burden that had complicated infrastructure changes.
• Adding a partner became a repeatable unit of work: Labatt IT creates a login and a locked folder, and the new partner joins the same five-minute collection cycle as everyone else. The partner base has grown steadily year over year on that pattern.

The Compatibility Burden Belongs to Files.com Now

Today, the connection between Labatt and the customers it feeds runs through Files.com. Labatt can add a partner, adjust a permission, or grow the estate without changing the clients and protocols its counterparties already use.

Consolidating the trading-partner base never required standardizing it. Labatt did not make its school districts and restaurant groups converge on one client or one protocol. It put Files.com in the middle and let the platform absorb the differences, one login and one locked folder at a time.