A Regional Motor Club Moved Its Partner File Exchange From Progress WS_FTP to Files.com Without a Big-Bang Cutover

A regional motor club serves members across a multi-state territory in the US. Roadside assistance is the visible part. Behind it sits an operation that also runs an insurance agency, a mortgage and lending business, a full-service travel agency, and driver training.

Every one of those lines of business trades files with outside parties. Mortgage and loan applications move to banks and credit unions. Payroll and HR feeds flow from the company's Workday system to banks and downstream processors. Insurance data, membership payments and refunds, and marketing lists move in and out daily, and nearly all of it carries members' personal data. For roughly eighteen years, nearly all of that exchange passed through a single on-premises Progress WS_FTP server. Any replacement had to protect that data as a property of the platform while looking, to every counterparty and automated process, almost exactly like the server it replaced.

A Security Model the Platform Enforces

The server carried hundreds of accounts: external vendors, internal staff, and the system accounts behind automated jobs. One IT network security engineer administered it and led the replacement. The motor club set the bar for whatever came next as a list of properties the platform itself would enforce.

Every file would be encrypted at rest the moment it landed, whether or not the sender encrypted it first. Employee access would come from the corporate directory, and every vendor would log in as itself, so each action traced to one party. Sensitive files would be deleted on the schedule the retention policy set. And an administrator would be able to look at any user and see exactly what they could reach.

Too Load-Bearing to Rip Out

Everything in the business pointed at that one server. Scheduled jobs pushed payroll files to banks. Scripts watched for new-hire and termination lists and used them to update Active Directory, so a missed file meant a new employee without accounts. Dozens of external organizations, from national banks to small credit unions and marketing platforms, connected with their own scripts, their own clients, and their own change-control windows. And because credentials could not be exported from the old server, every account on it would have to be rebuilt on whatever came next. A big-bang cutover would have bet dozens of production jobs, at dozens of companies, on one weekend going perfectly.

The motor club selected Files.com to meet both sides of the specification: the enforced security model, and a cutover that preserved the workflows already built around the old server.

A Cutover Built Around a Hostname Change

The work started with a catalog, not a migration. The engineer sat down with each process owner and documented every connection on the old server: who was on the other end, which direction files flowed, what they contained, how often they moved, how the connection authenticated, and which folders it touched. The catalog identified the user and service accounts that had to be rebuilt, and it became the migration plan.

The design principle was that nothing visible would change. Usernames, filenames, directory structures, and folder permissions were carried onto Files.com exactly as they were, so an existing client or scheduled job needed two updates: the hostname and a fresh credential. The old server stayed live throughout, and partners cut over in batches on their own schedules, updating allow-lists and host keys ahead of their move. The first external partner was live-tested end to end before the batches followed.

Because every account had to be rebuilt anyway, the motor club rebuilt them to the new model. Internal staff came in through Microsoft Entra ID single sign-on with SCIM provisioning, so the directory now creates and removes their file access and nobody administers employee accounts by hand. External organizations were onboarded as Files.com Partners, each in its own walled-off folder and invisible to every other partner. Vendors authenticate with their own SSH keys; a password with MFA exists only where a vendor genuinely needs the web interface.

Underneath, the platform enforces the rest of the specification. Every file is encrypted at rest the moment it lands, whether or not the sender encrypted it first. A retention policy deletes files automatically on schedule. Authentication and file activity stream from Files.com into the security team's Rapid7 SIEM, and the whole estate runs behind the club's own domain with certificates that renew themselves.

What the Platform Now Enforces

With the cutover complete and the WS_FTP server retired, the motor club runs its partner exchange on a security model the platform enforces.

• External vendor accounts authenticate with their own SSH keys inside their own partner spaces, so every action traces to one party.
• Sensitive files are encrypted at rest by default, whether or not a sender encrypted them before upload.
• Retention happens on schedule because the platform enforces it, so the deletion policy applies to every file automatically.
• An administrator can look at any user and see what they can reach, and the platform's own user records carry each account's purpose.
• Security logs stream into the Rapid7 SIEM on their own, with nothing retrieved from a server by hand.

The pattern also compounds. The next vendor the club onboards is a partner space, a folder, and an SSH key: the same construct every time.

Retired Without a Big Bang

Today the file exchange of a multi-line membership and financial business runs through Files.com, behind the club's own domain, and the server it replaced is off. The counterparties barely noticed. Their scripts run against a new hostname with a new credential, and everything else about their process is what it always was. Sensitive files pass through the platform in transit, encrypted while they are there, expired automatically, every touch logged into the security team's own SIEM. The engineer answers an access question by looking at the user.

The lesson in the motor club's migration is that age and entanglement are not reasons to keep a legacy file server. A system that spent eighteen years accreting dependencies came out from under them in batches: preserve every filename, path, and permission, run old and new in parallel, and the only thing a counterparty ever has to change is a hostname and a credential.