A Fundraising Analytics Provider Replaced AWS Transfer Family and ShareFile With Files.com, Without Leaving S3

A fundraising analytics provider runs collaborative fundraising for hundreds of member organizations across the United States, pooling donor and transaction data from members nationwide into one national repository.

Every member chooses its own fundraising CRM, so the provider 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, members send in refresh data, the provider runs it through its analytics stack, and benchmarks, reports and contact lists flow back out. Hundreds of members 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 member 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 the provider an SFTP endpoint that dropped files straight into S3, so every upload triggered the downstream processing automatically. But it gave the members nothing. There was no web experience a fundraising manager at a member organization could reasonably use, and the endpoint itself was expensive to keep running.

So the provider ran a second product alongside it. Citrix ShareFile handled the human exchange with members 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 the provider 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 member contacts a browser upload that asks nothing of them, keep SFTP for the members that automate their submissions, and meet the provider's security and compliance requirements on one platform instead of two. The provider selected Files.com to be that single layer.

Mounted on the Bucket, Open to the Members

Using Files.com Remote Server Mounts, the provider 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. Members that automate connect over SFTP with SSH key authentication; members that don't upload through the browser. Both paths reach the same folders under the same permissions.

The provider rebuilt the folder structure ahead of onboarding, using partner accounts and group-based permissions to give member 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 the provider 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 the provider's engineers use the Files.com API and SDK from inside Snowflake workflows themselves.

One Monthly Cycle, Visible End to End

The provider now tracks submissions from hundreds of members 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.
• Member contacts get one account and one place for everything the provider exchanges with them, whichever services they participate in.
• Hundreds of 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.

In the Same Tier as AWS and Snowflake

Today, when the provider 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 organization 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.