A Senior Living Operator Replaced Fortra's GoAnywhere With Files.com—Without Moving Its On-Premise Backend

A North American senior living operator manages dozens of retirement residences delivering everything from independent living to memory care. An operation that is distributed runs on data. Workforce scheduling lives in Kronos, HR in Workday, property management in Yardi, resident surveys in Qualtrics, dining in Maitre'D, and those systems exchange files with the operator's internal accounting, business intelligence, and operations platforms on a constant schedule. Almost none of that exchange involves a person. It is machines writing files for other machines to collect, thousands of times a day.

For years, the infrastructure carrying that exchange was the operator's own. To hand that layer to a vendor without moving its on-premise processing or making partners change their connections, the operator moved only the internet-facing front door to Files.com.

A Transfer Layer the Operator Ran Itself

The operator hosted its own SFTP and FTP server in its data centre, and ran GoAnywhere alongside it. Every software feed and every external partner connected to servers the company owned and operated. That meant the IT team was running infrastructure whose only job was moving files: patching it, monitoring it, and keeping it available. Each new data feed was one more connection for that team to carry.

The problem was not that file transfer worked badly. It was that the operator wanted the internet-facing half of file transfer operated by a vendor, and the work of running it in-house grew with every integration the business added.

A Live Estate, and a Backend That Could Not Move

The transfer layer was production plumbing, not idle infrastructure. More than a dozen integrations ran in production, with separate read and write processes for each, and external partners had the operator's endpoints embedded in their own scripts and firewall rules. The estate was also split: an operation the company had acquired already ran its file exchange on Files.com, while the in-house server carried everything else, so administration was duplicated across two systems doing one job.

The obvious answer, moving everything to the cloud, was not available. Files had to keep landing on the operator's internal infrastructure, because accounting, business intelligence, and operations processing all ran there. And some partners connected with older SFTP and FTP clients that the replacement had to keep supporting.

So the replacement had a specific shape. It had to present the same endpoints partners already used, so nobody outside the company had to reconnect. It had to speak SFTP and FTP exactly as those partners' clients spoke them. It had to pass files through to on-premise processing rather than strand them in a new silo. And it had to be infrastructure somebody else operates and defends. The operator selected Files.com as that external-facing layer, consolidating the in-house server's workloads into the existing Files.com site used by the acquired operation and displacing GoAnywhere in the process.

The Old DNS Names Now Point at Files.com

The consolidation was designed so that partners would never notice it. The operator redirected its existing DNS entries to Files.com, so every partner and every automated feed kept connecting to the same names it always had. Behind those names, the endpoint answering was now Files.com rather than a server in the operator's data centre. The site runs under the operator's own branded domain, so nothing about the exchange looks like a third party to the systems and partners on the other end.

Files.com's broad SFTP and FTP client compatibility kept the older partner clients connecting without forcing anyone through an upgrade, and IP whitelisting restricts where automated accounts can connect from. Permissions got simpler in the move: where GoAnywhere required virtual-folder configuration to map what each connection could see, on Files.com folder permissions attach directly to user privileges, so each system account is granted exactly the folders its jobs read and write.

The architecture is deliberately a transit layer. Feeds from Qualtrics, Kronos, Workday, Yardi, Maitre'D, and external partners land on Files.com, and the operator's internal processes collect them down to on-premise systems for accounting, BI, and operations work. The processing never moved, and the systems doing it never face the internet.

Nothing Public-Facing Left to Defend

With the consolidation done, the operator replaced a public-facing transfer estate it had to patch and defend with a hosted exchange layer it merely uses.

• The in-house SFTP and FTP server is retired, and with it the work of running internet-facing infrastructure the operator owns.
• GoAnywhere is gone. One platform now does what a data-centre server and a commercial MFT product did between them, with one set of accounts and permissions to administer instead of two.
• The exchange hub runs unattended. Nearly every account on the site is a system account, not a person, and the platform carries thousands of automated transactions a day with nobody in the path.

The Perimeter Moved and the Processing Stayed

Today, when a partner or a software vendor sends the operator a file, it arrives on Files.com under the operator's own branded name, and an internal system collects it from behind the perimeter. That same connection used to terminate on a server in the operator's own data centre, one the IT team had to patch, monitor, and defend for as long as the feed existed.

What is notable is what the operator did not have to do to get there. Accounting, BI, and operations still run exactly where they ran, on infrastructure that never left the building. Handing off the internet-facing layer did not require migrating the backend. It required moving the front door, and only the front door. The internet-facing half of file transfer went to Files.com, the old DNS names followed it, and neither the partners outside the company nor the systems inside it had to change a thing.