A Components Manufacturer Moves Partner FTP and SFTP to Files.com and Retires Its In-House Server

A North American components manufacturer supplies engineered parts to OEMs in the recreational vehicle, marine, and transportation markets, across a global, multi-site footprint.

A supplier positioned between that many OEMs and vendors exchanges files with outside companies as a routine part of production, and those companies connect the way industrial partners do: over FTP and SFTP. For roughly ten years, the system on the manufacturer's end of those connections was an FTP server the company ran itself. The manufacturer wanted to retire the server without interrupting those partner transfers, and to carry only active users onto its replacement.

A Server the Manufacturer Wanted Out of Running

Over a decade, more than 200 user accounts had accumulated on the server. Before anything moved, the company wanted every one of them reviewed, so that only accounts belonging to a live partner, a current vendor, or a current employee crossed to the replacement. The box itself needed hosting, patching, and uptime, work the IT organization wanted off its plate. And a related transfer server on the marketing side was already rated a high-priority migration.

The Endpoint Had to Outlive the Server

The server could not simply be switched off. OEM partners and vendors connected to the company's FTP and SFTP endpoints, and those are outside companies on their own schedules. Turning the server off meant breaking working exchanges with the companies the manufacturer supplies. Replacing it in kind meant standing up another server and signing up for another decade of the same hosting and patching. That was the work IT wanted out of, not more of.

The objective was never a better FTP server. The company wanted FTP as a service: the endpoints kept alive and maintained by someone else, with its own infrastructure out of the picture. The replacement had to speak FTP and SFTP so partners could keep connecting exactly as they always had. It had to take the server, the patching, and the uptime off the company's hands. It had to put access under corporate identity instead of a standalone account list. And it had to start with a clean account base rather than inherit one.

The manufacturer selected Files.com to be that service.

The Account Review Came Before the Cutover

The first move was not a migration. Before anything cut over, the company's IT team audited the 200-plus account base and carried only active users across, so only live users landed on the new platform. Inactive accounts ended with the server instead of being copied onto its replacement.

Files.com then took over the transfers themselves. Partners and vendors connect over the same FTP and SFTP they always used, and the company's own teams reach the same files over WebDAV and HTTPS, all against one managed platform instead of a box in the company's data center. Internal sign-in runs through Files.com's Okta single sign-on connector with two-factor authentication, so access follows the corporate identity the company already manages. Permissions are granted folder by folder through Files.com Groups, so each user and group reaches its own folders and nothing more. And when it is time to review who has access, the full user directory comes out as a CSV through the Files.com CLI.

Within months, Files.com was in production carrying partner traffic.

No Server to Run, and Only Live Users Moved

With Files.com in production, the manufacturer replaced infrastructure it operated with a service it consumes.

• The ten-year-old FTP server is retired, and so is the legacy transfer server on the marketing side. There is no transfer box anywhere in the company's infrastructure to host, patch, or keep up.
• Partner and vendor exchanges kept running through the change. The same FTP and SFTP connections now terminate on a maintained platform instead of an aging server.
• Only active accounts crossed at the cutover. Access is granted per folder through groups, staff sign in through Okta with two-factor authentication on top, and the user directory exports on demand when the company reviews who can reach what. An access review is now a CSV export from the CLI.
• A self-hosted server ages into the next decade's project. A service does not, because there is no box on the company's side left to age.

A Service the Manufacturer Uses, Not a Server It Runs

And the account review most companies in the manufacturer's position dread turned out not to be a separate project at all. It ran before the cutover, so inactive accounts ended with the server, and only the live business crossed to Files.com.