Enginetech Replaced HostedFTP.com and Stopped Losing Order Files Without Replacing Prelude UniData

Enginetech has supplied professional engine rebuilders since 1982. From its headquarters in the Dallas–Fort Worth area, the company manufactures, imports, and distributes internal engine parts: pistons, gaskets, bearings, timing sets, camshafts, and complete engine kits, a catalog of more than 15,000 SKUs it describes as the most extensive offering in the internal engine parts market. Its parts reach the trade two ways. Independent rebuilder shops order directly, and national retail chains and e-commerce marketplaces carry the brand and transmit their orders electronically.

That second channel is where the volume comes from, and every order in it arrives as a file. Those files feed Enginetech's system of record: a Prelude ERP built on UniData, running on-premises on an aging Red Hat Linux build and supported through its vendor. The ERP processes each order and prints pick tickets in the warehouse, where pickers pull the parts and ship them.

Between the trading partners on one side and the ERP on the other, Enginetech's entire order flow is file transfer. It supports seven distribution centers across the United States, and it is run by an internal IT team of two.

An Order Channel With No Memory

When an order failed to process, Enginetech had nothing to go back to. The order channel had no memory: every file that carried an order existed only until the ERP consumed it.

The files moved through a HostedFTP.com site. Trading partners delivered order files there, and on the on-premises Linux server, a custom retrieval script for each partner polled the site every 15 to 20 minutes, pulled down whatever had arrived, and handed it to the ERP. Once the ERP processed a file, the file was deleted. Nothing was retained on the FTP site, and nothing was retained on the server. All that remained of any order file was its filename in a report.

The cost of that showed up wherever anything went wrong. In one incident, files left the FTP site but never reached the Linux server, and 15 to 20 orders were simply gone, with nothing left to re-run. Any network or power outage on the on-premises side meant manually discovering and reprocessing whatever had been in flight. And when files piled up faster than the ERP worked through them, the backlog itself slowed the system and put the whole operation behind. An order file that vanishes is a pick ticket that never prints, a part that never ships, and a reseller's customer left waiting.

The ERP Couldn't Change, and the FTP Site Couldn't Help

The obvious fix was not available. The ERP is the system of record for orders, inventory, and invoicing. It runs on a Linux build old enough to make moving it difficult, and Enginetech depends on the vendor for its support and customization. Whatever fixed the order pipeline could not be a modernization of the backend.

The FTP site could not carry the fix either. It received files and held them until a script came for them, and that was the whole of what it did. It had no sync capability, no automation, and no way to keep a copy of anything, so every improvement had to be scripted around it on the Linux server, adding to the pile of per-partner scripts the two-person team already maintained. Each new trading partner meant another script to write and another feed with no safety net. What had started as a workaround had become the entire order channel.

Replacing it carried its own risk. Every live partner feed pointed at the old hostname, so a botched cutover was itself lost orders.

That set the requirements. The replacement had to speak the protocols the partners already used, including AS2 for the retailers that required it. It had to keep a recoverable copy of every order file and hold inbound transmissions when the on-premises server was down. It had to reach the ERP's server without exposing it, and without any change to the ERP itself. And it had to come live one partner at a time, with the old site still running underneath.

Enginetech selected Files.com to be that layer.

Files.com Between Every Trading Partner and the ERP

Files.com became the store-and-forward hub for Enginetech's order traffic: the one point every file passes through on its way between a trading partner and the ERP, with the ERP unchanged behind it.

On the intake side, each trading partner has its own account and folder at Enginetech's own domain, with folder-level permissions that keep every partner inside its own space. Retail chains and marketplaces connect over SFTP, FTP, or AS2. Partners install nothing and see nothing beyond their own folder.

On the ERP side, a Files.com Agent runs inside Enginetech's network and connects outbound only, so nothing on-premises is exposed to the internet. Files.com syncs push each arriving order file into the folder the ERP's scheduler already polls on its 15-minute cadence. The per-partner retrieval scripts were retired, and the ERP kept its existing jobs, repointed at the new source. That repointing was the entire backend change, a couple of hours of configuration by Enginetech's external ERP consultant.

Recoverability comes from a Files.com Automation. The moment an order file is created, the automation copies it into a safety-copy folder, and a second Agent carries that stream down to the Veeam backup VM. Retention on the safety-copy folder expires each file after four days, long enough to catch and re-run anything that failed, and the archive cleans itself up with no one touching it. Three copies of every order file now exist from the moment it arrives: the live Files.com folder, the ERP server, and the backup.

The outage protection required no configuration at all. If the on-premises server is unreachable, inbound files simply hold on Files.com, and when the Agent reconnects, the sync delivers everything that accumulated.

A Month in Parallel, One Partner at a Time

Enginetech synced the old site's contents into Files.com over a remote server connection, recreated the active partner accounts with SFTP credentials and folder permissions, and then ran both platforms live in parallel for roughly a month while every workflow was validated. Partners cut over one at a time, beginning with a major reseller, with a few days of monitoring between each, and the ERP ran dual jobs against both sources until the last feed moved. No partner feed dropped during the cutover.

A Failed Order Is Now a Lookup, Not a Loss

With Files.com in production, Enginetech replaced an order channel that forgot every file it carried with one that keeps three copies of each and holds traffic through outages.

• A failed or mis-processed order is found and re-run, not reconstructed. The file itself is retrievable from the safety copy for four days, where the old pipeline left nothing but a filename in a report.
• An outage on the on-premises side no longer loses transmissions. Inbound files wait on Files.com and deliver themselves when the server returns, replacing the manual hunt for whatever had been in flight.
• Every partner feed came across the migration intact, and files have arrived and routed as expected since, with safety copies landing as configured.

The compounding result is what each new partner costs. Bringing on another trading partner used to mean writing and maintaining another retrieval script feeding another unrecoverable stream. Now it is an account, a folder, and a credential over SFTP, FTP, or AS2, and the safety-copy automation and ERP sync apply from the first file. The pattern that fixed the existing feeds is the pattern every future feed rides.

Resilience Without a Modernization Project

Today, Files.com is Enginetech's customer-facing order channel. The accounts on the site belong overwhelmingly to trading partners and customers rather than staff, because the platform is where the business meets the companies that buy from it.

Enginetech got all of it without touching the system that could not be touched. The UniData ERP still runs the same 15-minute jobs against the same folder it always polled. A fragile system of record did not have to be modernized before its pipeline could be made resilient. Files.com made the pipeline resilient around it.