Files.com Let Archway Retire Microsoft Windows File Shares Without Rewriting Its 100,000-File-a-Day Application

Archway builds and operates the general ledger for some of the wealthiest families in the world. Its platform handles the complex partnership and portfolio accounting behind family offices, private banks, wealth advisors, and private funds, with more than $850 billion in assets on the platform, including ten of America's 25 wealthiest families.

What makes that ledger work is data ingestion. The platform pulls structured financial files from nearly 200 sources: 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 Archway'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, 100,000 Files a Day, and a Terabyte of RAM

For most of its history, Archway 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 Windows file shares, and roughly 100,000 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 its daily 100,000 files, it ran into timeouts and performance hiccups. The parent's answer was hardware. As Archway Information Security Manager Armando Cabrera describes it, the FTP servers had a terabyte of RAM and sat physically next to the servers that processed the files. The operational cost of a bad folder structure was masked by throwing hardware at it.

Cabrera measured what that estate actually cost. Zipping 400 files on the legacy remote server took 45 minutes. Downloading a single 3 GB file took 34 minutes. Those were not outage numbers. They were the ordinary speed of the system the business ran on.

Then the masking option went away. In June 2025, a private equity carve-out separated Archway from its former parent, SEI, and the parent's infrastructure was not coming along. The landing zone and the daily feed that filled it had to move to something Archway owned, and the hardware that had been hiding the flat-folder problem would not exist on the other side.

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. Mid-migration, that plan collapsed. Archway's portfolio application discovers its files through a third-party SFTP library that issues wildcard-based find and send calls. Object storage REST APIs drop wildcards. Pointing the application at Azure would have meant an emergency rewrite of a production financial application, in the middle of a divestiture 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 100,000 files and more, without the hardware. And it had to be fully hosted. CTO Dan Berg was blunt about that last requirement:

“I don't want to know about servers here. I want people to log in securely and do their thing in SaaS.”

Archway made Files.com native storage the landing zone.

A Sunday Copy, a Monday Release, and a Regex

Cabrera 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 Archway's own Azure environment, he ran a Files.com Sync outward from the native share to the Azure backend, moving roughly 4 terabytes.

“We created a sync from Files.com to that remote backend and let that run. That saved us.”

The cutover itself was built around a feed that could not stop. Cabrera copied the largest directories, the ones holding 100,000 files and more, from the parent's Windows 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 100,000 files kept flowing throughout.

Then Cabrera fixed the structure itself, the thing the hardware had been compensating for all along. The inbound files carried their dates embedded in the filenames, so he 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 more than 100,000 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 of 100,000 files runs without the timeouts that used to interrupt it.
• Cabrera's own side-by-side measurements: the 400-file zip takes 2 minutes, down from 45 on the legacy server, and the 3 GB 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, Not Re-Masked

Archway's developers were facing an emergency 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 a performance problem that had been masked with hardware on premises could finally be fixed at the source instead of re-masked in the cloud.