Marketbridge Replaced Azure Blob Storage SFTP With Files.com Without Moving the Data Databricks Reads

Marketbridge is a B2B go-to-market consultancy assembled, deliberately, from five companies at once. Launched in September 2024, it pairs a management-consulting spine with agency muscle: strategy, marketing and communications, data science, and analytics under one roof, with hundreds of people across the US, Canada, and the UK.

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

Three Problems Marketbridge Could Not Fix in Azure's Native SFTP

Legacy Marketbridge 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. Then a security audit found the first of three problems that could not be fixed from inside that setup.

Marketbridge's own TLS minimum was 1.2. But on Microsoft's implementation, TLS 1.0 and 1.1 remained technically available, and the auditors flagged it. The ciphers were not Marketbridge's to remove.

“TLS 1.0 and 1.1 are still technically available to Microsoft, and we wanted to use a solution where those ciphers and that TLS level aren't even supported anymore.”

The second problem was the audit trail. For a firm handling data for healthcare clients, the question that matters is who accessed a file and who viewed it. Blob storage logging could not answer at the user level.

The third was operational. Automations were hard to build against SFTP on a storage account, so inbound client data moved by hand: a client emailed to say a file was ready, and an engineer copied it 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

None of the three could be remediated in place, because all three lived in Microsoft's implementation rather than in Marketbridge's configuration. And the obvious escape, migrating to a new platform's storage, was off the table too: certain blob containers were connected directly to Databricks, and that storage had to remain the source of truth for the data science team.

The arrangement also stopped being survivable in late 2024. The merger had multiplied legacy Marketbridge's headcount, and a company growing that way needed one centralized transfer platform with access driven from the directory instead of administered by hand. The alternative Marketbridge 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 ship with the legacy TLS ciphers absent, not merely disabled. 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. Marketbridge selected Files.com to be that layer.

Files.com Mounted Over the Same Azure Containers

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

The Audit Finding Closed, and Nobody Copies Files Anymore

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

• The audit finding is closed the strongest way a finding can close: TLS 1.0 and 1.1 are not supported on Files.com at all, so there is no legacy cipher 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, the user-level record blob storage logging could not produce.
• 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 Was the Problem, Not the Storage

Nothing was ever wrong with Marketbridge's storage. 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 instead of a reconstruction. A client's dataset is in front of the data science team without an engineer touching it. And the security posture of the front door no longer depends on ciphers someone else controls. Marketbridge did not move off Azure. With Files.com, it replaced the one layer that was failing and kept everything underneath.