Files.com Let an Investment Accounting Provider Retire Its On-Premises File Shares Without Rewriting Its Application

An investment accounting software provider builds and operates the general ledger behind wealth managers and private funds. Its platform handles the complex partnership and portfolio accounting behind those clients, with hundreds of billions of dollars in assets on the platform.

What makes that ledger work is data ingestion. The platform pulls structured financial files from major US and international banks, prime brokers, clearing firms, and the regional and local banks other platforms don't cover. Every position and every transaction in a client's ledger starts as a file that landed in the company's environment and got processed. The landing zone for those files is not a side system. It is the front door of the product.

A Flat Folder, Tens of Thousands of Files a Day, and a Terabyte of RAM

For most of its history, the company ran inside a larger parent company, and its file estate ran on the parent's on-premises infrastructure. The landing zone was a set of flat folders on on-premises file shares, and tens of thousands of files a day landed in the largest of them.

Flat folders at that scale have a known failure mode: listing the directory becomes the expensive operation. When the application processed each day's files, it ran into timeouts and performance hiccups. The estate compensated with hardware. The FTP servers had a terabyte of RAM and sat physically next to the servers that processed the files.

The company's information security manager measured what that estate actually cost. Zipping 400 files on the legacy remote server took 45 minutes. Downloading a single multi-gigabyte file took 34 minutes. Those were not outage numbers. They were the ordinary speed of the system the business ran on.

Then a corporate separation split the company from its former parent, and the parent's infrastructure was not coming along. The landing zone and the daily feed that filled it had to move to something the company owned, and the new landing zone would have to hold up under the same directory sizes without a terabyte of RAM behind it.

The Wildcard Problem That Nearly Forced a Rewrite

The obvious destination was cloud storage, and the original plan was to point the application's backend at a mirror copy in Azure. The company's portfolio application discovers its files through a third-party SFTP library that issues wildcard-based find and send calls, and object storage REST APIs drop wildcards. Pointing the application at Azure would have meant rewriting a production financial application in the middle of a separation program run deliberately as lift-and-shift to keep the number of variables down.

So the replacement landing zone had a precise specification. It had to speak traditional SFTP end to end, wildcards included, so the application could keep working untouched. It had to hold up under directories of tens of thousands of files and more, without the hardware. And it had to be fully hosted.

The company made Files.com native storage the landing zone.

A Sunday Copy, a Monday Release, and a Regex

The information security manager mirrored the parent company's remote server and its full folder tree into a Files.com native share. Because Files.com serves that storage over standard SFTP, the application's wildcard calls pass straight through. The rewrite never happened. To keep a mirror copy in the company's own Azure environment, the team ran a Files.com Sync outward from the native share to the Azure backend, moving several terabytes.

The cutover itself was built around a feed that could not stop. The team copied the largest directories, the ones holding tens of thousands of files and more, from the parent's file shares into Files.com on a Sunday. After validating the copy, developers released application code on Monday pointing a new service account at the Files.com share over SFTP. The highest-volume 5 percent of client feeds moved first while the rest continued on the parent share, with a delta sync carrying the remainder across while both systems ran in parallel. The daily feed kept flowing throughout.

Then the team restructured the landing zone itself. The inbound files carried their dates embedded in the filenames, so the team used Files.com's Organize Files feature with a regex pattern on those dates to split the flat folders into year/month/date subfolders. A live directory of tens of thousands of files was restructured with a folder setting rather than a script, and new arrivals sort themselves into the same structure as they land.

From 45 Minutes to 2 Minutes

• Folder listings that used to time out now load quickly, and the application's daily processing runs without the timeouts that used to interrupt it.
• The company's own side-by-side measurements: the 400-file zip takes 2 minutes, down from 45 on the legacy server, and the multi-gigabyte download takes 2 minutes, down from 34.
• The portfolio application runs unmodified. The change that moved it shipped as a new service account and a hostname, not a rewrite.
• The application is now decoupled from where its data lives. It talks SFTP to Files.com, and Files.com syncs onward to Azure behind it, so the storage underneath can change again without anyone touching application code.

Fixed at the Source

The company's developers were facing a rewrite of a production financial application before its data could move to the cloud. They never had to do it. Files.com kept the protocol identical and changed everything underneath it, which meant the folder structure could be fixed at the source with the application running unmodified on top.