Billion Automotive Replaced CDK-to-Snowflake Scripts and Hand Loads With One Monitored Files.com Job

Billion Automotive has been selling cars since 1935, when it opened as a single new-car franchise in Sioux Falls, South Dakota. More than ninety years on, the family-owned group operates 27 dealership locations across South Dakota, Iowa, Minnesota, and Montana, with 1,200 employees, a portfolio of new-car franchises, an OEM wholesale parts operation, and collision centers.

A dealer group that size runs on its dealer management system, and at Billion that system is CDK. Sales, service, parts: the transactions of the whole group pass through it. So every question the business asks about its own performance starts with getting data out of CDK. And CDK data leaves the system as file exports: GPG-encrypted files that land on an internal SFTP server and wait for someone to carry them the rest of the way.

A Warehouse Feed Built From Scripts, Hand Loads, and a Separate Decryption Step

For years, carrying them the rest of the way was manual work. Exports were loaded by hand. One-off scripts handled individual steps, and separate tools handled others: one script for this job, a different product for that one. Because the exports arrived encrypted, GPG decryption was its own step in the middle of the chain, performed before anything could be staged. No orchestration layer sat over any of it, and nothing monitored it.

Billion had outgrown data movement assembled by hand, and the cost showed up in the worst possible place. A batch that arrived incomplete, or a step that failed quietly, went unnoticed until someone in the business asked why their numbers were missing. The people relying on the data were the pipeline's only monitoring. IT learned that a load had broken from an unhappy stakeholder, after the damage was already visible.

Snowflake Went to Production, and the Manual Chain Could Not Carry It

Billion spent roughly six months building out its Snowflake environment. Then the environment moved to production, and the nature of the work changed. Ad-hoc development loads became recurring incremental loads across multiple tables, with business stakeholders depending on the data being there every day. A chain of unmonitored scripts and hand-loaded files could not carry that dependency.

The fix had to automate the feed end to end and notify IT when a load did not run. And because the source SFTP server sat inside Billion's network, it had to reach the files without exposing that server to the internet.

Billion selected Files.com to be that orchestration layer, connecting the systems already in place rather than replacing them.

An Agent Inside the Network, One Job End to End

Billion deployed the Files.com Agent onto an internal server. The Agent holds an outbound-only encrypted connection to Files.com and reaches the internal SFTP host where CDK exports land, so the server was never opened to the internet and never had to move. From the Files.com console, the team browses that internal server like any other folder.

On top of that connection, a single Files.com Automation runs the whole feed. It picks up each CDK export, decrypts it in flight using GPG keys that Billion manages itself, and syncs the result into the Azure container feeding Snowpipe. Mount, decrypt, and sync collapsed into one job. Every run lands in a log, and failure alerting notifies the team when a load does not complete. Access to the platform sits behind Billion's Azure single sign-on.

Systems Architect Jeff Schuurmans built the entire configuration himself, with Billion's security administrator testing alongside, and had it working in less time than he expected the build to take.

“We thought it was going to be harder to use.”

Loads That Run Themselves, Failures That Announce Themselves

With the Files.com pipeline in production, Billion replaced a chain of scripts, hand loads, and a standalone decryption step with one automated job that reports its own failures.

• The CDK-to-Snowflake feed runs daily with nobody touching it: nobody decrypts a file by hand, and nobody stages a load.
• The six-month Snowflake build became a working production system: automated incremental loads across multiple tables, feeding reporting for the entire 27-dealership group.

The architecture also compounds. Because the Agent, the key management, and the automation engine are platform capabilities rather than custom code, standing up the next feed means adding a connection and an automation, not writing and babysitting another script.

The Layer Over What Was Already There

Today, when a load fails at Billion Automotive, the data team hears it from a Files.com notification instead of from a manager asking where yesterday's numbers went. That is the difference the pipeline was built for.

What Billion did not do is just as instructive. Nothing upstream was replaced. CDK still exports what it always exported. The internal SFTP server still catches the files. Azure still stages them, and Snowflake still loads them. Files.com became the layer that connects those pieces, moves the data between them, and answers for whether it actually moved. Modernizing the pipeline did not require ripping anything out. It required putting one accountable system in charge of the space between them.