CDP Replaced AWS Transfer Family and ShareFile With Files.com, Without Leaving S3

Contributor Development Partnership (CDP) is a public benefit corporation that runs collaborative fundraising for more than 230 public radio and television stations across the United States. Founded inside Boston's WGBH in 2011 and later spun out as an independent company, CDP built a national repository of donor and transaction data pooled from stations nationwide.

Every station chooses its own fundraising CRM, so CDP built a universal data model that maps all of them into one. That decision makes the whole operation a file exchange business at its core. Each month, stations send in refresh data, CDP runs it through its analytics stack, and benchmarks, reports and contact lists flow back out. Roughly 200 stations feed that cycle. The data has to land in AWS S3, where file notifications kick off pipelines into Snowflake. And the people sending it are station fundraising staff, not engineers.

Two File Transfer Products for One Job

The pipeline side of the house had exactly what it needed. AWS Transfer Family gave CDP an SFTP endpoint that dropped files straight into S3, so every upload triggered the downstream processing automatically. But it gave the stations nothing. There was no web experience a fundraising manager at a member station could reasonably use, and the endpoint itself was expensive to keep running.

So CDP ran a second product alongside it. Citrix ShareFile handled the human exchange with stations and vendors, and it sat entirely outside the data pipeline. Every monthly cycle had to bridge that split. Files that arrived through the exchange tool were disconnected from the S3 landing zone the analytics depended on, and CDP was paying for two file transfer platforms, two sets of accounts, and two administration burdens to do one job.

The arrangement survived because the hard requirement ran through S3. Whatever replaced Transfer Family had to keep the bucket as the repository and keep the file notifications firing, or the pipelines into Snowflake would stop. Whatever replaced ShareFile had to be simple enough for hundreds of non-technical external contacts. Neither incumbent could do both, which is why there were two.

As the partner base grew, so did the cost of the split, and the replacement had a clear specification: keep S3 as the storage layer with the pipeline triggers intact, give station contacts a browser upload that asks nothing of them, keep SFTP for the stations that automate their submissions, and meet CDP's security and compliance requirements on one platform instead of two. CDP selected Files.com to be that single layer.

Mounted on the Bucket, Open to the Stations

Using Files.com Remote Server Mounts, CDP put the platform directly on top of the S3 storage it already ran. Nothing migrated. Files uploaded through Files.com land in the same bucket, and the notifications that drive the Snowflake pipelines keep firing exactly as before. What changed was the front door. Stations that automate connect over SFTP with SSH key authentication; stations that don't upload through the browser. Both paths reach the same folders under the same permissions.

CDP rebuilt the folder structure ahead of onboarding, using partner accounts and group-based permissions to give station contacts access only to the appropriate service and input/output folders. On the internal side, Microsoft Entra ID single sign-on with SCIM provisioning creates users and groups straight from the directory, so accounts follow the identity CDP already manages.

From there, the same layer expanded beyond ingestion into CRM delivery, cross-cloud handoffs, and pipeline automation. Files.com Automations move generated CSV batches from the S3-mounted path into an archive and the CRM's inbound SFTP endpoint. A monthly Snowflake extract moves from S3 onto a mounted Google Drive for a client, while CDP's engineers use the Files.com API and SDK from inside Snowflake workflows themselves.

“We use it as part of a mount on top of AWS S3, and it becomes a really integral part of our technical stack.”

One Monthly Cycle, Visible End to End

CDP now tracks submissions from roughly 200 stations centrally, so it can pursue late files before the monthly window closes rather than discover them afterward.

• AWS Transfer Family and Citrix ShareFile are both retired. One platform now carries the SFTP ingestion, the partner exchange, and the scheduled movement between systems.
• Station contacts get one account and one place for everything CDP exchanges with them, whichever services they participate in.
• Over 200 accounts with role-scoped folder access are administered by a single IT specialist.

The larger result is what the layer keeps absorbing. The CRM feed, the cross-cloud client delivery, and the API calls from inside Snowflake were none of them part of the original scope. Each arrived later and landed on the platform that was already there, because the mount, the permissions and the automation engine generalize to whatever file movement comes next.

“New use cases for Files.com are always coming up for us, so having the room to expand is good in our case.”

In the Same Tier as AWS and Snowflake

Today, when CDP describes the cloud infrastructure it uses to support its clients, Files.com appears in the same list as Azure, AWS, Snowflake and Salesforce. That is the measure of what changed: file exchange stopped being two tools bolted onto the edges of the business and became part of the infrastructure the business runs on. A fundraising manager at a member station uploads a refresh file in a browser, and the same Files.com platform hands it to a pipeline, archives the CRM feed, and delivers a client's monthly extract to another cloud, with nobody carrying files between systems by hand.

Replacing AWS Transfer Family never meant leaving S3. The bucket, the data and the pipeline triggers all stayed exactly where they were. Only the layer people touch changed, and now it is one layer instead of two.