RAC WA Replaced Its Legacy SFTP Server on Files.com Without Asking Partners to Change

The Royal Automobile Club of Western Australia began as a roadside assistance body, and it stopped being just a motoring club a long time ago. The member-owned mutual now spans motoring services, insurance, travel, and finance-related services. Because the business is regulated under APRA and the Australian Privacy Act, confidential member information runs through nearly everything RAC does, and those obligations follow the information wherever it moves.

A business that broad trades files with the outside world constantly. External parties uploaded files to RAC and collected files from it, feeding everything from marketing workflows to backend systems. And for years, all of that traffic landed in one place: a very old on-premises SFTP server.

Retiring it would require RAC to move those partner workflows incrementally while the old server kept running—and preserve SFTP for outside parties that did not want to change.

One Aging Server, Bespoke Partner Workflows

Everything attached to the server was handmade. A typical exchange worked like this: a third party dropped files onto the SFTP server for RAC's marketing department, and a scheduled job ran a couple of times a day, using a PowerShell script to move the files onward to a SharePoint destination. Other accounts were more involved, with incoming and outgoing subfolders, drop-offs that sometimes arrived as nested folder trees, and a separate PowerShell script for each direction, all orchestrated by the JAMS scheduler.

The cost was in what that arrangement forced. A file a partner delivered in the morning could sit untouched until the next scheduled run before anyone downstream saw it. Every partner exchange was its own bespoke machinery, built and maintained by Group IT, and every new one added to the pile. And confidential member information was moving across aging infrastructure at the very moment RAC's security function was looking for a governed way to transfer it.

The hardware decision had already been made: the server was going. The open question was where its partner relationships would land.

Partners RAC Could Not Ask to Change

The accounts on that server did not belong to RAC alone. On the other end of each one sat an external party with its own systems, its own scripts, and no obligation to change any of them. One business unit made the point explicitly: it chose to keep SFTP as its exchange method because the third party was happy with it and did not want to change. Whatever replaced the server had to preserve the SFTP method the partner already used.

The variety of the workflows ruled out a single cutover. One account was a simple one-way drop-off. Another moved files in both directions through incoming and outgoing folders, sometimes as nested folder structures. Migrating everything in one synchronized weekend was not realistic. The accounts had to move one at a time, with the old server running until the last of them left.

RAC's cyber security function set the bar for anything that would carry confidential member information: authentication through RAC's Azure AD, accounts provisioned and revoked from the directory rather than by hand, two-factor authentication and IP restrictions on access, and SFTP support so internal processes could interact with it.

The specification wrote itself. RAC needed a cloud SFTP endpoint that partners could continue to use through the same protocol, with identity drawn from Azure AD, movement triggered by a file's arrival instead of a scheduled script, and the ability to absorb accounts incrementally while the legacy server kept running. RAC selected Files.com to be that endpoint.

Identity First, Then One Account at a Time

Files.com became the server behind the protocol. To the outside, the same SFTP exchange partners had always used. On the inside, identity from RAC's directory and automation in place of scripts.

The identity foundations went in before any workflow moved. RAC's cyber security team connected Files.com to Azure AD over SAML with SCIM provisioning, so internal users could sign in through single sign-on while their accounts were created and deactivated from the directory. Two-factor authentication and IP whitelisting added further controls.

Then the workflows moved, simplest first. The marketing drop-off account was recreated on Files.com with an SFTP home folder for the third party: the same protocol and drop-off pattern, with a different server behind it. RAC designed the workflow to move files onward when they landed instead of waiting for the twice-daily scripted run. The more complex bidirectional account, nested folders and all, queued behind it, and the server crossed over account by account while the legacy system kept serving whatever had not yet moved.

Files.com Automations made the per-partner setup repeatable rather than bespoke. When RAC creates a user, that user's folders are created automatically with full permissions, and share permissions apply by rule. Standing up the next external party is a user record, not another pair of PowerShell scripts.

The Legacy Server Became Decommissionable

With its SFTP processes running on Files.com, RAC replaced a scripted, batch-driven exchange on hardware already marked for retirement with a governed cloud endpoint. Moving those processes made the aging server decommissionable.

Partners kept their method. They could continue exchanging files over SFTP while the server behind the protocol changed.

The operating model changed inside RAC as well. The marketing workflow was designed to move files onward when they arrived rather than leaving them for the next scheduled run. And onboarding a partner stopped being a scripting project: creating the user now creates the folders and applies the permissions.

A Partner Exchange That No Longer Depends on One Machine

Today, external parties still use SFTP to send files to and collect files from RAC, but everything behind that exchange has changed. The account a partner connects to comes from a rule rather than a script. The programmer who once maintained a separate PowerShell script for each direction of each exchange creates a user instead. Access for RAC's own people follows the Azure AD directory, granted and revoked without anyone touching a file server.

That is the portable lesson in RAC's migration: a legacy SFTP estate does not need a cutover weekend, and it does not need partner cooperation, to retire. RAC moved its workflows to Files.com one account at a time, with the old server running alongside until the remaining work had moved.