Archway Put Files.com in Front of Its Former Parent’s SFTP Server to Move 250 Partners

Archway Group runs the accounting platform behind some of the most complex private wealth in America. Its general ledger platform supports more than $850 billion in assets for 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 Archway does not control. File transfer is not a back-office chore at Archway. It is the front door of the product.

For most of Archway’s history, that front door belonged to somebody else. Archway operated for years inside SEI, its former parent. At the end of June 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.

250 Trading Partners, All Pointed at a Server Archway Was Leaving

Everything file-related ran inside the parent’s environment. Roughly 250 trading partners delivered files to the parent’s shared SFTP server: banks, credit unions, custodians and counterparties, each with individual credentials, while Archway’s platform collected the files from that same server for ingestion. Archway itself had no managed file transfer tooling, no dedicated IP address, and no file transfer domain of its own. Under the transition agreement that came with the carve-out, it had roughly twelve months to get out.

Archway’s problem was never standing up a replacement server. It was moving a partner network that resisted change, on a deadline, off infrastructure it did not control. Financial institutions whitelist by IP address, so every one of those 250 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 Archway’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 parent’s side couldn’t support one either. Its environment offered no sync tooling beyond Robocopy, and any change to its infrastructure went through a process of 60 to 120 days. A migration plan that depended on coordinated work inside the parent’s environment would spend the transition clock waiting on tickets.

That constraint set the requirements. Archway 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.

Archway 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.

“Your platform stood out because we could have a static IP. It was fully hosted, so we don’t have to manage DR.”

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.

Archway 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 Archway’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, which meant nothing had to wait 60 to 120 days.

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

The final step never involved the partners at all. When Archway 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 Archway’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, Archway had moved its roughly 250 trading partners and shut down the last connections to the former parent’s server within its twelve-month transition window, while the data flows feeding its ledger ran uninterrupted. The shared server Archway did not control had been replaced by a managed file transfer environment under its control.

• A major audit fell during the migration period. Archway passed it.
• Onboarding the next trading partner is now Archway’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 Archway does not have to patch file servers or manage their disaster recovery.

“I don’t want to know about servers here.”

A Front Door Archway Owns

Before the migration, every partner connection Archway had was an arrangement running through a company it was leaving, and changing any part of it meant a ticket into another organization’s change process measured in months. Today, when a custodian whitelists an IP to send Archway a feed, it whitelists Archway’s. When a credential needs rotating or a folder needs restructuring, Archway 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 Archway was ready.