A Travel Management Company Runs Its Asia Region as a Dedicated Files.com Child Site for In-Region Data Feeds

A global travel management company manages corporate and government travel programmes across several regions, Asia among them.

A large part of what clients buy from a travel management company is data. Bookings, hotel content, supplier feeds, and reporting all move as files, and the company's in-house business intelligence and partner data function operates that exchange on behalf of its client ecosystem. Most of it is machine to machine: scripted uploads, running on the customer's schedule, pointed at an endpoint the company provides. For years, providing that endpoint meant hosting it, with the hardware and its upkeep owned in-house. When the Asia region's hosted endpoint came up for replacement, the company chose to leave self-hosted transfer infrastructure behind rather than build it again.

Dozens of Customers' Scripts Pointed at One Endpoint

In Asia, dozens of external customers uploaded their data feeds to a transfer server the company hosted itself, through scripts it did not write and could not change. Replacing that endpoint meant every one of those customers repointing an upload script.

The company started down the traditional replacement path and got far enough to see what it actually cost.

Contacting every affected customer to repoint their upload scripts was the real cost of the project, and spending it on a new self-hosted server bought nothing permanent. The company would still be the host, and would face the same migration again when that server was replaced in turn. Every one of those companies would reconfigure their automation so that the company could land on different hardware with the same job to do.

What the Replacement Had to Do

If the coordination cost was unavoidable, the company wanted to spend it exactly once. The replacement had to keep scripted SFTP access working, so each customer would repoint an upload script one time and never again. It had to keep Asian customer data in region. It had to fit a company run as separate regions with separate IT leaderships without fragmenting into separate platforms. And it had to take the company out of the hosting business, so the next hardware refresh was no longer the company's to own.

The company selected Files.com to be that endpoint.

A Region as a Standalone Tenant Under One Parent

Using Files.com child sites, the company stood up a dedicated Asia site under its existing parent account. The standalone tenant had its own domain, IP allocation, database tenant, and storage region for in-region data residency. It was provisioned empty, and the Asia customer accounts were created natively inside it so their scripted SFTP access would continue when they repointed.

Because the Asia site is a child of the company's parent account, it is separate where separation counts while remaining part of one governed platform. The region gets its own tenant. The company keeps one system.

Under the new connection model, Asia's customers would connect to Files.com, not to a server inside the company's infrastructure. The leg the company operates would be the one between Files.com and its own systems: a connection it controls at both ends.

Less Work, Less Management, and No Next Rebuild

After cutover, every customer connection would terminate at Files.com rather than inside the company's infrastructure, whichever protocol the customer's script speaks. And there would be no company-owned server to certify or replace.

Spending the Migration Once

The company faced the decision every company hosting its own transfer server eventually faces: the customers have to repoint their scripts no matter what replaces the box. The only question is what that coordination buys. Rebuilding buys the same server on a newer date, with the same hosting work and the same migration waiting at the end. The company chose to spend it on Files.com instead, so it would not have to spend it again.