A Compliance Software Company Replaces AWS Transfer Family With Files.com Without Changing Customer Endpoints

A global compliance software company sells governance, risk and compliance software. Its platform runs ethics, risk, compliance, and audit programs, and its learning business provides compliance training. Its customers are the organizations regulators watch hardest: hospitals, government bodies, large defense contractors, European banks. The company's stated focus is high-risk, highly regulated sectors, and compliance is not a department at the company. It is the product.

That puts the company's own file exchange under the same scrutiny its software helps customers manage. Customers move data into and out of the company's applications constantly: automated imports, integration feeds, extracts flowing back the other way. Roughly 90% of those customers carry data residency mandates. US data stays stateside, European data stays in Europe, Australian data stays in Australia. And every customer's data has to be kept apart from every other customer's.

A vendor built on those promises has to keep them by construction. The company set out to make residency and isolation properties of its architecture.

Three SFTP Endpoints, Pinned to a Cloud the Company Was Leaving

Customer file exchange ran on infrastructure the company maintained itself: three regional AWS Transfer Family SFTP endpoints backed by S3, one each for the Americas, EMEA, and Australia, plus a separate self-run SFTP server. It met the residency requirement region by region, and it worked. That is why it survived as long as it did.

It also kept the cloud operations team in the loop for every change. Per-customer isolation was configured by the cloud team, customer by customer, and the company wanted the business divisions that set up customer access to be able to do it themselves, with each customer's storage separate and each division confined to its own. Isolation had to become something the storage layout enforces, provisioned as code.

Two things forced the change. First, the company committed to migrating its major workloads from AWS to Google Cloud, running cutovers almost every weekend. Every customer-facing endpoint was anchored to the cloud being left, and moving an endpoint meant touching every automated customer integration behind it. Second, per-customer isolation was about to scale: dozens of compliance customers across three regions each required a fully siloed environment, and the company's Global Head of Engineering put the ceiling at roughly a thousand clients who could need a data exchange.

The Transfer Platform Could Not Own the Storage

The requirements described the gap precisely. Residency had to be enforced by architecture, so a US customer physically could not land data in Europe and a European customer physically could not land data anywhere else. Each customer needed its own segregated storage, per product line. The storage itself had to stay inside the company's own cloud projects, because a platform that held the data would fail the security requirement outright. And the whole thing had to be indifferent to which cloud sat underneath, because the storage was mid-move.

The company selected Files.com to be that front end. It gave the company a cloud-independent gateway: regional sites and per-customer mounts enforced residency and isolation in the company's own buckets, while customer-facing paths and endpoints stayed stable as the storage behind them moved from S3 to GCS.

Three Regional Child Sites, One Bucket per Customer

Residency is enforced by the site itself. The company stood up its Americas site first, then Files.com child sites in Frankfurt for EMEA and Australia for APAC. Each child site is a fully separate environment with its own endpoint, so a customer connects in its own region and its data stays there. There is no configuration step that keeps EMEA data in Europe. The architecture does.

Isolation is enforced by the storage. Using Files.com remote server mounts, each customer-facing folder connects directly to a Google Cloud Storage or S3 bucket inside the company's own cloud projects, with one bucket per customer, segregated per product line. Customers connect over SFTP or the web and data flows both directions: uploads land in the customer's own bucket, and the company's backend services drop extracts into that bucket for the customer to collect. One customer cannot see another's data because the storage is not shared in the first place, and none of it sits on Files.com.

Provisioning is code. The company runs Terraform and Ansible across its estate, and it provisions Files.com the same way, using the Files.com Terraform provider with the API covering the rest. Standing up the exchange for a new customer means creating a bucket, mounting it, and applying the configuration.

Moving the Storage Without Moving the Endpoints

The rollout ran alongside the AWS-to-GCP migration, phased by business unit with the learning division first. Where a workload still lived on AWS, Files.com mounted the S3 bucket directly. As migration windows opened, the company redirected the same folder structures to GCS. The paths and endpoints customers connected to never changed, and by August 2025 nearly every workload was running in Google Cloud.

Residency by Design, Isolation by Bucket

With the regional gateway in production, the company traded self-run SFTP infrastructure for a structural pattern:

• Data residency is a property of the architecture for customers who mandate it. A customer connects to its own region's endpoint and its data cannot land anywhere else.
• Per-customer isolation is physical. Compliance customers exchange files through their own buckets in the company's cloud projects, so the siloing the company promises its customers is enforced by the storage layout itself.
• The customer-facing endpoints are decoupled from the cloud behind them. The company moved its storage from AWS to GCP under the gateway without disrupting the workflows running through it.
• Onboarding the next customer is a bucket, a mount, and a Terraform run. The same code-based pattern can be repeated as adoption expands.

A Front Door That Outlives the Cloud Behind It

The company did not hand its customer data to a transfer vendor. It put Files.com in front of storage it already controls, which is what let a company whose product is compliance make residency and isolation properties of its architecture, and what let it change clouds without its customers ever touching an integration. Where the data lives is the company's decision. Where customers connect no longer depends on it.