A Global Hotel Management Company Closed Its Last Data Center With Granular SFTP Connection Control on Files.com

A global hotel management company runs hotels for the people who own them, operating more than a thousand properties across dozens of brands. After the company migrated all of its servers into Azure, one workload kept its European data center open: a traditional SFTP server receiving nightly files from Oracle Opera.

Running other people's hotels means running other vendors' systems. The point-of-sale platforms inside those properties answer to their vendors' roadmaps, not to the company, and yet the revenue they record every night has to land in the company's own ERP, Business Central, where the owners' books are kept. At hotel properties across Europe and Latin America, that system is Oracle's Opera point-of-sale. Every night, each property's Opera instance opens an SFTP connection, drops its revenue and transaction files, and the company's applications carry them into the ERP. The company controls one end of that connection. Oracle controls the other.

The Last Server in the European Data Center

The traditional SFTP server, hosted and managed by a third party, remained in the company's European data center solely to receive the nightly Opera file drops. Until that endpoint moved, the data center could not close. An organization that had finished its cloud migration everywhere else was keeping a data center arrangement alive for a single file feed.

The feed could not simply be pointed somewhere new, because Opera fixes its own connection parameters, including the protocol versions and cipher suites it will negotiate. The vendor system set the connection terms, and the receiving endpoint had to match them exactly. The files themselves are small, a night's revenue and transactions per property. The problem was never volume. It was negotiation, and the revenue picture in Business Central for two regions depended on the negotiation succeeding every night.

The Endpoints the Company Already Owned Could Not Take the Feed

The company already owned a managed file transfer platform: MoveIt. It exposed no granular control over which ciphers or protocols its SFTP endpoint would negotiate, so the company could not set the endpoint to match Opera's connection parameters. Opera could not connect.

Azure Blob SFTP was the obvious second answer, since every other workload had already landed in Azure. Opera could not connect to it either.

That left the fallback every IT team knows: stand up your own SFTP server and configure it to speak whatever the vendor needs. The company refused. A self-managed server meant owning one more piece of infrastructure indefinitely, inside an IT organization that is intentionally lean and whose standing policy is to buy SaaS rather than build and maintain its own.

So the requirement wrote itself: a SaaS endpoint with no infrastructure for the company to own, granular control over exactly which ciphers and protocols that endpoint negotiates, and a fixed address the European side could allowlist.

The company selected Files.com to be that endpoint.

An Endpoint Set to Match the Feed

Files.com exposes granular control over the cipher suites and protocols its SFTP endpoint will negotiate, so the company configured the endpoint to match Opera's connection parameters exactly. Nothing had to change on the vendor's side.

Onboarding the vendor took a credential scoped to the feed's subdirectory and a fixed address under the company's own name, using Files.com's Custom Domain with static IP addressing. The European network side could allowlist it, and each Opera instance only had to connect and start dropping files.

The migration ran in parallel. The old server kept receiving files while the Files.com endpoint was validated, and only then did the feed cut over. Downstream, nothing changed: the company's applications collect the files and process them into Business Central exactly as before. The Opera feed was the last workload to leave the European data center, and once it cut over, nothing was left to keep the facility open.

The Data Center Closed and the Files Kept Arriving

With the cutover validated, the company retired the third-party-hosted SFTP server and finished the exit it had been blocked on.

• Oracle Opera connects to Files.com on its own connection parameters, and the nightly drops have run ever since, with nothing changed on the vendor's side.
• The European data center closed. The Opera feed was the last on-premise dependency, and with it gone, so was the facility and the hosting arrangement behind it.
• Nobody at the company patches an SFTP server. The connection parameters Opera requires are a setting the company controls on a scoped endpoint, not a server the company maintains.
• Opera properties across Europe and Latin America deliver to a single endpoint, and the European side allowlists one fixed address.

There is a compounding result underneath the immediate one. The next vendor system that fixes its own connection terms gets the same answer: a scoped credential and a protocol configuration, not new infrastructure. The pattern the company built for Opera works for any system-to-system feed whose parameters are set on the other side.

Connection Terms Met in Configuration, Not Infrastructure

What changed at the company is where a vendor system's connection terms get met. Keeping Opera connected used to mean paying a third party to run a server in a data center the company wanted closed, because the connection could only live on infrastructure configured to those terms. Now it is a configuration on Files.com. The endpoint negotiates what Oracle Opera speaks, the nightly revenue from hotels across Europe and Latin America arrives in the ERP, and the company's IT team runs no server to make that true. A vendor system that sets the connection terms no longer sets the infrastructure.