Finning Retires BatchSync for a Direct Azure Blob-to-Partner FTP/SFTP Pipeline

Finning is the world's largest Caterpillar dealer. It sells, rents, and services Cat equipment for mining and construction operators across Western Canada, South America, and the UK and Ireland, with approximately 13,000 employees. 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 Finning, 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 Finning's Azure cloud, the results go back out: to the customers who run the machines, and to Caterpillar itself. The recipients take delivery the way heavy industry always has, on FTP and SFTP servers. Finning 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. Finning used Files.com to retire BatchSync and make that journey direct, without changing the endpoints its customers and Caterpillar 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 Caterpillar 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 20,000 to 40,000 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. Finning had outgrown that kind of tooling for a flow this size.

The arrangement survived because the endpoints could not change. Finning does not control what its partners run. Customers receive their data on FTP and SFTP servers, Caterpillar'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 Finning 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. Finning 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, Finning'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 Caterpillar's FTP. Routing is per partner.

BatchSync Retired, the Pattern Reused for Every Outbound Connection

With the Files.com workflow in production, Finning 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. Finning 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 Caterpillar makes one trip. It lands in Azure Blob, and Files.com carries it to Caterpillar'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 Finning's condition-monitoring data.

Finning never asked its partners to modernize. The endpoints still speak FTP and SFTP, and none of that had to change. What changed is that Finning'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.