A Grocery Wholesaler Moved Retailer Order Intake to Files.com SFTP Without Touching 30 Years of Backend Code

A national grocery wholesaler supplies thousands of independent supermarkets from its wholesale divisions. It exists to give independent grocers the scale of a national chain.

Every one of those stores keeps its shelves stocked by ordering from the wholesaler's warehouses, and those orders arrive as files. Retailers run batch scripts that submit orders to the wholesaler and pull back confirmations, ads, and discounts. Thousands of independent businesses on ordinary internet connections, all sending files to one wholesaler: that is the fact the wholesaler's file transfer problem grew from.

Thousands of Retailers Sending Orders to One Legacy Server

The server receiving those orders was a legacy order server that had been in service for decades. The wholesaler wanted retailer order intake to arrive over encrypted SFTP, on a managed endpoint that authenticates every retailer by credential, without the retailers or the backend noticing the change.

Most of the wholesaler's thousands of retailers sit on dynamic, ISP-assigned IP addresses that change without warning, so that endpoint could not rely on IP allow-listing. It had to accept a connection from any address.

Every Path to Modernizing Priced Out as a Rewrite

Every path to modernizing the endpoint had been priced as a rewrite, and the diagnosis was simple: the constraint was not the server, it was everything bolted to the server.

Decades of automation pointed directly at that machine. COBOL-based processes read from it. The order-receipt processes that pull retailer orders into the wholesaler's internal systems ran against it. Hundreds of customized Cleo Harmony actions, fired by internal schedulers, moved files between it, mainframes, and other servers. The wholesaler estimated that retrofitting those processes to read from any other location would take upwards of 3,000 internal labor hours, while converting the retail backend itself would require more than 1,000 hours. Any fix had to avoid both.

The partner side was just as rigid. Thousands of retailers had the wholesaler's connection details baked into their own batch scripts, clients, and retry logic. Any solution that changed how they connect would break the retailer base one store at a time. The wholesaler had already attempted the obvious modernization once: a move to Azure SFTP over Data Lake storage was backed out after the design ran to 300 pages of documentation.

Two requirements drove the timing. The wholesaler wanted a managed, encrypted endpoint in front of the order server, and it needed to onboard retailer and vendor accounts at a pace that one-at-a-time local account creation could not sustain. So the fix had a strict shape before any product entered the picture. It had to put a managed SFTP endpoint in front of the order server. It had to leave every downstream job reading files from exactly the place it always had. It had to let a retailer keep their existing script, changing nothing but a connection string and a credential. And it had to provision accounts by the hundreds, not by hand.

The wholesaler selected Files.com to be that transfer edge.

Files.com in Front, the Legacy Order Server Behind the Agent

The design confined the modernization to the edge: Files.com became the retailer-facing endpoint, while the legacy order server stayed in place as a backend.

Retailers connected over SFTP to the wholesaler's own branded domain using the same clients and batch scripts they always had, with the same username-and-password authentication. For a retailer, the entire migration was a new hostname and a new credential.

Behind that endpoint, the Files.com Agent ran on servers inside the wholesaler's network. The Agent connected outbound to Files.com and reached the legacy server's file root over SMB, presenting its existing folders through Files.com access controls.

Files.com Remote Server Sync carried incoming order files through to the on-premises server within about a minute of arrival. The Cleo Harmony actions and batch jobs behind it picked up files from the same folders they always had, unchanged.

A Lifeblood System, Cut Over in Small Batches

The wholesaler was cutting over a system it could not afford to break, so it moved in verified steps. A cloned copy of the legacy order server runs as a permanent test bed, exercised by a script pushing and pulling files, and every new Agent version is validated there before a production window.

A single wholesale division went first. Stores cut over in deliberately small chunks through the holiday change moratorium. The rollout resumed after the holidays, and several hundred stores completed their cutovers while the wholesaler provisioned external retailer and vendor accounts by the hundreds for the continuing migration.

Encrypted Orders and Decades of Code Left in Place

Files.com put retailer order intake on governed SFTP without requiring the rewrites that had kept the old path in place.

• Retailer orders arrive encrypted over SFTP on the wholesaler's own domain. Each retailer kept their existing script; the cutover asked for a connection string and a credential, nothing more.
• The 3,000-hour process retrofit and the backend conversion never happened. Every Cleo Harmony action, batch job, and COBOL process reads files from the same place it always did.
• The wholesaler provisioned retailer and vendor accounts by the hundreds through CSV import instead of creating them one at a time on the server, and onboarding the next retailer is a row in a spreadsheet.
• The wholesaler's security team has a complete audit trail of the exchange: millions of SFTP action entries forwarded to Sumo Logic, recording every transfer.

Modernized at the Edge, Untouched at the Core

Today, an order from an independent grocer leaves the same batch script it always has. It travels encrypted to Files.com, and within about a minute it is sitting in the same folder on the same server where a process written decades ago expects to find it.

The wholesaler proved that a business-critical legacy server does not have to be rewritten before the exchange in front of it can be modernized. Files.com fronts the estate; the thirty years of order-processing automation behind it stayed exactly where it was, which is what made the project practical at all.