A Trucking Services Provider Built a Governed Files.com Exchange Layer Over Its Azure Estate

A North American trucking services provider runs compliance and toll payment services for commercial motor carriers. Hundreds of thousands of truckers use the platform, which connects hundreds of roadside sites across the United States.

Every part of that business is a data exchange between parties that do not share systems. Service eligibility rests on safety and inspection data, and crash data helps determine whether a truck qualifies. Tolling means reconciliation with toll authorities. Billing means files moving to carriers, collections systems, and banks. The provider sits in the middle of state agencies, motor carriers, tolling authorities, and financial institutions, and the files have to move between all of them, every day.

Files.com became the governed exchange layer over storage the provider kept, rather than a new home for the data.

The Files That Ran the Business Moved by Hand

For years, much of that movement was manual or built one connection at a time.

Once a month, someone downloaded the latest crash data from an anonymous FTP server and imported it by hand. That is the data feeding service eligibility, retrieved and loaded by a person on a calendar reminder.

Payroll and timecard files delivered by ADP had to be moved by an operator before the Power BI reporting team could work with them. Billing files populate the autodialers in the provider’s collections call center, and the stakes of that feed are blunt: without the data, the dialers have nothing to dial and an entire call center sits idle.

And each new counterparty, whether a bank or a tolling agency, meant another bespoke connection to build and maintain on its own.

Storage in Azure, Counterparties Everywhere

The condition persisted because no single system could see all the endpoints. The provider is a cloud-based company, and its data lives where its systems put it: Azure Files and Blob storage, SharePoint, an on-premises SQL server, servers controlled by partners, and bank endpoints the provider does not operate. None of those exchange files with each other natively. The obvious fix, consolidating everything onto one storage platform, would have meant re-hosting data across the whole estate just to change how files travel.

So the fix had to do something narrower. It had to read and write Azure storage directly, connect outbound over SFTP to banks and agencies, run file moves on a schedule or the moment a file lands, and keep a record of every run, all without becoming another place the data has to live.

The provider selected Files.com to be that layer.

An Exchange Layer on Top of the Storage the Provider Already Had

Azure stayed the storage. Using Files.com Remote Server Mounts, the provider connected its Azure Files and Blob storage accounts into Files.com as ordinary folders. On-premises servers and cloud workflows continued dropping files into the same shares they had always used, and Files.com acted on what arrived. Most of the provider’s data remained outside Files.com storage.

Files.com Automations handled scheduled and upload-triggered file moves, with a recurring sync available as a backstop. Outbound connections linked the provider to banks, tolling agencies, and other counterparties over SFTP instead of requiring another hand-built process for each one.

What Runs Without an Operator Now

With those workflows in production, the provider replaced a patchwork of manual downloads and one-off connections with a single repeatable pattern for moving a file between any two of its systems.

• The monthly crash ingest, the data behind service eligibility, runs on schedule with no download and no manual import.
• The ADP payroll feed delivers overnight and unattended, so the reporting team finds the data waiting in SharePoint instead of waiting on a person.
• The billing files that populate the collections autodialers travel the same governed path, with a log of every run.
• Adding a counterparty is a connection, not a project. Outbound connections have kept growing, spanning national banks, tolling agencies, and the provider’s own internal endpoints.

That last change is the one that compounds. Because the pattern already exists, internal departments joined it instead of building their own file movement: site systems across hundreds of roadside locations, HR, Finance, and security all move files through Files.com today, with Automations running on their data.

Governed Movement, Without a Migration

Today, moving a file at the provider is no longer a job someone performs or a connection someone builds. The analyst who needs payroll data finds it already in SharePoint. Nobody has to retrieve or import the monthly crash file, and the feed that keeps a call center dialing arrives on the same logged path as everything else. When a new bank or tolling agency comes along, it becomes one more Files.com connection on a platform that already records every run.

None of it required leaving Azure. The storage stayed exactly where it was, and Files.com became the layer that governs how files move across it. The provider did not fix its file movement by migrating its data. It fixed the movement itself, one workflow at a time, on top of the storage it already trusted.