A Regional Insurance Group Replaced Progress WS_FTP Pro and OpenSSH Without Rewriting ACH Processing

A regional insurance group writes property, casualty, and life coverage through a network of independent agents.

An insurance group of that shape runs on files that have to arrive: policy reports for leadership, enrollment files from brokers, and the ACH settlement files that move money between the group and its bank. For years, the group moved all of it on file transfer infrastructure it built and ran itself. The group set out to retire three hand-programmed SFTP servers without rewriting the SQL-based ACH processing behind them: Files.com would take over the movement around that logic.

Three SFTP Servers, Every Schedule Programmed by Hand

That infrastructure was three on-premise SFTP servers. Two ran Progress WS_FTP Pro and transferred files directly to remote servers controlled by the group's bank. The third was a Windows server running OpenSSH, tied to the group's policy system. Every schedule and every transfer interval on that software had to be programmed by hand.

The cost landed at the worst possible moments. When a file needed to go out in a hurry, the person who needed it sent could not send it. It went through IT first.

Recurring distribution had the opposite failure: nothing moved unless a person remembered. End-of-month reports went out when someone thought to send them, and a forgotten report delayed everyone downstream who was waiting on it. The most critical path of all, ACH delivery, ran through SQL Server pushing files to the bank's FTP site, with manual steps sitting in the middle of a workflow that moves money.

Bank Files Nobody Could Afford to Break

The estate survived because the work running on it was exactly the work nobody wants to disturb. ACH files are bank transactions, and each delivery has to arrive on schedule, date-stamped, with a notification email carrying the file's details. The transfer logic was also interwoven with processing that lives in SQL Server — date and time stamping, XML-to-CSV conversion, error reporting — owned by the group's database administrator rather than a dedicated integration team. Rewriting all of that to fix a transport problem would have put bank processes at risk.

So the replacement had a specification before it had a name. It had to run scheduled transfers that are declared once, not programmed by hand. It had to reach the internal database server without exposing that server to the internet. And on anything touching bank transactions, it had to run alongside the existing process until the new path was proven.

The group selected Files.com to be that platform.

An Agent on the Database Server, Not a Rewrite

The design had one thesis: Files.com carried the transport, the scheduling, and the delivery, and the business logic never left SQL Server.

Decommissioning ran lowest-risk first. The Windows OpenSSH server, carrying only a trickle of files, went before the two Progress WS_FTP Pro servers that fed the bank.

The ACH workflow showed the shape of the rebuild. The finance team dropped ACH files into Files.com. A Files.com Agent installed on the group's internal Windows database server, connecting outbound only with no inbound firewall change, synced those files to SQL Server, where the existing logic applied the date and time stamp. The stamped files returned through Files.com and were delivered to the bank over SFTP, with an email notification carrying the file details. While the Files.com path was tested, the legacy SQL-driven delivery kept running in parallel: the group's standing rule for anything touching bank transactions.

The same Agent-plus-SQL pattern carried a vendor data pipeline, automatically decrypting PGP-encrypted files, converting XML to CSV in SQL, returning the converted files and error reports to Files.com, and expiring decrypted source files after a set period.

ACH Delivery That Runs Itself

With the Files.com workflows in production, the group replaced hand-programmed transfer servers and memory-dependent distribution with syncs that run themselves.

• ACH files reach the bank on schedule, date-stamped, with the notification email sent automatically and no manual steps left in the path.
• Recurring reports push automatically, internally and externally, so a distribution no longer waits on someone remembering to send it.
• Sync configuration is declared in Files.com rather than programmed on a server. After building the first bank sync, the group's database administrator found standing up the next ones straightforward.

The Transport Changed, Not the Business Logic

Today, a bank file's trip starts when the finance team drops it into Files.com, and no one touches it again before it reaches the bank. A transfer that used to open with a request to IT, at exactly the moment speed mattered most, now runs because a schedule says it does.

The group did not rebuild its financial processing to get there. The SQL logic that stamps and converts its bank files runs where it always ran. Files.com replaced the servers underneath it and the hand-programming around it, one workload at a time, with the bank-critical path run in parallel until it had earned trust. The servers that had to be programmed are gone. The logic they served never had to move.