JBT Marel Moved Legacy FTP Workflows to Files.com—Then Extended the Pattern Across a Merger
JBT Marel designs, builds, and services processing equipment and technology for the food and beverage industry. Formed in January 2025 by the combination of JBT and Marel, the company runs at $3.8 billion in revenue with more than 11,000 employees worldwide.
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 JBT Marel'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 JBT's own infrastructure. An internal file server and a legacy FTP server carried the vendor flows, moving files between JBT'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 JBT's own keys. And it had to keep development and test transfer paths cleanly apart from production without a dedicated server for each.
JBT 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 JBT Marel 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 JBT Marel's own network, including a Windows server in Sweden 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
In mid-2022, JBT added two staging sites alongside its production site: one serving its development systems and one serving its test systems. By September 2023, all three were running 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, JBT Marel 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.
By late 2025, the platform carried 36 remote server connections plus two on-premise Agents across production, test, and development, up from roughly two dozen connections in October 2023. None of that growth required standing up another transfer server.
The Pattern That Absorbed a Merger
In January 2025, JBT completed its combination with Marel, roughly doubling each legacy company and merging two IT organizations 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 JBT Marel 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 a $3.8 billion manufacturer, nobody builds them a server. They get the pattern.
Related Customer Stories
Manufacturing
Porsche Cars North America Built a Files.com Alternative to Email and FileZilla That Teams Adopted Without Promotion
To clear Porsche AG's hosting rules, the channel combined federated identity, Porsche branding, and Canadian data residency for workflows across the business.
Read story →
Manufacturing
Qualcomm Uses Files.com for Modem-Log Collection Across Three Simultaneous Carrier Assessments
A shared collection layer let contractor teams upload multi-gigabyte handset logs without VPN access while Qualcomm kept its analysis systems on-prem.
Read story →
Manufacturing
Acer America Retired Its Warranty Repair FTP Server With Files.com—Without Changing the Address
A weekend cutover moved the repair channel to Files.com while preserving the Acer endpoint and protocols its service providers already used.
Read story →