A Hospitality Group Moved Its Vendor Feeds to Files.com Without Rewriting Its Visual Basic Applications

A US hospitality group runs full-service restaurants and a contract dining business serving private colleges and corporate campuses, with thousands of employees keeping it all running.

An operation like that runs on vendor data. Food ordering, product, sales, and payroll information moves between the group and dozens of 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 accumulated for a decade and a half, one vendor at a time, and the team wanted them consolidated into a structure tied to the company directory before anything moved. Its directory tree carried scores of folders and files that no longer served any purpose. And because the group operated the endpoint itself, every vendor connection problem landed on its own infrastructure team.

That work fell on the infrastructure team, which carried the server, its accounts, and its configuration alongside everything else they ran. Everything depended on the server, and the team wanted to stop operating it.

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

Why the Server Couldn't Simply Be Swapped Out

The server was not standalone. The 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 FTP, the protocols the vendors already used, so the 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 the group's own name, and it had to hold data in the United States.

The group 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 accumulated user accounts 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 the first large wave of vendors went live, 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 a company-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 the group replaced a box it patched and administered by hand with a platform it configures. Dozens of 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 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, the group's vendor exchange meant operating infrastructure: a server to patch, accounts to build by hand, an endpoint whose configuration was the team's responsibility every time a vendor connected. Today the same 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 endpoint configuration 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 the group's estate to on-premises infrastructure retired without taking anything down with it.