A B2B Consultancy Runs Client Data Intake Through Files.com Over the Azure Storage Databricks Reads

A B2B go-to-market consultancy was assembled, deliberately, from several companies at once. It pairs a management-consulting spine with agency muscle: strategy, marketing and communications, data science, and analytics under one roof.

The analytics side of that business runs on client data. Clients deliver files, the consultancy's data science team works them in Databricks, and insight comes back out. That makes file transfer more than back-office plumbing at the consultancy: it is the front door of the product, and much of what comes through it is regulated data from healthcare and financial services clients.

The Bar a Regulated-Data Front Door Has to Clear

Before the merger, the consultancy ran that front door the way many Azure shops do: SFTP enabled natively on an Azure Storage account. Clients connected over SFTP and dropped files into blob containers. Employees reached the same files through Azure Storage Explorer.

The consultancy wanted a front door that met the standard its healthcare and financial services clients hold it to: a TLS floor set by the platform itself, an activity log that names the user behind every file action, and an intake path with no engineer copying files between storage accounts. On a storage account, an engineer copied each client delivery by hand from the SFTP container into the separate storage account wired to the Databricks catalog. The intake path of an analytics business had a person in the middle of it.

The Storage Had to Stay Where Databricks Could Read It

Native SFTP on a storage account does not clear that bar from inside the consultancy's configuration, so the layer had to change. The storage could not: certain blob containers were connected directly to Databricks, and that storage had to remain the source of truth for the data science team.

The timing was set by the merger. The combined company needed one centralized transfer platform with access driven from the directory instead of administered by hand. The alternative the consultancy costed was self-hosted: a server for SFTP software, a file server, and a third server for home folders. Three machines to build and patch was the wrong direction for a company expanding by acquisition.

So the requirement was specific. Whatever replaced the native SFTP endpoint had to sit in front of the Azure storage that stayed. It had to be TLS 1.2-only by construction, not by setting. It had to log activity down to the individual user, provision and revoke access from Microsoft Entra ID, keep each client fenced to its own data, and give employees one URL in place of Storage Explorer. The consultancy selected Files.com to be that layer.

Files.com Mounted Over the Same Azure Containers

The consultancy built a governed transfer surface over storage that never moved.

Using Files.com Remote Server Mounts, the blob container hierarchy appears as Files.com folders in real time. A file a client uploads over SFTP writes straight into the container behind it, and because those are the same containers Databricks reads, a client's delivery is already sitting where the analytics catalog looks. There was no migration, and there is no second copy.

Each client has its own container, mounted as its own folder, with a Files.com group matched to it and permission fencing on top, so a client login sees exactly one folder whether that client connects over SFTP or through the web interface.

Internally, identity comes from Entra ID. Single sign-on handles login, and SCIM provisioning creates accounts from the directory and deactivates them the same way: remove someone from provisioning and their file access is gone. Nobody maintains file users by hand across the merged company. For external senders, both regular uploaders and one-off contributors use the same audited surface.

Employees now reach Azure-backed content through the Files.com web interface at a single URL. Azure Storage Explorer was retired, and the three-server build was never started. The rollout went business unit by business unit, data science first and marketing services after.

TLS 1.2 Only, and Nobody Copies Files Anymore

With Files.com in production, the consultancy replaced SFTP on a storage account, and the manual handling built around it, with a governed transfer layer over the same storage.

• The endpoint is TLS 1.2-only by construction: TLS 1.0 and 1.1 are not supported on Files.com at all, so there is nothing to disable and nothing to explain at the next audit.
• Every file action is attributable. The log records who accessed a file and who viewed it, at the user level.
• Client data lands directly in the containers Databricks reads. Nobody copies files between storage accounts to feed the analytics pipeline.
• The three-server self-hosted build was never started, and file accounts are not administered by hand: access is provisioned when someone joins and revoked when they leave, straight from the directory.

The compounding result is the pattern itself. Onboarding the next client is a container, a mount, and a group. Onboarding people from another business unit is a directory sync. The deployment that began with the data science team reached marketing services within its first year without the architecture changing.

The Layer Changed, Not the Storage

The consultancy's storage did not move. Azure Blob still holds the client files in this workflow today, and Databricks still reads the same containers it always did. What changed is the layer in front. An auditor who asks who viewed a file gets a lookup. A client's dataset is in front of the data science team without an engineer touching it. And the front door's TLS floor is a property of the platform. The consultancy did not move off Azure. With Files.com, it replaced the layer in front and kept everything underneath.