A Food Processing Equipment Maker Moved Legacy FTP Workflows to Files.com—Then Extended the Pattern Across a Merger

A global food processing equipment manufacturer designs, builds, and services processing equipment and technology for the food and beverage industry. It was formed by the recent combination of two equipment makers, each a large company in its own right.

A manufacturer at that scale is also a very large back office. Its ERP estate exchanges files with outside systems constantly: purchase orders and CAD drawings going to vendor portals, invoices and payment files, payroll time data, travel and expense data, transportation and logistics data. Almost none of those flows stay inside the company. Each one crosses between the manufacturer's systems and a counterparty's, and each counterparty brings its own protocol, its own endpoint, and its own credentials.

File Exchange Built on Servers They Ran Themselves

That exchange ran on the company's own infrastructure. An internal file server and a legacy FTP server carried the vendor flows, moving files between the company's systems and vendors' SFTP servers in both directions. Every new vendor or application meant one more connection built and maintained against servers the team had to run themselves.

The burden showed up in two places. First, every integration was a build: custom plumbing against legacy infrastructure, done again for the next vendor. Second, environment separation was hardware. Keeping test data flows away from production meant standing up and operating separate servers, so every environment the team wanted to keep honest carried its own infrastructure burden. The company's file exchange had outgrown the model of running its own transfer servers, and the estate could not grow without the server footprint growing with it.

A Replacement That Could Not Be a Cutover

None of this could be swapped out in one move. The flows touched dozens of external counterparties and systems, from the Infor Nexus portal to Syncron, Concur, and Azure storage, plus on-premise systems in multiple countries. Each connection had its own protocol and credentials. Any replacement had to take that work over one integration at a time, without asking dozens of counterparties to change anything on the same day.

The requirements followed from the estate itself. The replacement had to serve SFTP to vendors pushing files in, and act as an SFTP and FTPS client delivering to vendors' own servers. It had to reach systems sitting behind corporate firewalls in other countries. It had to encrypt and decrypt with PGP using the company's own keys. And it had to keep development and test transfer paths cleanly apart from production without a dedicated server for each.

The company selected Files.com to be that hub and began moving the legacy FTP server's workloads onto it, integration by integration. That repeatable pattern later gave the combined company a way to extend existing vendor connections across both legacy organizations.

A Standard Folder Pattern for Every Connection

On Files.com, a vendor connection stopped being a build and became a pattern. Each vendor or application gets a root-level folder with a standard subfolder structure. Folder-scoped permissions mean a vendor connecting over SSH-key SFTP can deposit files into its own folder and reach nothing else, and country-based access controls with per-user exceptions govern where connections are allowed to come from.

Behind those folders, Files.com does the moving. Remote server mounts and syncs connect vendor SFTP servers and Azure Blob storage, running on schedules or firing when an inbound webhook arrives. Files.com Automations copy, move, archive, and rename files with wildcards and timestamps so downstream systems receive them in the form they expect. GPG encryption and decryption run inside the flows with keys the company manages itself, while an automation keeps a backup of every inbound file so failed files can be examined and reprocessed instead of requested again from the vendor.

For systems the cloud cannot reach directly, Files.com Agents run on Windows and Linux hosts inside the company's own network, including a Windows server in Europe mounted to a Windchill engineering system. The Agent connects outbound only, so joining an internal system to the hub opens no inbound firewall port. Even an ERP system with no file transfer method of its own joined the hub by emailing files machine-to-machine into the platform, where the same automations took over.

Development, Test, and Production as Sites, Not Servers

The company added two staging sites alongside its production site: one serving its development systems and one serving its test systems. All three run in parallel. Each is a fully separate Files.com site with its own users and transfer paths, so development and test traffic never brushes production data. Automations are built and validated in the test site before they deploy to production.

On premise, that separation was a server per environment. On Files.com, it is configuration on one platform.

The Integration Estate Grew Without New Infrastructure

With the hub in production, the manufacturer replaced one-off transfer plumbing on servers it ran itself with a repeatable integration pattern on a platform it does not have to run at all.

The platform now carries dozens of remote server connections plus on-premise Agents across production, test, and development, and the number has grown steadily. None of that growth required standing up another transfer server.

The Pattern That Absorbed a Merger

When the two legacy companies combined, each roughly doubled in size and two IT organizations merged into one. Consolidating duplicated applications across the two legacy entities is a long programme. On the file exchange side, the pattern simply extended: where both legacy companies trade files with the same vendor, the existing Files.com connection now serves both sides rather than being built twice.

That is the position the incremental migration bought. The legacy internal FTP server remains in the estate, but the manufacturer moved workloads from it to Files.com one integration at a time. Each integration that moved stopped being something built and maintained against a server and became a folder, a credential, and a set of automations on Files.com. Today, when a new counterparty needs to exchange files with the manufacturer, nobody builds them a server. They get the pattern.