Yamaha Motor Manufacturing Replaced Progress WS_FTP With Files.com Without Migrating a File

Yamaha Motor Manufacturing Corporation of America (YMMC) builds golf cars, ATVs, side-by-sides, electric carts, and personal watercraft at its plant in Newnan, Georgia, for the American market. The plant has operated since 1986. Its production depends on a supply chain: parts and motors arrive from the parent company in Japan, a deep base of vendors, suppliers, and temp agencies feeds the plant, and file feeds flow out to Yamaha's U.S. sales arm. Every one of those relationships exchanges files, and for years all of that exchange passed through a single point: an SFTP server YMMC ran itself.

One Server in the DMZ Carried the Whole Supply Chain

That server was Progress WS_FTP running on a Windows Server 2016 host in the DMZ. As the plant's one external exchange point, it carried transfers with vendors, suppliers, temp agencies, and the feeds to Yamaha's U.S. sales organization.

Two things were wrong with it, and YMMC's own security organization named both. The host itself was standing exposure: an internet-facing Windows server that internal security and compliance policy had judged insufficient for external file exchange, and that the team wanted out of the DMZ entirely. 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 server lasted as long as it did because of what depended on it. 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. YMMC 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. A 7-day 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 Windows 2016 host was slated for decommissioning.

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

With the Files.com model in production, YMMC replaced a hand-run exchange on a server its own security policy had flagged with a governed, automated pattern it repeats for every partner. The results land on two axes: risk removed and effort removed.

• The DMZ attack surface is gone. The Windows Server 2016 host that internal policy judged insufficient is out of the external file-exchange path entirely, not patched 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 YMMC connects a new counterparty, nobody touches a server, because there is no server to touch.

YMMC changed the operating model behind the file exchange its manufacturing supply chain depends on while removing the infrastructure security wanted gone. New counterparties now enter a governed pattern rather than adding another hand-run connection.