Valiant Capital Partners Retires MOVEit and Its Last On-Prem Server With Files.com

Valiant Capital Partners is a San Francisco investment manager running a global long/short equity book and a private growth equity strategy. The firm has traded for 18 years and operates around the clock across Asia-Pacific, Europe, and India.

That business runs on counterparty files. Every hour, the systems built by CTO David Grayson deliver P&L to the CEO and the investment team, and every one of those reports starts as files pulled from roughly 15 financial institutions. The files arrive in morning and evening cycles plus continuous intraday collection, and 18 years of in-house ETL converts them into the SQL tables the reporting stands on.

All of that now lives in Azure, where Valiant moved its business systems. Except one piece. The transfer layer that fed everything ran on an on-premises MOVEit server, the last on-prem box the firm had.

One Server, One Operator, and 18 Years of Automation Behind It

Grayson has been Valiant's one-person development function since the firm started. He built the ETL, the reporting, and the transfer layer under it, and for 18 years that layer ran on tools from the same vendor: WS_FTP LE first, then MOVEit. The server was administered and patched by hand, and its single-server design meant that in practice only one person could operate it.

That mattered because everything downstream assumed the transfer layer was perfect. Twenty-two automated processes ran every day, about 18 of them calling data from external providers. If the files did not arrive, the automation did not run, and the hourly P&L behind it did not go out. One person carried the uptime of the layer the whole firm's reporting stood on.

Retrieval was the other cost. MOVEit pulled indiscriminately: thousands of files landed from a broker directory when only a few dozen mattered, and the filtering happened afterwards, in SSIS loops, stored procedures, and scripts on a local machine.

“I only want to bring in these 30. I know what they are. I know the file pattern.”

The setup survived for the same reason it was dangerous. A service this critical had to stay dialed in, so Grayson kept it under his own control, and for years one operator was enough. Any replacement also faced a hard constraint: 18 years of downstream ETL expected files to arrive exactly as they always had. Swapping the transfer layer could not mean touching what stood behind it.

Three Users, One Server, and an Azure Migration One Box From Done

Two things stopped being true. The team grew: three to four administrators and developers now needed to work in the same platform, and a single-operator server could not hold them. And the firm's cloud program ran out of road. Every other system had moved to Azure, leaving the MOVEit box as the one server Valiant still had to keep alive on-premises.

Whatever replaced it had to reproduce production one for one. That meant preserving SFTP connections with SSH key pairs and IP whitelisting for every counterparty, decrypting PGP-encrypted and zipped feeds in flight, and delivering each file into Azure exactly as the existing ETL expected. It also had to fix the two things the old server never did: let several people work at once, and pull only the files that mattered.

Valiant selected Files.com to be that transfer and orchestration layer.

Watching Broker Directories and Landing Files Straight Into Azure

Files.com became the managed layer between Valiant's counterparties and its Azure estate. It watches broker directories, takes only the files that matter, decrypts them in flight, and lands them where the existing automation already looks.

Each institution connects over SFTP using SSH keys, while dedicated public IP addresses satisfy counterparty whitelisting. Files.com Remote Server Mounts watch JP Morgan and Morgan Stanley directories for new files, and Automations use wildcard patterns and date filters to decide what moves. Out of a broker directory holding thousands of files, the pull takes the roughly 30 Valiant needs, selected at the point of transfer instead of filtered afterwards.

Morgan Stanley's feeds arrive zipped and PGP-encrypted, and Files.com decrypts and unzips them inline inside the same workflow. Each pull then writes to two destinations in a single Automation: a Files.com folder and Azure Blob Storage. The file lands where Grayson's existing Azure loop picks it up without being downloaded twice.

Mimic Production First, One Workflow at a Time

Grayson ran the migration himself and set one rule: reproduce production first, improve later. Some broker endpoints stop showing a file once it has been picked up, so running the old and new systems fully in parallel was never an option. He moved one workflow, ran it until it behaved exactly like production, then migrated the rest the same way. When the last workflow cut over, the processes on the MOVEit server were shut down, and the server with them.

The Last On-Prem Server Is Off

With the workflows on Files.com and the MOVEit box off, Valiant replaced a hand-patched, single-operator transfer server with a managed layer the whole team works in.

• The firm's last on-premises server is retired. The Azure migration that had stalled at the transfer layer is complete, and nobody administers or patches a transfer box by hand.
• Twenty-two critical automated processes run on Files.com daily across 15 financial institutions, feeding the pipeline behind hourly P&L. The 18 years of ETL downstream did not change.
• Selective retrieval ended the sea of files. A broker directory of thousands becomes about 30 targeted files, and the local SSIS loops and scripts that used to filter the flood are out of the intake path.
• The transfer layer is no longer single-operator. Three to four administrators and developers work in the platform at once, so the service every report depends on no longer lives or dies with one person.

The move also produced something the old stack never offered. Files.com's automatic organization by date lets Grayson file and query historical broker data by the year each file was created.

A Layer That No Longer Depends on One Person

And none of the 18 years of automation behind it had to be rebuilt. The last on-prem server never needed a rewrite of what stood on top of it. It needed a transfer layer that could reproduce production one workflow at a time, and then it could be turned off.