VASA Fitness Moved 400 GB Off Its Last Third-Party-Hosted FTP Server with Files.com

VASA Fitness operates 71 high-volume fitness clubs in the United States. Its infrastructure follows an entirely cloud-based model. VASA hosts nothing. There are no on-premises servers and nothing self-hosted anywhere in the company; every system it runs is a service bought from a third party.

That posture is what made one line item stand out.

The One Server VASA Was Still Paying For

VASA's file exchange with outside parties ran through an FTP server hosted by a paid third-party vendor. The server had one job: hold the data VASA handed off to external parties, and receive the automated files its billing company pushed in on its own schedule. Everything else in the company had already moved to cloud services. This was the last piece of hosted infrastructure left, and VASA was paying a separate vendor purely to keep a legacy server alive so that files could change hands.

It survived because retiring it looked risky. Roughly 400 GB of data sat on the server. An external billing company was pushing files into it, so any replacement had to happen without losing files in flight. The person who would have to do it was a business analyst.

What Replacing It Required

Standing up VASA's own SFTP server was never on the table. The company hosts nothing, and it was not going to start in order to hand off files. The replacement had to take the FTP workload as a service: external senders had to keep pushing files the way they already did, the data had to come off the old server without a project team, and the result had to be operable by one business analyst. Above all, there could be no single hard cutover date. The billing company's pushes had to keep landing somewhere safe through the entire transition.

VASA moved the workload to Files.com.

400 GB in One Move, Then a Month in Parallel

Kalyan Karki, the business analyst who runs VASA's file exchange, executed the migration himself. Using a Files.com remote server connection, he pointed the platform at the legacy FTP host and pulled roughly 400 GB across in a single move. He had wondered whether a transfer that size would go through at all. It did.

The cutover was deliberately unhurried. The billing company began pushing its files to Files.com, and rather than cancelling the old service immediately, Karki kept it running in parallel for about a month as a redundancy check, confirming that every automated push was landing in Files.com and nowhere else. Only then did he disconnect the old server and cancel the hosting service.

File Exchange Without a Server to Keep Alive

With the old server decommissioned, VASA replaced its last piece of paid, hosted infrastructure with file exchange that runs as a service, like everything else in its stack. A company of 4,600 employees now runs its file exchange with outside parties on a platform that one business analyst operates end to end, with no server for anyone to patch, monitor, or pay to keep online.

For Karki, what makes that workable is that the platform stays simple for the one person running it.

“The interface is simple and straightforward.”

Nothing Left to Host

Retiring a hosted FTP service with external automated senders is usually treated as a project: a migration team, a coordinated cutover date, a window where everyone involved holds their breath. VASA's version was one business analyst, a Files.com remote server connection, and a month of watching two destinations until only one mattered.

Before the move, VASA was an all-cloud company with an asterisk: its file handoffs still depended on a vendor keeping a legacy server running. Now the description is simply true. Files arrive from the billing company, data goes out to outside parties, and nowhere in that path is there a server VASA has to think about. The last server the company paid for is gone, and it took one person to retire it.