Eat'n Park Moved 75 Vendor Feeds to Files.com Without Rewriting Its Visual Basic Applications

Eat'n Park Hospitality Group has been family-owned since it opened a single car-hop restaurant in Pittsburgh in 1949. Today the group serves more than 50 million guests a year: full-service Eat'n Park restaurants across Pennsylvania, Ohio, and West Virginia; Parkhurst Dining, its contract dining arm serving private colleges and corporate campuses across a dozen states; and an online store that ships its signature Smiley Cookies to every state in the country. Roughly 9,000 employees keep it all running.

An operation like that runs on vendor data. Food ordering, product, sales, and payroll information moves between Eat'n Park and roughly 75 outside vendors, and all of it feeds the company's internal databases. For fifteen years, every one of those feeds arrived through a single on-premises SFTP server.

Fifteen Years of Accumulation on One Server

The server had grown the way long-lived servers do. User accounts had been created ad hoc for a decade and a half, one vendor at a time, until nobody could say cleanly who still needed access to what. Its directory tree carried scores of folders and files that no longer served any purpose. And because Eat'n Park operated the endpoint itself, every connection problem landed on its own infrastructure team, including vendors connecting with dated ciphers and outdated security protocols.

That work fell on a two-person infrastructure team under one director, who carried the server, its accounts, and its security configuration alongside everything else they ran. The server had become the thing nobody wanted to touch and everything depended on.

By then, Eat'n Park had also begun an enterprise-wide overhaul of its technology stack, moving off on-premises infrastructure. The SFTP server, the sole collection point for 75 vendor feeds, was one of the anchors holding it there.

Why the Server Couldn't Simply Be Swapped Out

The server was not standalone. Roughly 75 external vendors authenticated directly against it, and they could not all be moved on one schedule. Custom Microsoft Visual Basic applications drove file transfers into it through a third-party .NET FTPS library. And internal systems read what landed there: a purchasing loader scanned the vendor folders for new files and loaded them into a SQL Server-backed purchasing system.

Replacing the server the obvious way meant rewriting that application layer — the kind of project that keeps an aging server alive for another five years.

So the replacement had a specification. It had to speak SFTP, FTPS, and plain FTP, the protocols the vendors already used, so 75 outside companies never had to change how they connect. It had to be reachable from the existing Visual Basic applications without rewriting them. It had to tie vendor provisioning to the company's Azure AD directory instead of another round of hand-built accounts. It had to run under Eat'n Park's own name, and it had to hold data in the United States.

Eat'n Park selected Files.com to be that vendor-facing platform.

A Mount, a Sync, and a Staged Cutover

The team treated the migration as a reset, not a relocation. Before moving anything, they cleared the unneeded directories out of the legacy server and consolidated fifteen years of ad hoc user management into a structure worth carrying forward.

Using the Files.com Agent, the team first exposed the legacy storage through Files.com as a Remote Server Mount. Once that proved out, a sync copied the data onto Files.com for verification before the old mount was disconnected, avoiding a single all-at-once migration.

The vendors moved in waves. A single vendor ran in parallel against both systems first. Then 40 vendors went live in the initial rollout, provisioned through Azure AD, with a bulk user import mapping each vendor to its designated folders. Each vendor authenticates with its own login, lands in its own folders, and connects over the same protocols it always used.

With production stable, the team deployed a custom domain, so vendor-facing transfers run under an Eat'n Park-branded hostname with dedicated IPs. Files.com provisions and renews the certificate behind it automatically.

Repointing Visual Basic at the Cloud

The applications that fed the old server never went away. Instead of rewriting them, the team pulled the Files.com .NET SDK from NuGet and swapped it in for the third-party FTPS library the Visual Basic applications had used. The applications kept their logic and their jobs; only the transfer layer underneath them changed. Code that had pushed files at an on-premises box for fifteen years now pushes them at Files.com.

The internal purchasing loader kept its job too. It still scans the vendor folders for new files and loads them into the purchasing system; the folders it scans simply live on Files.com now.

What Runs Through Files.com Now

With the cutover complete, the on-premises server and its mount were retired, and Eat'n Park replaced a box it patched and administered by hand with a platform it configures. Roughly 75 vendors now exchange food ordering, product, sales, and payroll data through its branded endpoint. Azure AD provisions their access and permissions, while the legacy Visual Basic applications and purchasing loader continue their existing jobs against Files.com.

The platform has also absorbed work the old server never did. Daily jobs from the company's SQL Server push financial reports over SFTP into Files.com, where Automations move each report on to its destination folders; typical runs process in under 30 seconds by the team's own measurement. UKG, the company's payroll partner, delivers GPG-encrypted roster files into a dedicated path, and the Files.com GPG Key Manager decrypts each file automatically on arrival. Neither workflow existed on the old server. Both were added as configuration, not as new processes to stand up and maintain on a box.

From a Server They Maintained to a Platform They Configure

For fifteen years, Eat'n Park's vendor exchange meant operating infrastructure: a server to patch, accounts to build by hand, an endpoint whose security configuration was the team's responsibility every time a vendor connected badly. Today the same two-person team runs a larger exchange than the old server ever carried, without operating a vendor-facing server at all. The team no longer has to patch that server, build vendor accounts one by one, renew its certificate, or keep its protocols, ciphers, and other endpoint security current. A new vendor is a login provisioned through Azure AD and a folder. A new workflow, like an encrypted payroll feed or a nightly report pipeline, is a folder setting or an Automation on Files.com.

And the company got there without the project that keeps most aging servers in place. The Visual Basic applications were repointed, not rewritten. The vendors moved in waves, not on one cutover weekend. The server that had anchored Eat'n Park's estate to on-premises infrastructure retired without taking anything down with it.