An Investment Manager Retires MOVEit and Its Last On-Prem Server With Files.com

A US investment manager runs global equity strategies across public and private markets. The firm has traded for nearly two decades and operates around the clock across Asia-Pacific, Europe, and India.

That business runs on counterparty files. Every hour, the systems built by the firm's CTO deliver P&L to the CEO and the investment team, and every one of those reports starts as files pulled from more than a dozen financial institutions. The files arrive in morning and evening cycles plus continuous intraday collection, and nearly two decades of in-house ETL converts them into the SQL tables the reporting stands on.

All of that now lives in Azure, where the firm 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 With Two Decades of Automation Behind It

The CTO has built the firm's systems since it started: the ETL, the reporting, and the transfer layer under it. For nearly two decades that layer ran on tools from the same vendor, WS_FTP LE first, then MOVEit, on a server designed around hand operation.

That mattered because everything downstream assumed the transfer layer was perfect. A couple dozen automated processes ran every day, most 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. The firm wanted that layer on a platform several people could operate and watch.

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.

The setup lasted because it worked. A service this critical had to stay dialed in, and for years a hand-operated design was enough. Any replacement faced a hard constraint: nearly two decades of downstream ETL expected files to arrive exactly as they always had. Swapping the transfer layer could not mean touching what stood behind it.

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

Two things stopped being true. The team grew: several administrators and developers now needed to work in the same platform, and the old server had no room for 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 the firm 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.

The firm 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 the firm'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 the firm's prime-broker 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 few dozen the firm needs, selected at the point of transfer instead of filtered afterwards.

One broker'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 the existing Azure loop picks it up without being downloaded twice.

Mimic Production First, One Workflow at a Time

The CTO 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, the firm replaced its last on-premises 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 there is no transfer box left to administer.
• Critical automated processes run on Files.com daily across the firm's financial institutions, feeding the pipeline behind hourly P&L. The two decades of ETL downstream did not change.
• Selective retrieval ended the sea of files. A broker directory of thousands becomes a few dozen 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 open to the whole team. Several administrators and developers work in the platform at once, so the service every report depends on has a full team working in it.

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

A Layer the Whole Team Runs

And none of the two decades 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.