A Powersports Manufacturer Replaced Progress WS_FTP With Files.com Without Migrating a File

A powersports vehicle manufacturer builds recreational and utility vehicles at its US plant for the American market. Its production depends on a supply chain: parts and motors arrive from overseas, a deep base of vendors, suppliers, and temp agencies feeds the plant, and file feeds flow out to the group's US sales arm. Every one of those relationships exchanges files, and for years all of that exchange passed through a single point: an SFTP server the manufacturer ran itself.

One Server in the DMZ Carried the Whole Supply Chain

That server was Progress WS_FTP running on a host the manufacturer maintained in the DMZ. As the plant's one external exchange point, it carried transfers with vendors, suppliers, temp agencies, and the feeds to the group's US sales organization.

Two requirements drove the replacement. The manufacturer wanted external file exchange off a server it hosted itself and out of the DMZ entirely, onto a managed exchange point built for the job. And the workflow around it ran on people. Files were placed, retrieved, and cleaned up by hand at both ends of every transfer, so each exchange carried its own manual steps, and each new counterparty added more of the same work rather than repeating an established pattern.

The replacement had to work around what depended on the server. It was the single connection point for the entire counterparty base, and manufacturing operations ran through the flows it carried. Replacing it meant rebuilding every one of those connections on a new platform without interrupting them, and doing it in a way that did not simply recreate the manual workflow on newer infrastructure.

That defined what the replacement had to do: speak the SFTP the counterparties already used, take the server out of the DMZ rather than relocate it to another one, and turn per-partner setup from bespoke work into a repeatable pattern. The manufacturer selected Files.com to be that managed exchange point.

A Model Built on Two Partners, Rolled Out Counterparty by Counterparty

The team did not lift the old workflow onto new infrastructure. They defined the business needs for two representative partners, built the target structure around those examples, and then rolled the same pattern out per counterparty in successive onboarding rounds.

The pattern keeps every counterparty separate and every setup identical. Each partner receives an inbound folder, an outbound folder, and an archive, so a new vendor or temp agency is a repeat of a known structure rather than a design decision.

Files.com Automations took over the steps people used to perform. When a partner downloads a file from its outbound folder, an automation moves the file to archive. An expiration policy on the archive then removes it. Delivered files clean up after themselves, with nobody tracking what has been collected and nobody deleting anything by hand.

Machine traffic runs through dedicated service accounts, including bot users that automatically pick up files SAP drops, while employees sign in through the company's existing Cisco Duo single sign-on. Unused services were disabled, so the site exposes only what the exchange uses.

Go-Live Meant Creating Accounts, Not Moving Files

The cutover carried no data migration at all. Because the server was an exchange point rather than a store, going live on Files.com required creating user accounts and nothing else: zero files moved. All SFTP operations shifted to Files.com, and the self-hosted server was slated for decommissioning.

Out of the DMZ, and Out of People's Hands

With the Files.com model in production, the manufacturer replaced a hand-run exchange on a self-hosted server with a governed, automated pattern it repeats for every partner. The results land on two axes: infrastructure removed and effort removed.

• The self-hosted server is out of the DMZ and out of the external file-exchange path entirely, not relocated or fenced off.
• Per-transfer manual handling is gone. Files archive the moment a partner collects them and expire on schedule, with no one placing, retrieving, or cleaning up files by hand.
• The cutover itself carried no migration risk. Nothing had to be copied, verified, or synchronized; go-live was account creation.
• Onboarding the next vendor, supplier, or temp agency is a repeat of an established pattern: folders, credentials, and automations that already exist, rather than a bespoke setup that adds permanent manual load.

The last of those is the result that compounds. Since go-live, the platform's footprint has spread well past the original scope: site administrators drawn from IT, SAP programming, enterprise data and analytics, and network security now run it, and automations have been built for partner workflows, temp-agency user archival, and internal data synchronization.

File Exchange as a Pattern, Not a Server

Today, when the manufacturer connects a new counterparty, nobody touches a server, because there is no server to touch.

The manufacturer changed the operating model behind the file exchange its manufacturing supply chain depends on while removing a self-hosted server from its external perimeter. New counterparties now enter a governed pattern rather than adding another hand-run connection.