A Medical Association Rebuilt Its MOVEit Book-Order Relay as Files.com Automations Proven Before Cutover

A medical professional association represents tens of thousands of physician members, and its best-known products are books. Publishing is the association's largest operating department and one of its main revenue drivers, producing books and journals for clinicians in its specialty.

The association does not print, bind, warehouse, or bill for those books itself. External vendors do: the vendor that runs the e-commerce storefront, the printers and fulfillment houses that produce and ship the orders, and the vendor that handles billing. Those companies have no relationship with one another. Every book order has to be relayed between them, and the association sits in the middle as the intermediary they all connect to.

The pipeline that moved the association's publishing revenue ran on a Progress MOVEit automation server and a set of custom scripts, with each job's details recorded in a spreadsheet. The association expected the vendor network to grow, and it wanted every new connection to be a repeatable pattern rather than another script and another spreadsheet row.

The Relay Ran on MOVEit, Scripts, and a Spreadsheet

Around MOVEit sat a pile of custom scripts and scheduler jobs that carried the actual logic: which files to pick up, how to rename them, and where each copy had to go. The details of every job lived in an Excel spreadsheet. The association wanted that logic running on a platform that records every run and shows every job in one place.

None of this was easy to replace. The counterparties are publishing and fulfillment companies, not IT organizations, and some do not control their own transfer endpoints. The association could not dictate the other side of any connection. A replacement had to reproduce the per-job filtering, renaming, scheduling, and archiving exactly, speak the SFTP and FTP those vendors already ran, and ask nothing of them.

The association selected Files.com to be the new hub of the relay.

Every Job Proven Against a Mock Vendor Network Before Cutover

The association did not cut over blind. Its IT team stood up an FTP server on site, with folders mimicking each vendor endpoint, and rebuilt every production job as a Files.com Automation against that mock network: the file renaming, the weekday schedules, and the filtering logic that selects only that day's order files. Every automation was proven working before any business unit or vendor was involved.

The rollout then ran in sequence. Internal divisions were shown the new system first. Then each vendor was given the new source IP addresses to clear through its firewall, since each vendor's access list admits only the addresses it has been told about. Production cutover followed in July 2026.

The automations reproduce the relay exactly. Scheduled Move automations pull order files from the storefront vendor and deliver them downstream to the fulfillment vendors, with confirmations routed onward to billing. Each run applies the required filtering and file naming, while retaining an archive copy so the association has a record whenever a vendor disputes what was sent.

One fulfillment vendor stood up an SFTP endpoint as part of the cutover, and another received its own Files.com account, authenticating with a key.

What Retired With MOVEit

With the Files.com automations in production, the association replaced an automation server, a pile of scripts, and a spreadsheet of job logic with a relay it can see.

• Progress MOVEit and the custom scripts around it are gone. The association confirmed the migration complete in July 2026.
• Every relay job now runs as a logged Files.com Automation. The schedule, the files touched, and the outcome of every run are on the record, instead of in script logic documented in a spreadsheet.
• Vendors changed nothing but a firewall entry. Each one cleared the new source IP addresses and kept its own endpoint and protocol.

The compounding result is what the growth ahead now costs. The association can add another fulfillment connection by repeating an existing pattern—a scheduled automation pointed at a new endpoint—rather than adding another script and another spreadsheet row. The relay that supports book order fulfillment can grow without growing the pile of machinery underneath it.

Proven Before the First Real Order Moved

A legacy MFT relay held together by scripts does not have to be replaced blind. Rebuilt job by job on Files.com and proven against a mock vendor network, it was already working before the first real order file moved, and the next vendor connection starts from a pattern that already runs.