Assembly Replaced AWS Transfer Family With Files.com to Move Stage to Google Cloud—Without Disrupting Hundreds of Senders

Assembly is a global omnichannel media agency in the Stagwell network. Its performance marketing and client data analytics services are powered by Stage, a proprietary platform that aggregates marketing and business data in BigQuery and serves the dashboards clients use to steer their campaigns.

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

After standardizing Stage 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 Stage's Cloud Migration Hostage

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

It was nearly blind. The analytics and tracking on the AWS layer were so thin that the team had almost no view into the tier feeding its clients' morning dashboards. When data was late, the first question was always where the file was, and the layer responsible could not answer it.

“Our clients are making decisions on ad spend and campaign optimization based on the data they're getting in the morning or what's happening in real time. If I can't get that data in a timely fashion, they can't make decisions on millions of dollars of media spend.”

It could not encrypt or decrypt. A healthcare client required its files to arrive GPG-encrypted, be decrypted for ETL processing, and be returned re-encrypted under the client's own key. Transfer Family had no way to do any of that, and encryption around it was a problem Assembly had been trying to solve on its own without an answer.

And it was bound to the wrong cloud. Assembly had decided to move Stage 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. Assembly'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. Assembly 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. Assembly is in the data business, not the file-transfer infrastructure business, and standing up and maintaining its own SFTP tier at 600,000 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. Assembly selected Files.com as that gateway.

The Hostname Stayed While the Backend Became Files.com

Assembly 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.

Assembly 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. Two hundred 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 Stage'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 the AWS tier could not support now 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, Assembly replaced a transfer layer bound to one cloud and blind to its own traffic with a gateway it can move, watch, and encrypt through.

• Stage moved from AWS to Google Cloud with no sender-side cutover.
• Encryption is now inside the transfer: 200 GPG automations handle decryption on arrival and re-encryption on delivery, closing the gap Assembly had been trying to engineer around.
• A healthcare client's encrypted data exchange, impossible on Transfer Family, 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 instead of guessing at a layer it could not see.

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, Stage'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 Assembly does not control. Now the perimeter is Assembly's. A company that owns its transfer hostname can move its entire backend, even across clouds, and its counterparties never have to know.