A Global Investment Bank Moves 15 Years of GlobalScape EFT File Flows to Files.com Without a Rebuild

A global investment bank provides M&A, restructuring, and capital markets advisory to corporations, governments, and financial sponsors worldwide.

Like every firm, it runs an ordinary corporate back office: Workday on the HR and payroll side, Salesforce on the client side, outside providers around them. Those systems exchange data with each other and with the outside world as files. For roughly fifteen years, an on-premises GlobalScape EFT server carried that traffic.

GlobalScape Changed Its Licensing Model

GlobalScape changed its licensing model, and the bank took that as its moment to move off a server the firm had run on-premises for roughly fifteen years.

The move was not a side project. The server carried the firm's automated file-transfer estate: the production flows moving files between outside providers and the systems that run the firm, across finance, payroll, HR and CRM. That is sensitive HR, finance, and client data, and the bank wanted it on one governed path, encrypted where the data demands it, on a platform delivered as a service rather than a server the firm has to keep alive.

Fifteen Years of Flows With No Appetite for a Rebuild

The server had lasted that long because the work around it had grown into its shape. It was originally bought to move files for an in-house financial system that was retired years ago, and it kept accreting workloads as finance, payroll and HR systems came and went.

The integrations around it had a specific shape. Salesforce has no native SFTP, so an ETL tool called Scribe sits in the path, reaching into Salesforce, extracting records and building the flat file that moves, or the reverse for files Workday produces. Each system produces flat files by design. The bank had no interest in re-architecting all of that just to change the server it happened to run on.

So the replacement had a precise job. Reproduce the existing flows exactly: scheduled SFTP against service accounts, GPG encryption on the sensitive flows, files staged for Workday pickup, archiving along the way. Leave Scribe and the flat files where they are. Keep encryption under the security team's control. And clear the network and firewall review an investment bank runs before anything touches its DMZ. The bank selected Files.com to take that workload over.

A Lift-and-Shift Onto Files.com, Proven Flow by Flow

The migration was deliberately conservative. Phase 1 reproduced each GlobalScape flow on Files.com, proved it against internally defined success criteria, and then cut it to production. Files.com became the managed transfer layer the old server had been, without asking anything around it to change.

A Files.com Agent runs in the bank's DMZ and connects outbound only, to dedicated Files.com IPs. No inbound firewall rule exists, and nothing inside the network accepts connections from the internet. That architecture is what cleared the firm's network and firewall validation. The platform runs under the bank's own branded domain, on dedicated IPs the firm's firewall rules can pin to.

The flows themselves kept their old shape and controls. Where Files.com connects directly to Salesforce, its connector runs a scheduled delta check for changed records. Scribe remains the ETL layer in the existing Salesforce-Workday path, building and consuming flat files, while Files.com handles their secure movement. Scheduled SFTP connections use service accounts, and Files.com encrypts and decrypts sensitive flows with GPG, stages files for Workday pickup, and lands them in storage the bank owns.

In Production With Nothing Rebuilt Around It

With the flows proven and cut over, the bank retired the GlobalScape server. Its full automated file-transfer footprint now runs on Files.com.

• All production flows between outside providers, Salesforce, Workday and Scribe run on Files.com, GPG-encrypted where the data demands it, landing in storage the firm owns.
• No person handles a file in transit. Every flow runs on systems and service accounts, on a platform delivered as a service rather than a server the firm has to keep alive.
• The deployment passed the firm's network and firewall validation without opening a single inbound port.
• The integration design did not change. The flat files, the ETL layer and the storage all work exactly as they did. Only the platform underneath them is new.

The handoff was designed in from the start: business technology configured the platform, and IT operations now runs and monitors it day to day.

The Way Out Was Not a Re-Architecture

The standard assumption about a fifteen-year-old MFT server is that leaving it means modernizing everything around it first: build the APIs, replace the ETL tool, restructure the storage, then migrate. The bank did the opposite. It moved the server's job to Files.com, flow by flow, and left the integrations alone.

The difference shows in what the firm no longer runs. Today the sensitive HR, finance, and client data that used to depend on an on-premises server moves through Files.com as a service, and nobody at the bank maintains that server, because there isn't one. Fifteen years of accumulated file flows did not need to be rebuilt to leave that server behind. They needed a platform that could reproduce them exactly, and Files.com did.