The Odom Corporation Found Four Live FTP Partners, Then Retired Microsoft Windows Server 2003 and WinSCP With Files.com

The Odom Corporation has been distributing beverages since 1934. Today it is one of the largest privately held companies in the Pacific Northwest: a Coca-Cola bottler and wholesale distributor of beer, wine, spirits, and soft drinks across the Pacific Northwest, Alaska, and Hawaii, with more than 2,300 employees and roughly 20 distribution centers. Its footprint includes some of the hardest delivery terrain in the country. In Alaska, where only about a fifth of the state is reachable by road, product also moves by barge and plane.

A distribution business of that shape runs on files. Orders, routing data, and invoices move between Odom and its supplier and distribution partners every day, and some of those files decide whether trucks leave a warehouse the next morning. For two decades, that exchange ran through an on-premises FTP server. Then Odom decided that the data center it lived in was going away.

The 50 to 100 partner connections the server was assumed to carry resolved to roughly four that were genuinely active, and more than 95 percent of the content on the legacy server was confirmed dormant. None of it moved.

A Late File Meant a Lost Day of Deliveries

The costliest fifteen minutes in Odom's file estate arrived every evening. A daily routing exchange with one of its largest distribution partners ran between 5 and 6 PM Pacific, and it had almost no slack.

“Within 15 minutes, if the file hasn't transferred, we have truck delays.”

If that file arrived late, trucks did not roll the next day, and Odom lost a full day of deliveries across Central Washington.

The system carrying that transfer was a Microsoft Windows Server 2003 machine driven by WinSCP, sitting inside Odom's data center. Partners dropped files onto it and picked files up from it, several of them over VPN tunnels that ran straight into Odom's internal network. External counterparties held standing paths inside the company's perimeter, and after twenty years of accumulation, nobody could say with confidence what the server still served. Live workflows kept surfacing by accident, discovered only when someone went looking for something else.

The Data Center Had a Closing Date

The server's condition had been survivable for years. What ended it was structural: Odom was in the middle of a deliberate, multi-year move off its own infrastructure.

The data center was scheduled to close by May 2026, and the FTP server had nowhere left to live.

The replacement had a specific job. It had to carry partner exchange over SFTP with no hardware behind it that Odom owned. It had to keep plain FTP alive for one legacy partner whose AS/400 could speak nothing else. It had to ask partners to change almost nothing, because the largest counterparty's approval cycles were long enough that one small change had once required dozens of people on their side of a call. And it had to make the time-critical evening feed observable, with a record of every transfer instead of a black box. All of it had to happen on Saturday-only maintenance windows, before the shutdown date.

Odom selected Files.com to carry that partner exchange.

Discovery First, Then One Partner at a Time

Odom ran the migration as a blank-slate build rather than a lift-and-shift. Instead of copying twenty years of accumulated folders onto a new platform, the team moved only the live workflows discovery had surfaced.

The four live partners migrated one at a time. The slowest-moving counterparty, the one whose feed carried the fifteen-minute delivery stake, was engaged earliest precisely because its approvals took longest, and cut over last. The change on the partner's side was deliberately held to a new endpoint and a new set of credentials, validated in a test environment before the production cutover.

On Files.com, each partner now connects over SFTP with its own credentials to an endpoint outside Odom's network. The VPN tunnels are gone. The legacy AS/400 partner kept plain FTP, served from the same platform, so the one counterparty that could not modernize did not have to. Odom's own staff reach the site through Entra ID single sign-on, with conditional access and MFA.

Odom's team also owned the build itself. The business systems team constructed its own Files.com Automations to route arriving files, and relies on the audit log and event-triggered email notifications to watch the feeds that matter.

The Server Retired With the Data Center

With the last partner cut over, Odom had replaced a two-decade-old exchange hub inside its own network with a cloud platform its partners reach from outside it.

• Files.com is now Odom's single external SFTP platform for partner exchange, and the Microsoft Windows Server 2003 machine retired alongside the data center, on the timeline the shutdown demanded.
• No partner holds a tunnel into Odom's internal network anymore. Each connects with its own scoped credentials, and every transfer lands in the audit log.
• The daily routing feed that decides whether trucks roll runs through a monitored platform that logs every run and fires notifications on file events, instead of through a server nobody fully understood.
• Only the live connections moved. The dormant 95 percent of the legacy server's content retired with the hardware rather than being carried forward.

No Transfer Infrastructure Left to Own

Today, the file exchange that gates Odom's deliveries depends on no hardware Odom runs. There is no server to patch, no operating system quietly aging past its era, and no data center obligation attached to moving a partner file, which is where the company's five-year shift to SaaS was pointed all along.

The pattern also compounds. Connecting the next partner means issuing credentials on Files.com, not opening a path through the firewall or standing anything up in a rack.