MDS Group Used Files.com to Retire CentOS 7.9 SFTP Servers Across 25 Companies, One at a Time

MDS Group is a multinational insurance and reinsurance brokerage and risk consultancy, part of the Ardonagh Group, one of the world's twenty largest insurance brokers. MDS is a market leader in Portugal and Angola and holds a top-three position in Brazil, where its acquisition of D'Or Consultoria roughly doubled the size of its operation and created the largest independent broker in the country. D'Or brought with it 2.3 million health-plan beneficiaries contracted through more than 3,000 companies.

A brokerage at that scale runs on files moving between organizations. Policy, benefits, and claims data travels between the group's companies and their corporate clients, including banks and peer brokerages, and much of it is personal and health data, which Brazil's LGPD treats as sensitive. And a group built by acquisition inherits a file-exchange arrangement with every company it acquires. The Brazilian operation spanned 25 subsidiary companies, each exchanging files with its own corporate clients, on infrastructure the group's own team had to keep alive.

A File-Transfer Estate the Group Had Outgrown

That infrastructure was a set of self-managed SFTP servers: on-premises machines running CentOS 7.9, plus more SFTP servers hosted in the cloud. MDS had outgrown running its own file-transfer servers. CentOS 7.9 was well past its useful life, and keeping it on the internet as the front door for sensitive client data meant carrying a risk every single day the servers stayed up, on top of the cost of maintaining them.

“The operating system we are using right now is CentOS 7.9, which is a really old one. Imagine the security side of things.”

The group's leadership wanted the SFTP servers gone as soon as possible, for the security exposure and for what they cost to run on-premises. And the servers were only half the problem. With 25 companies each exchanging files its own way, there was no common access model across the group: no single answer to which client could reach what, and no consistent record of who took which file. For a broker handling health data under LGPD, that is a governance gap, not an untidiness.

The Servers Everyone Was Connected To

The estate had survived this long because it could not simply be switched off. Corporate clients, banks among them, connected to those servers from their own systems, on their own schedules, over SFTP, FTP, and AS2. Breaking a bank's connection means breaking business. And no single synchronized cutover was available, because each subsidiary answers to its own management, and each company's migration needed that company's sign-off. A big-bang migration across 25 companies and every client they serve was never on the table.

So whatever replaced the servers had to meet four requirements. It had to speak the protocols clients already used, so that switching a client over meant changing a hostname and a credential rather than starting a project on their side. It had to wall each client organization into its own space with its own credentials. It had to record who took which file and when, the picture LGPD asks the group to have. And it had to allow the migration to run one company at a time.

MDS selected Files.com to be that single client-facing exchange layer. It gave MDS a way to move one independently managed company at a time—and a repeatable model it could use as the acquisition-built group grows.

Migrating Company by Company, Behind Each Manager's Sign-Off

Getting the data across came first. Ferrari attached the legacy CentOS server to Files.com as a Remote Server integration, so its contents were reachable alongside the new folder structure he was building, and copied over what he needed.

“I copied everything I wanted to the folders I created inside Files.com, and that was it. Easy peasy, no problem at all.”

Then the cutover ran as a repeating pattern rather than one project. For each subsidiary, that company's files were pre-loaded into Files.com folders, and its clients' access was then switched from the on-premises server to Files.com, sequenced behind approval from that subsidiary's manager. A company whose management was not ready simply waited its turn. Nothing in the pattern depended on everyone moving at once, and company by company, the old servers emptied out.

One Folder and One Credential per Client

On Files.com, MDS built the per-client model the old servers never had. Each corporate client got its own folder and its own credentials, and using the SFTP client root folder setting, each client's session is locked to that folder with parent paths hidden: a client logs in, sees its own folder, and sees nothing else. Internal folders sit under a separate permission set, segregated from anything a client can reach. Clients retain their existing connection methods, while the group's own systems work against the same Files.com exchange layer programmatically. Every action on a partner file lands in the audit log.

“I have the automation to let me know who did it, who took the file, when they took the file, so I have the whole picture of what is happening toward those files, especially because here in Brazil we have the LGPD rules in place.”

The SFTP Servers Are Gone

With the cutovers done, MDS replaced a server estate its own team had to defend with a client exchange it administers but does not operate.

• The on-premises and cloud SFTP servers are out of the file-exchange path. Nobody at MDS patches an end-of-life operating system that faces the internet, and the cost of maintaining servers whose only job was moving files went with them.
• 25 subsidiary companies exchange files with their corporate clients through one platform, under one permission model, instead of 25 separate arrangements.
• Every client connection is isolated by construction: a client's credential opens its own folder and nothing else, over whichever protocol it uses.
• The LGPD audit picture, who took which file and when, is produced by the platform on every transfer rather than assembled after the fact.

The pattern also generalizes. Onboarding a new corporate client is a folder and a credential. Migrating an acquired company is a rehearsed sequence of pre-loading its files, switching its clients' access, and getting its manager's sign-off. For a group that grows by acquisition, that repeatability is the result that compounds.

One Exchange Layer for a Group Built by Acquisition

The migration proved something as useful as what it removed: a 25-company SFTP estate did not need one synchronized, high-risk cutover. It was retired the way it had been built, one company at a time.