CTM Chose Files.com Over Rebuilding an End-of-Life FTP Server for Dozens of Customers

Corporate Travel Management (CTM) is one of the largest travel management companies in the world: ASX-listed, estimated to be the fourth largest globally, with a network spanning more than 100 countries. CTM manages corporate and government travel programmes across four regions: Australia and New Zealand, Asia, North America, and UK/EMEA.

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 CTM'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 CTM provides. For years, providing that endpoint meant hosting it—and owning the hardware, patching, and security. When Asia's end-of-life server meant dozens of customers would have to repoint their scripts, CTM chose to use that unavoidable migration to leave self-hosted transfer infrastructure behind.

An End-of-Life FTP Server With Dozens of Customers' Scripts Pointed at It

In Asia, the endpoint was a self-hosted Linux FTP server, and it had reached the end of its life. It needed vulnerabilities patched, and the external customers who uploaded their data feeds to it did so through scripts CTM did not write and could not change.

The age of the server was only half the problem. Because CTM hosted it, CTM answered for how every one of those customers chose to connect, including the ones who could only upload over plain-text FTP. Under CTM's ISO compliance obligations, every one of those insecure connections had to be argued as an exemption: this customer uses that system, they cannot change it, and CTM needs an exception for it.

CTM 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 Windows server bought nothing permanent. CTM would still be the host, still liable for how its customers chose to connect, and still face the same migration again at the new server's end of life. Every one of those companies would reconfigure their automation so that CTM could land on different hardware with the same problem.

What the Replacement Had to Do

If the coordination cost was unavoidable, CTM 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 four regions with four IT leaderships without fragmenting into four separate platforms. And it had to take CTM out of the hosting business, so the next end-of-life cycle, the next round of patching, and the next customer's insecure protocol choice were no longer CTM's to own.

CTM selected Files.com to be that endpoint.

A Region as a Standalone Tenant Under One Parent

Using Files.com child sites, CTM 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 CTM'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 CTM's infrastructure. The security CTM answered for would be the leg between Files.com and CTM's own systems: a connection CTM controlled at both ends.

Less Work, Less Management, and No Next Rebuild

After cutover, plain-text FTP connections would terminate at Files.com rather than inside CTM's infrastructure, so ISO compliance would no longer depend on per-customer exemption arguments. And there would be no CTM server to patch, certify, or replace.

Spending the Migration Once

CTM faced the decision every company with an aging 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 liability and the same migration waiting at the end. CTM chose to spend it on Files.com instead, so it would not have to spend it again.