A Wealth-Accounting Provider Put Files.com in Front of Its Former Parent’s SFTP Server to Move Hundreds of Partners

A US wealth-accounting software provider runs the general ledger platform behind family offices, private banks, wealth advisors and private funds. The accounting itself is structurally hard: complex partnership accounting, a huge variety of structured financial data, and reporting built for the bespoke needs of family offices.

All of it runs on data that arrives from outside. The platform ingests structured financial data from banks, prime brokers, custodians and counterparties, and that data arrives as files, delivered by institutions the company does not control. File transfer is not a back-office chore for this provider. It is the front door of the product.

For most of the company’s history, that front door belonged to somebody else. The company operated for years inside its former parent. In 2025, a private equity firm carved it out as an independent company. The people and the platform came along. The file transfer infrastructure did not.

Hundreds of Trading Partners, All Pointed at a Server the Company Was Leaving

Everything file-related ran inside the parent’s environment. Hundreds of trading partners delivered files to the parent’s shared SFTP server: banks, credit unions, custodians and counterparties, each with individual credentials, while the company’s platform collected the files from that same server for ingestion. The company itself had no managed file transfer tooling, no dedicated IP address, and no file transfer domain of its own. The carve-out meant standing all of that up under the company’s own name.

The company’s problem was never standing up a replacement server. It was moving hundreds of partner connections, each on its own change schedule, off infrastructure it did not control. Financial institutions whitelist by IP address, so every one of those partners had the parent’s IP in its firewall rules and the parent’s address in its scripts and schedules. Moving a partner meant asking a bank or custodian, each with its own change control and its own QA, to repoint to a new address with new credentials. And the feeds had to keep flowing throughout, because the files in them were the raw material of the ledgers the company’s clients ran their wealth on.

Why One Big Cutover Was Never an Option

A synchronized cutover, in which every partner repointed on the same date, was never realistic with hundreds of independent financial institutions on the other end. The company also wanted a migration that asked nothing of the parent’s environment, so the work could run on its own schedule.

That constraint set the requirements. The company needed a static IP its partners could whitelist once, and a custom domain it owned, so future storage changes would not require another partner-facing address change. It needed a fully hosted platform, because a company rebuilding its entire IT estate mid-carve-out was not going to rack and patch file servers on top of everything else. And it needed the new platform to run in parallel with the parent’s server for months, so partners could move one at a time, at their own pace, with both systems live.

The company selected Files.com to be that platform, with a migration design that put Files.com in front of the parent’s SFTP server before moving the storage behind it.

Mounting the Parent’s Server Inside Files.com

The design made Files.com a stable front door whose back end could change without partners ever knowing.

The company stood up its Files.com site on its own branded custom domain with a dedicated static IP: the one address every partner would be asked to adopt. Then, using Files.com remote server mounts, the team mounted the parent’s SFTP server inside the new site, so the folders on the old server appeared as ordinary Files.com folders.

That mount is what made a partner-by-partner migration possible. New credentials were created on Files.com for each partner, and each account was jailed into that partner’s existing folder on the parent’s server. A bank that repointed to the company’s new address landed, through Files.com, in exactly the directory it had always used, with the same files in it. Nothing had to change on the parent’s side.

Partners then cut over client by client, in batches, with both systems live in parallel throughout. In all, hundreds of partner users were bulk-provisioned.

The final step never involved the partners at all. When the company was ready, it flipped home directories from the mounted parent server to Files.com native storage. The address, credentials and folder structure each partner saw stayed identical; only the storage behind them changed. Repointing to the company’s own domain was the only endpoint change asked of a trading partner, and each one made it once.

Out of the Parent’s Environment, With the Feeds Still Running

By mid-2026, the company had moved its hundreds of trading partners and shut down the last connections to the former parent’s server, while the data flows feeding its ledger ran uninterrupted. The shared server the company did not control had been replaced by a managed file transfer environment under its control.

• A major audit fell during the migration period. The company passed it.
• Onboarding the next trading partner is now the company’s own operation rather than a request into someone else’s estate: a partner container, credentials and a folder, with partner team leads able to create and manage their own downstream users, work that previously routed through IT.
• There are no file servers behind any of it. Files.com is fully hosted, so the company does not have to patch file servers or manage their disaster recovery.

A Front Door the Company Owns

Before the migration, every partner connection the company had ran through infrastructure it did not control. Today, when a custodian whitelists an IP to send the company a feed, it whitelists the company’s. When a credential needs rotating or a folder needs restructuring, the company decides and makes the change itself, on Files.com, with every action landing in its own audit log.

The migration also proved something about the order of operations that any carved-out company faces: the new platform did not have to wait for the old one to be emptied. Files.com stood in front of the parent’s server before any data moved, the partners walked through the new front door one at a time, and the storage behind that door changed only when the company was ready.