A Hospitality and Entertainment Company Dropped Azure SFTP for Files.com Without Rewriting Its Integrations

A US hospitality and entertainment company runs two very different businesses under one roof: hotels, and a portfolio of live-event venues and restaurants.

Every one of those businesses is transactional. Hotels run point of sale systems. Venues run ticketing platforms. Payroll, expenses, and supply chain each run on external systems of their own. The data all those systems produce is needed internally: each one exports CSV extracts that have to land in Azure Blob Storage, where the company's ETL jobs pick them up, transform them, and load them into downstream applications and databases. No person touches these files. The whole flow is system to system, and the step connecting the external systems to the internal pipeline is file transfer.

The Feeds Ran Through an Endpoint That Was Not Working Out

The front door for those feeds was Microsoft's Azure SFTP, alongside a couple of other SFTP servers picked up over time. Azure SFTP carried the weight: external systems dropped their extracts there, and a large body of automations moved each file into Blob for ETL pickup. And it was not performing the way the team needed. That put the least dependable component at the head of a pipeline everything else depended on, and turned it into an endpoint the VP of IT and the IT team had to work around rather than rely on. Every daily feed, and every report and application downstream of it, inherited the risk.

Everything Built Around It Made It Expensive to Leave

The obvious question is why an underperforming endpoint stayed in production. The answer was everything attached to it. The automations that routed inbound files, the Blob paths they delivered into, and the ETL jobs keyed to those paths had all been built around Azure SFTP. Replacing the endpoint looked like replacing all of it, and that rewrite was the fence that kept the team where it was.

So a replacement had a narrow specification. It had to present standard SFTP and FTP to external systems that could not be re-engineered. It had to deliver every file into the same Azure Blob containers the ETL jobs already read, so nothing downstream moved. It had to authenticate against the company's Azure AD, keeping the file perimeter under the same conditional access policies as the rest of the Microsoft estate. And it had to offer an API, because the team's ETL tool retrieves files programmatically.

The company selected Files.com to be that endpoint.

New Front Door, Same Landing Zone

Point of sale, ticketing, and the rest of the external systems began delivering their CSV extracts to Files.com over SFTP and FTP, on the company's own branded domain. Behind that endpoint, Files.com mounted Azure Blob Storage as a Remote Server, so the containers the ETL jobs read from appeared as ordinary folders on the platform. Files.com Automations then handled the routing: when an extract arrived, an automation archived it and moved it into its Blob landing path, with every run logged.

Files.com's Azure AD integration kept sign-in and user management under the company's existing conditional access rules, while the Files.com REST API gave the ETL tool the programmatic download workflow it required.

The Swap the Pipeline Never Noticed

With Files.com in production as its ingestion perimeter, the company retired Azure SFTP.

• The automations and integrations built up over years carried over intact. Files land in the same Blob containers they always did, so nothing downstream was rewritten.
• A handful of external transactional systems now deliver their CSV data every day through Files.com, machine to machine, with no one in the path.
• For the small internal team that runs the entire integration estate, connecting another transactional system means adding a credential and an automation rule on the existing endpoint, not standing up and operating another SFTP server.

Replaced at the Perimeter, Not the Pipeline

Today, the team that runs data integration for a hotel and venue portfolio no longer works around an endpoint it could not rely on, and it kept every hour of integration work it had already put in. The replacement happened entirely at the perimeter, and the pipeline behind it never noticed.