A Global Media Agency Replaced AWS Transfer Family With Files.com to Move Its Data Platform to Google Cloud—Without Disrupting Hundreds of Senders

A global omnichannel media agency runs its performance marketing and client data analytics services on a proprietary data platform that aggregates marketing and business data in BigQuery and serves the dashboards clients use to steer their campaigns.

The platform ingests billions of rows a day, and 10 to 15 percent arrives as files pushed over SFTP by hundreds of external senders: hundreds of thousands of files a day. A platform whose entire value is timely client data depends on a file-transfer tier fed by systems the agency does not control. When the agency decided to move the platform from AWS to Google Cloud, that AWS-native transfer tier could not move with it.

After standardizing the platform on Google Cloud, processing times fell by roughly 70 percent, and onboarding a new client dropped from two or three months to days.

The Transfer Tier That Held the Cloud Migration Hostage

That tier was AWS Transfer Family. Senders pushed files over SFTP, Transfer Family dropped them into S3, and the platform picked them up from there. It carried the volume, and it was failing the agency three ways at once.

It offered thin visibility. The agency wanted a view into the tier feeding its clients' morning dashboards, so a question about where a file was could be answered from a log.

It could not encrypt or decrypt. A healthcare client was coming onto the platform with a requirement the tier could not take on: files arriving GPG-encrypted, decrypted for ETL processing, and returned re-encrypted under the client's own key.

And it was bound to the wrong cloud. The agency had decided to move the platform from AWS to Google Cloud, and an AWS-native transfer service could not make that move. Until the file tier was replaced, the migration could not proceed.

Hundreds of Senders, and Every One of Them Owns Their Side

Replacing an SFTP endpoint normally means coordinating a cutover with every party that connects to it. The agency's connection base ran to hundreds of external senders, most authenticating with usernames and passwords, some with SSH keys, some with IP allowlisting, and each owning its own side of the connection. The agency could not schedule their changes, test their scripts, or force their timelines. That coordination problem is where migrations like this one stall for years.

Building a replacement in-house was rejected outright. The agency is in the data business, not the file-transfer infrastructure business, and standing up and maintaining its own SFTP tier at hundreds of thousands of files a day was exactly the work it did not want to own.

What the replacement had to do was clear: speak plain SFTP to hundreds of existing senders without any of them changing anything, run independently of any one cloud, encrypt and decrypt inside the flow rather than around it, and give the team visibility the AWS layer never had. The agency selected Files.com as that gateway.

The Hostname Stayed While the Backend Became Files.com

The agency owns the SFTP hostname its senders connect to, and that fact dissolved the coordination problem. The endpoint never moved. The hostname stayed identical, and the backend behind it became Files.com, with the existing mix of passwords, SSH keys, and IP allowlists carried across. Senders kept connecting exactly as they always had. There was nothing to announce, nothing for anyone to install, and no cutover to negotiate with hundreds of companies.

The agency sequenced the migration in two phases. First, files landed in Files.com and flowed through the existing AWS path while the immediate healthcare encryption workflow went live. The second phase switched the transfer tier to direct Google Cloud integration under OAuth 2.0.

Decryption on Arrival, Re-Encryption on the Way Back

With Files.com as the front door, encryption stopped being a separate problem and became a property of the transfer. Hundreds of GPG automations run across the connection base: encrypted files decrypt automatically on arrival, with keys held in the Files.com GPG Key Manager, and land in Google Cloud Storage for the platform's ETL to load into BigQuery. On the return leg, processed output is re-encrypted for client pickup. The same platform delivers transformed data outbound to S3, Azure Blob, Google Cloud Storage, and partner SFTP endpoints in the tabular formats clients consume.

The healthcare exchange runs daily: files arrive under the client's encryption, decrypt for processing, and return re-encrypted under the client's own key, with every step applied automatically.

What Changed When the Gateway Went Cloud-Neutral

With Files.com running the inbound tier, the agency replaced a transfer layer bound to one cloud with a gateway it can move, watch, and encrypt through.

• The data platform moved from AWS to Google Cloud with no sender-side cutover.
• Encryption is now inside the transfer: hundreds of GPG automations handle decryption on arrival and re-encryption on delivery.
• A healthcare client's encrypted data exchange runs every day as a standard workflow rather than an exception.
• Transfer activity streams into Datadog, so when a client asks where its morning data is, the team answers from a log.

The compounding result sits underneath all of it: the next infrastructure change happens behind the same hostname, without asking anything of the hundreds of companies on the other side.

A Data Platform That Owns Its Front Door

Before Files.com, the platform's file perimeter belonged to the cloud it happened to run in, and every infrastructure decision behind that perimeter carried the price of renegotiating with hundreds of counterparties the agency does not control. Now the perimeter is the agency's. A company that owns its transfer hostname can move its entire backend, even across clouds, and its counterparties never have to know.