A Restaurant Operator Moved Hundreds of Restaurants to Files.com SFTP Without Rewriting a Script

A US multi-brand restaurant operator runs hundreds of restaurant locations.

Every restaurant has an office computer, and every one of those computers is an endpoint in a fleet spread across multiple states. Software installers, local configuration, and configs for in-store networking equipment have to flow out to every store, and each store’s sales data has to flow back. The pipeline that carries that traffic is not a convenience. It is infrastructure the whole fleet runs on.

One Self-Hosted Server Under Every Restaurant

For years, that pipeline was a self-hosted FTP server. A scheduled script on the office computer in each restaurant pulled installers, configuration files, and networking-equipment configs down from the server, and pushed the store’s sales data back up.

The pattern was sound, and the operator wanted to keep it. What it wanted to change was underneath: every executable sent to a store and every sales file coming back had to move over encrypted SFTP, at every location, on every run.

The server itself was the other half of the work. It was a single, self-managed machine, and everything at hundreds of restaurants depended on it. The operator’s IT team owned its uptime and its patching, on top of the restaurants the team actually exists to support.

Hundreds of Scripts, and No Room for a Big Bang

The pipeline was wired into every store. The deployment script at each location was pointed at the old server. Replacing the server meant changing what every one of those scripts pointed at without breaking software distribution or sales collection at restaurants serving customers every day. A synchronized cutover across a live fleet was not a realistic option.

So the replacement had a specific shape. It had to support the scripts’ existing automated pull-and-push pattern over encrypted transport, so they could be repointed rather than rewritten. It had to absorb machine-driven traffic at fleet scale, from hundreds of endpoints running on schedules with no person watching. And it had to take the server itself off the operator’s hands entirely.

That fit led the operator to select Files.com as the managed SFTP endpoint for the restaurant fleet.

Repointing the Scripts, Store by Store

The operator’s own systems engineer converted the deployment scripts in place over roughly two months. Each script changed its destination from the legacy FTP server to Files.com SFTP. The logic that decides what each store pulls and what it pushes stayed exactly as it was. Dedicated Files.com service accounts carry the fleet’s automated traffic, and the operator administers those accounts itself.

When the fleet’s scripts arrived, daily transaction volume on the account rose sharply. Files.com absorbed that jump with nothing for the operator to size, provision, or re-architect.

Encrypted to Every Store, With No Server to Run

With the fleet on Files.com, the operator replaced a self-run server with a managed endpoint and encrypted transfer to every restaurant in the workload.

• Every store endpoint pulls installers and configuration, and pushes its sales data, over encrypted SFTP.
• The legacy FTP server is retired. Nobody at the operator patches, monitors, or restores the machine that every restaurant used to depend on.
• Files.com now handles more than a million daily transactions from the restaurant workload.
• The migration was completed in-house by repointing scripts rather than rebuilding the workflow.

Distribution Without a Server to Run

For an operator running the same automation across hundreds of restaurants, that is the difference between adding load to a box it has to operate and adding another script to a platform built for the workload. The scripts were never the problem. The operator kept them, changed the one thing about them that mattered, and retired the server they pointed at.