A Healthcare Revenue Cycle Firm Replaced Fortra's GoAnywhere With Files.com and Automated Daily Hospital File Exchange End to End

A healthcare revenue cycle management firm runs an extended business office for hospitals and physician groups. Client hospitals hand over their patient receivables, and the firm works the accounts on their behalf: resolving patient balances, sending statements by program, and managing bad-debt recovery. The company takes only healthcare clients and serves everything from multi-hospital systems to growing practices.

That business model has file exchange built into its foundation. A hospital that outsources its receivables has to send the firm new patient accounts, and the firm has to send results back. Dozens of hospitals and vendors transact with the firm this way, every day, and every one of those files carries protected health information and billing data governed by HIPAA. Some clients run sophisticated IT operations and some do not, and all of them have to be served on the same day, on the same schedule.

A Transfer Platform That Stopped Short of the Processing Server

The firm ran that exchange on GoAnywhere by Fortra. The platform held the client-facing side: per-client folder trees, group configurations, and the transfer workflows for every hospital and vendor. What it did not do was carry a file all the way through. The hop between the transfer platform and the processing server inside the firm's own environment was a separate step, inbound and outbound, for every client, every day. The firm wanted one pipeline that ran from the hospital's folder to the processing server and back with no step in between.

The firm had outgrown that arrangement. The CIO's team wanted end-to-end automation of import and export with configurable per-user security, and the incumbent platform was not delivering it. Leaving was its own problem, in two ways. First, the estate was large and bespoke, with per-client folder structures, dozens of permission groups, and dozens of clients each exchanging four distinct file types, and all of that configuration lived inside GoAnywhere. Second, the processing server sat behind the firm's firewall, and the team did not want to open inbound firewall ports or write and maintain its own scheduled sync scripts just to let a cloud platform reach it.

So the replacement had to do specific things: automate import and export end to end, encrypt the exchange, give each hospital its own scoped credentials over SFTP, reach the internal processing server with no inbound connection from the internet, and be buildable from the estate GoAnywhere already held rather than rebuilt by hand. The firm selected Files.com to replace GoAnywhere as that layer.

Rebuilt by Script From GoAnywhere's Own Export Data

The rebuild started from GoAnywhere's own export data. Using the Files.com CLI, the firm's systems architects generated the groups by script directly from the exported configuration and built the folder structure to mirror the layout hospitals already used, so clients did not have to relearn where anything lived. User accounts were bulk-imported by CSV with group assignments and IP whitelisting already applied, and SSH keys were generated as clients needed them. Every hospital and vendor connects the same way, over SFTP into its own scoped folder, whatever its technical sophistication.

The migration ran from data, not from a rebuild by hand. The old platform's export became the new platform's build input.

An Outbound-Only Path to the Processing Server Behind the Firewall

To connect the client-facing side to the processing side, the firm installed the Files.com Agent inside its own environment. The Agent made an outbound-only, encrypted connection to Files.com, so the processing server was never exposed to the internet and no inbound firewall port was opened. Through that connection, dozens of one-way sync behaviors were configured to carry files in both directions: a hospital's upload synced from its Files.com folder into the processing system, and processed deliverables synced back out to the client's folder for pickup.

On top of the pipeline, the firm built hundreds of Files.com Automations, some moving outbound deliverables and the rest filing inbound documents. Each one matched filename patterns that identified the client and the file type, so originals, completed work, and rejected records would all land in per-client archive folders on their own.

The cutover was deliberate. Every sync and automation was created in a disabled state and enabled selectively, starting with smaller clients. Before the switch, the team verified the migration independently in FileZilla: file counts and total size matched exactly between GoAnywhere and Files.com. The move was proven, not assumed.

Daily Transfers With Dozens of Hospitals Now Run End to End on Their Own

With the Files.com pipeline in production, the firm retired GoAnywhere and replaced a daily workflow that stopped at the transfer platform with one that runs end to end on its own.

• Daily business-to-business file transfer with dozens of hospitals and vendors runs on Files.com, and GoAnywhere is gone.
• Every client file completes its round trip with no step in between. Uploads sync into the processing system, deliverables sync back to each client's folder, and the archive automations file matching documents by client and type.
• PHI travels one encrypted, credentialed path from the hospital's folder to the processor and back, and the automations carry it the whole way.
• Onboarding the next hospital is a script run, not a build. The per-client pattern of folders, group, users, syncs, and pattern-matched automations is generated the same way the original groups were, so each new client is incremental volume on a design that already exists.

A Legacy MFT Estate Rebuilt Without a Leap of Faith

The way the firm got there is the part worth carrying away: a legacy MFT estate with hundreds of per-client workflows did not have to be untangled by hand or cut over on a leap of faith. GoAnywhere's own export data became the input to the Files.com build, the workflows went live one client at a time, and the numbers were checked before anything switched.