How an Audiobook Streaming Service Moved Its Largest Publishers Off Self-Hosted SFTP Without Rebuilding Its Google Cloud Storage Pipeline

A European audiobook and e-book streaming service operates across the whole audiobook value chain, from publishing through production to streaming, in markets worldwide.

That catalog does not appear by itself. Every title on the platform arrives as media files and metadata delivered by a publisher or aggregator, and the largest of those, more than a hundred publishers and aggregators, deliver in bulk: hundreds of gigabytes of audio a day, in very large batches. Publisher ingestion is the intake of the entire product. For years, it ran through a single SFTP server that the company built and operated itself.

The company ultimately moved those publishers one at a time to Files.com, kept the Google Cloud Storage pipeline behind them intact, and absorbed a growing daily transfer volume without adding servers.

The Whole Catalog Arrived Through a Server the Company Ran Itself

The server was a self-hosted SFTP service on a Google Cloud VM, owned and operated by the Content Services engineering team. Publishers connected to it directly to upload audio and metadata, and from there files moved into the Google Cloud Storage buckets that feed the rest of the content pipeline.

By 2023, that server carried the accounts of more than a hundred publishers and took in hundreds of gigabytes of uploads on an average day. Every part of it was the company's to run: the VM, the SFTP software, the accounts, the upgrades. Keeping it current had become a standing drain on a team whose actual job was the content platform.

The company was in the business of streaming stories, and it had ended up in the business of operating internet-facing transfer infrastructure. The two had nothing to do with each other, and the second was taxing the engineers responsible for the first.

Why More Than a Hundred Publishers Couldn't Just Be Pointed Somewhere Else

More than a hundred external publishers had integrations aimed at the server, each running its own tooling on its own schedule, and none of them under the company's control. Any replacement had to meet them exactly where they were.

That set the requirements. The new intake had to speak plain SFTP, because that is what the publishers' systems already spoke. It had to keep every publisher walled off from every other. It had to absorb the real workload: hundreds of thousands of files a month, with individual files running to many gigabytes. And it had to hand everything into the existing Google Cloud Storage buckets, because the company had no intention of rebuilding the pipeline behind them.

The company's IT Operations team had already been consolidating the company's scattered departmental FTP systems onto Files.com. The Content team decided the ingestion server should follow, and selected Files.com to be the managed, publisher-facing layer in front of its cloud storage.

A Folder Per Publisher, Swept Into Google Cloud Storage

The company stood up a dedicated ingestion site alongside its general-purpose company site. Each publisher received a folder and an account of its own. A publisher connected over SFTP with whatever client it already ran and saw only its own folder.

Behind the folders, Files.com's sync engine pushed everything into Google Cloud Storage and removed each file from Files.com once its transfer was confirmed. The buckets were the same ones the content pipeline had always read from, so nothing downstream changed. Files.com is not where the company's content lives; it is the front door the content walks through, and a file stays on it only as long as it takes to confirm it has landed in the bucket.

Cutover One Publisher at a Time

Moving more than a hundred external counterparties is where projects like this usually stall, and the company treated the cutover as its own piece of engineering. The team began by sizing the real workload and confirming which publisher integrations were active, so the cutover plan covered live publishers and nothing else.

Then it ran the two systems in parallel. A test environment came first, then internal accounts, then a handful of pilot publishers to validate the path end to end. Only after that did the cutover begin, publisher by publisher. Each move was small enough to schedule with the individual publisher, and each one was a fresh start for the account: as a publisher moved, the team issued its connection details and credentials under the company's current credential policy.

There was no big-bang weekend and no synchronized change across a hundred companies the company does not control. Before summer 2024, all of the largest publishers were delivering through Files.com, and the self-hosted server was decommissioned.

Growing Daily Volume, and No Server Left to Patch

With the ingestion perimeter on Files.com, the company replaced a server its engineers had to keep alive with a service that runs without them.

• The self-hosted SFTP server is gone. Nobody at the company patches, upgrades, or operates publisher-facing transfer infrastructure anymore; the Content Services engineers work on the content platform instead.
• All of the largest publishers and aggregators deliver through Files.com, each in its own isolated folder, each on credentials issued under the company's current policy.
• Content never lingers on the perimeter. Every file is swept into Google Cloud Storage and removed from Files.com the moment its transfer is confirmed, and the pipeline behind the buckets was never touched.
• Growth stopped being an infrastructure problem. A single publisher uploading a very large batch at once is within normal range, and typical daily transfer has kept rising. Absorbing that took no new servers and no project.

The Content Team Works on the Content Platform

The lesson in the company's migration is that retiring the old server never required a leap. It was replaced one publisher at a time, on a schedule the company controlled, with each account re-provisioned as it moved, and the Google Cloud Storage pipeline behind it never noticed the change. Files.com became the front door of the catalog. Everything behind the door stayed exactly where it was.