An Insurance Brokerage Retires Self-Managed SFTP Servers Across Two Dozen Companies With Files.com, One at a Time

A multinational insurance and reinsurance brokerage and risk consultancy has grown by acquisition, and one acquisition roughly doubled the size of its operation in one of its largest markets. That operation brought with it millions of health-plan beneficiaries contracted through thousands of 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 the local data-protection law treats as sensitive. And a group built by acquisition inherits a file-exchange arrangement with every company it acquires. The operation spanned two dozen subsidiary companies, each exchanging files with its own corporate clients, on infrastructure the group's own team had to run itself.

A File-Transfer Estate the Group Had Outgrown

That infrastructure was a set of self-managed SFTP servers: on-premises machines, plus more SFTP servers hosted in the cloud. The group had outgrown running its own file-transfer servers, and wanted the group's client exchange on a platform it administers but does not operate.

The group's leadership wanted the servers retired and the cost of running them on-premises gone. And the servers were only half the work. With two dozen companies each exchanging files its own way, the group wanted one access model and one audit trail across all of them: a single answer to which client could reach what, and one record of who took which file. For a broker handling health data under data-protection law, that record is the standard the law asks the group to meet.

The Servers Everyone Was Connected To

The estate 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 two dozen 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 the data-protection law asks the group to have. And it had to allow the migration to run one company at a time.

The group selected Files.com to be that single client-facing exchange layer. It gave the group 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. The group's team attached the legacy on-premises server to Files.com as a Remote Server integration, so its contents were reachable alongside the new folder structure it was building, and copied over what it needed.

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, the group built a per-client model. 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.

The SFTP Servers Are Gone

With the cutovers done, the group replaced a server estate its own team had to run 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 the group runs a server whose only job is moving files, and the cost of maintaining them went with them.
• Two dozen subsidiary companies exchange files with their corporate clients through one platform, under one permission model, instead of two dozen 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 data-protection audit picture, who took which file and when, is produced by the platform on every transfer.

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 two-dozen-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.