A Heavy Equipment Dealer Retires BatchSync for a Direct Azure Blob-to-Partner FTP/SFTP Pipeline

A multinational heavy equipment dealer sells, rents, and services machines for mining and construction operators. Increasingly, it also watches the machines it sells. Haul trucks, excavators, and dozers in the field report fuel consumption, failure codes, and warning codes back to the dealer, and its condition-monitoring teams turn that telemetry into maintenance and repair decisions for fleet operators.

That monitoring business produces data that has to keep moving. Once telemetry has been processed in the dealer's Azure cloud, the results go back out: to the customers who run the machines, and to the equipment manufacturer itself. The recipients take delivery the way heavy industry always has, on FTP and SFTP servers. The dealer sits between a cloud data plane and a partner ecosystem that speaks protocols older than the trucks. A file that starts life in an Azure Blob container has to end up on someone else's FTP server, tens of thousands of times a day. The dealer used Files.com to retire BatchSync and make that journey direct, without changing the endpoints its customers and the manufacturer already used.

Tens of Thousands of Files a Day Through a Desktop Batch Tool

For years, the thing bridging that gap was BatchSync, a desktop batch file-transfer tool. Every file bound for a customer or for the manufacturer made an extra stop on the way out: pulled from Azure Blob, duplicated into a staging copy, then pushed to the destination server in batches. At tens of thousands of files a day, arriving continuously from multiple customer sites, that put a desktop tool and a duplicate copy of everything in the middle of a production, partner-facing data pipeline. The dealer had outgrown that kind of tooling for a flow this size.

The arrangement survived because the endpoints could not change. The dealer does not control what its partners run. Customers receive their data on FTP and SFTP servers, the manufacturer's intake is an FTP server, and Azure Blob speaks neither protocol. Something had to translate between object storage on one side and protocol servers on the other, and for years the desktop tool was that something.

So the replacement had a clear specification. It had to connect to the Azure Blob storage where the data already lives, without moving or copying it. It had to speak FTP and SFTP to endpoints the dealer does not control. It had to deliver each file as it arrives, route it to the right partner, and keep pace with continuous additions from many customer sites at once, with no staging copy and no server of its own to stand up in the middle. The dealer selected Files.com to be that translation layer, and retired BatchSync entirely.

Files.com Mounts the Azure Storage and Speaks the Partners' Protocols

Using Files.com Remote Server Mounts, the dealer's developers connected the Azure Blob containers that hold processed telemetry directly to the platform. A mounted container appears as an ordinary folder, and the data stays in Azure. Nothing migrates, and nothing is stored twice.

One platform carries every outbound connection, and each run retries on failure and lands in the platform's logs. A partner endpoint that drops offline briefly does not need a person to notice and re-send. On top of the mount, Files.com Syncs collect newly arrived files, and Automations deliver each one to its destination: a customer's SFTP server, or the manufacturer's FTP. Routing is per partner.

BatchSync Retired, the Pattern Reused for Every Outbound Connection

With the Files.com workflow in production, the dealer replaced a staged, desktop-driven transfer process with a direct cloud-to-partner pipeline.

• The pipeline keeps pace with continuous arrivals from every customer site at its full daily volume, with sync runs completing in minutes.
• Onboarding the next outbound connection is a sync and an automation against the same mount, not another tool. The dealer proved the approach on one partner connection, reviewed the rest, and moved them all onto the same design.

One Trip from the Bucket to the Partner

Today, a processed telemetry file bound for the manufacturer makes one trip. It lands in Azure Blob, and Files.com carries it to the manufacturer's FTP with nobody staging it, duplicating it, or watching a batch tool run. The same is true for every customer that takes delivery of the dealer's condition-monitoring data.

The dealer never asked its partners to modernize. The endpoints still speak FTP and SFTP, and none of that had to change. What changed is that the dealer's cloud storage can now reach those endpoints itself: Files.com mounts the storage where it lives and speaks the protocols the other side already runs. The developers who own the telemetry data plane now own its outbound delivery too, on the same platform, and the last desktop tool in the pipeline is gone.