Skip to main content

Bates White Retires Fortra's Globalscape EFT Without Moving Client Case Data to the Cloud

Files.com gave external clients a modern SFTP endpoint while the Agent kept sensitive datasets on Bates White's servers and within LAN-speed reach of its analysts.
Bates WhiteFiles.com

Bates White is an economic consulting firm headquartered in Washington, DC. Its economists provide analysis and expert testimony in antitrust, mass torts, energy, finance, and healthcare matters for law firms, Fortune 500 companies, and government agencies.

That work runs on client data. Engagements begin when a law firm, a company, or an agency sends Bates White the case data its economists will analyze, and the datasets are large: commonly 100 GB to 1 TB, with individual transfers reaching a couple hundred gigabytes. The data is also exactly the kind clients guard most closely. It can contain PHI or PII, and a portion of Bates White's clients refuse cloud file sharing outright. Whatever system receives those files, the files themselves have to land on Bates White's own storage.

A Legacy Server the Clients' Rules Kept Alive

For years, the answer was an on-premise Globalscape EFT server: a single machine in the firm's DMZ, answering SFTP on port 22, where external clients connected with FileZilla to drop and collect engagement data. Behind it sat a Windows file server holding the FTP-access folders.

The server did the job, and it taxed the firm for it. It was an internet-facing legacy server Bates White had to patch and keep alive because client data had nowhere else to arrive.

The obvious fix was off the table. A cloud file-sharing service is precisely what some of the firm's clients refuse. The constraint was not Bates White's to negotiate; it belonged to the clients. So the server stayed.

A Cloud Front End for Files That Never Leave the Building

A replacement had to do something unusual: behave like a managed cloud service to the people connecting from outside, and behave like the firm's own storage to everyone else. Clients needed a maintained, modern endpoint to send files to. The files had to land on Bates White's servers and stay there. Because the data can contain PHI or PII, a HIPAA Business Associate Agreement sat on the critical path. And internal staff, who run analyses against datasets that reach a terabyte, had to keep local-network speed to the data.

Bates White selected Files.com to be that front end, with the Files.com Agent keeping every file on the firm's own servers. Files.com executed a HIPAA Business Associate Agreement covering the PHI exposure.

This is why we chose you guys initially, because you offered this kind of proxy, the agent, where you guys can be the front end, but the data still in the end resides on our servers.
Manny Torres, Director, Infrastructure & Operations, Bates White

Replicate the Old Structure, Test It, Flip Once

The migration was built to be invisible. The team recreated the existing FTP folder structure inside Files.com, so the new site matched the old one path for path. Two on-premise servers were connected through the Files.com Agent, which runs inside the firm's network and makes only outbound connections: no inbound firewall rule, and no new machine in the DMZ. Folders on those servers were mounted into Files.com, so a file a client uploaded through Files.com passed straight through to Bates White's storage.

After testing the path with large files, the team migrated the legacy data and recreated each client account against its folder. The site runs under Bates White's own custom domain and branding, and the legacy FTP hostname was pointed at it, so a client's saved connection details kept working.

Internal staff never touch the new front end at all. They pick up received data over the same direct local share as before, at LAN speed, which is what makes hundred-gigabyte case data workable.

The ability for our end users to connect just to a share that we have here, and then the external people come in through Files.com, allows us to keep that local transfer for our internal users, but then it eases the access for the external folks.
Matthew Keaton, Senior Network Engineer, Bates White

Cutover was a single flip day. External clients and internal staff were notified to switch, and the help desk was trained on the new provisioning procedure before day one. The approach throughout: replicate the existing model first, evolve the processes after.

Globalscape Retired, Data Still at Home

With the cutover complete, Bates White retired the Globalscape server. Files.com is now the only way client SFTP transfers reach the firm.

The internet-facing legacy server is gone, and with it the patching and upkeep of a machine the firm ran only because its clients' rules demanded it. The clients who refuse cloud file sharing noticed nothing: they connect over the same protocol they always used, and every file they send still lands on Bates White's own storage.

The setup also gives each new engagement more flexibility. The old setup centered on one protocol, and every client requirement had to fit it. With Files.com, Bates White can choose SFTP, FTP, or a web interface when an engagement demands it, all against the same folders and the same storage.

Serving the Strictest Clients Without Running a Server

What changed at Bates White is who runs the machinery behind its clients' strictest requirement. The requirement itself still holds: some clients will not allow their case data in cloud storage, and every file still lands on the firm's own servers. What no longer holds is the price of honoring it. When a client sends case data today, it arrives through Files.com under Bates White's own domain and passes straight onto the firm's storage, and nobody at the firm maintains an internet-facing transfer server to make that happen.

For a firm whose clients say no to the cloud, that turned out to be the whole answer: the transfer layer and the storage were never the same thing, and only one of them needed to be theirs.

The front end moved to Files.com. The files did not move at all.