FHI Moved a Grocery FTP Feed Off Its Production SQL Server After Azure IP Whitelisting Failed

FHI pioneered the professional unloading industry. Founded in 1991, the company supplies trained crews that load and unload trucks inside grocery and retail distribution centers across the United States, working in facilities that range from 200,000 to 1.5 million square feet. Its teams operate deep inside other companies' buildings, on other companies' schedules.

That position shapes how FHI moves data. The load and appointment files that tell its crews what freight is coming, and when, flow between FHI and the distribution customers it serves. Those customers set the terms of the exchange: the endpoint, the format, and the schedule. FHI adapts to each one.

For one major grocery distribution customer, that adaptation had hardened into a fixture. Files were delivered to the customer's FTP server three times a day, seven days a week, at the same times since at least 2015. When FHI tried to move the feed through Azure, randomized outbound IP addresses left the customer unable to whitelist the connection.

The Database Server Was Also the File Transfer Client

The process behind that delivery was homegrown, and it ran in the worst possible place. The production SQL server that generated the load and appointment data pushed the files directly to the customer's FTP endpoint itself. The system holding FHI's operational data was also its internet-facing file transfer client.

There was no managed file transfer platform behind a delivery the customer depended on every day. Just a job running on a database server, connecting out to an external endpoint on its own. FHI's systems team knew it: their stated goal was to move the process off that server and secure it.

The Cloud Path the Partner Could Not Whitelist

The process survived nine years for two reasons.

First, the schedule had become an operational promise. The customer had received files at those times since 2015 and expected them at those times, every day. Any replacement had to keep the customer-facing behavior identical: same endpoint, same files, same clock.

Second, FHI's Azure-based transfer path could not meet the customer's IP-whitelisting requirement because its outbound addresses were randomized. The customer could never pin down what to allow, so the cloud route could not carry this feed. The source data, meanwhile, lived on an on-prem SQL server behind FHI's firewall.

The replacement had to pick files up from behind that firewall, present connectivity the customer could whitelist, hit three fixed delivery times a day without drift, and clean up the source afterward. It had to do all of that without the customer changing a single thing on their side. FHI selected Files.com to be that delivery layer.

A Local Share, an Agent, and a Scheduled Push

FHI's systems administrators built the new pipeline in September 2024, and it shrank the SQL server's role to one safe step. A script extracted the CSV and TXT files and dropped them into an outbox folder on the local Windows file share. That was the last thing the database server touched.

From there, the Files.com Agent synced the outbox folder to Files.com every 30 minutes, staging the files ahead of each delivery window. The Agent connected outbound only, so nothing behind FHI's firewall was exposed and no inbound firewall change was needed.

A Files.com Automation then pushed the staged files through a Remote Server connection to the customer's FTP endpoint three times a day, seven days a week, deleting them from the source after each completed transfer. The delivery presented stable connectivity the customer could whitelist, which was the requirement the randomized Azure egress could never satisfy.

From One Feed to a Repeatable Operating Model

With the pipeline in production, FHI replaced a homegrown push running on a production database with a governed, scheduled delivery running on Files.com. The production SQL server is out of the file transfer business, the customer's IP-whitelisting requirement is met, and the long-established delivery schedule continues unchanged.

The pattern did not stop at one feed. Two Files.com Agents now run across FHI's on-prem Windows file servers, carrying roughly nine scheduled syncs around the clock. Standing up the next scheduled exchange means configuring another sync and another Automation, not building another homegrown process on another server.

Changing the Plumbing Without Changing the Promise

FHI built its business on stepping into other companies' operations without disrupting them. With Files.com, it applied the same discipline to its own infrastructure. The grocery distribution customer continues to receive its load and appointment files at the expected times. Behind that unchanged schedule, everything is different: the systems administrator who once had to worry about a database server making its own FTP uploads now has a delivery that stages itself, pushes on schedule, and cleans up after itself. A nine-year-old partner delivery never had to change for the partner in order to change completely behind it.