A Fitness Club Operator Moved Hundreds of Gigabytes Off Its Last Third-Party-Hosted FTP Server with Files.com

A fitness club operator runs dozens of high-volume clubs in the United States. Its infrastructure follows an entirely cloud-based model. The company 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 the Company Was Still Paying For

The company'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 the company 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 the company 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. Hundreds of gigabytes 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 the company'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.

The company moved the workload to Files.com.

Hundreds of Gigabytes in One Move, Then a Month in Parallel

The business analyst who runs the company'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 hundreds of gigabytes 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, the analyst 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, the company 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 thousands of 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 the analyst, what makes that workable is that the platform stays simple for the analyst running it.

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. The company'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, the operator 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 the company has to think about. The last server the company paid for is gone, and retiring it was a configuration exercise rather than a project.