Files.com Let Archway Retire Microsoft Windows File Shares Without Rewriting Its 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 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, Tens of Thousands of 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 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 parent's answer was hardware. 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.

Archway'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 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 tens of thousands of files and more, without the hardware. And it had to be fully hosted.

Archway made Files.com native storage the landing zone.

A Sunday Copy, a Monday Release, and a Regex

Archway's 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 Archway'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 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 feed kept flowing throughout.

Then the team 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 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.
• Archway'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, 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.