A Travel Retailer Moved Legacy FTP and PowerShell Workflows to Files.com—Without a Cutover

A North American travel retailer operates hundreds of specialty retail stores in airports and resorts across the United States and Canada.

A retail operation of that shape runs on file exchange. Vendor orders arrive as files. Sales transactions flow back from stores to keep inventory accurate. Pricing updates go out to the stores themselves. Every one of those movements is a file crossing between a vendor, an internal system, or a store endpoint, every day.

Legacy FTP for the Vendors, a Script for Everything in Between

For years, that exchange ran on infrastructure the IT team held together by hand. Vendor and client data moved over legacy FTP connections. Hand-written PowerShell scripts carried the routing logic: which files to move, which to delete, where each one went next. Behind them, an on-premise scheduler ran the file automations, with no cloud integration at all.

The cost showed up in two places. Every change to a feed meant editing a script, and every new vendor meant another connection to stand up and more scripting to route what arrived. And as the company's systems extended into the cloud, with an Azure environment and SharePoint Online, the file layer could not follow. The pipeline that kept inventory accurate and pushed pricing to hundreds of stores stopped at the edge of the data center, and reaching anything beyond it meant writing more bespoke code.

The diagnosis was simple: file movement for the whole retail operation was code on servers, and the servers could not reach the cloud.

The estate survived as long as it did because it was too fragmented to replace in one move. Dozens of vendor and client endpoints each had their own connection, and the daily sales and pricing feeds could not stop for a cutover. Any replacement had to absorb the estate a piece at a time.

What the Replacement Had to Do

The IT team's requirements were specific. They wanted an SFTP-based managed file transfer service that would also supply the storage, so vendor exchange ran on the provider's footprint instead of a server they maintained. It had to reproduce the logic embedded in the scripts: pattern-matched moves, in-flight cleanup of unwanted files, and routing that hopped across multiple servers. It had to reach both on-premise Windows servers and the cloud systems the old scheduler could not. And it had to support a rolling migration, vendor by vendor, while the daily feeds kept running.

The retailer selected Files.com to be that platform.

Vendor Exchange Moved to Managed SFTP, One Connection at a Time

Vendor and client connections were upgraded onto Files.com in sequence. Each migrated vendor now exchanges files over SFTP against Files.com, with Files.com supplying the storage behind the exchange. Where a vendor holds files on its own server, a Files.com remote server connection pulls them in on a schedule instead of waiting for a push.

Because the migration ran connection by connection, there was never a cutover weekend. And the pattern has held ever since: new vendors, clients, and internal teams are brought straight onto the platform as they come up.

Agents On-Premise and in Azure: The Pipeline the Old Scheduler Could Not Run

In parallel, the team rebuilt the script layer as Files.com Automations, using the Files.com Agent to give the platform reach into their own infrastructure. Agents run on Windows servers both on-premise and in the company's Azure environment, connecting outbound to Files.com so that internal directories appear as ordinary Files.com folders.

Files.com recreated and consolidated the routing logic while connecting on-premise servers, Azure, and SharePoint Online. In one workflow, a file-triggered automation deletes unwanted file types in flight before downstream systems in Azure pick up the remaining files for sales processing and store pricing updates.

The pattern logic that once took a script per case now runs as configuration. Using automation sets, the team collapsed several separate filename patterns into a single automation. They also mounted SharePoint Online into Files.com, bringing SharePoint transfers into the same managed pipeline.

Inventory and Pricing Feeds Without Custom Scripts

Inventory and pricing feeds now span on-premise systems, Azure, and SharePoint Online through Files.com. Vendor and client exchange runs over managed SFTP, with Files.com supplying the storage instead of a dedicated vendor transfer server maintained by the team.

More than a dozen automations are in production, several of them delete automations cleaning unwanted files out of the pipeline in flight.

The maintenance payoff is clearest whenever the operation changes. Onboarding the next vendor is a new SFTP connection, not a new script. Routing a new feed used to mean an engineer editing a PowerShell script on a server that could not see the cloud. Now it is an automation configured on Files.com, running against any endpoint the platform reaches, on-premise or in Azure. Reaching another server means deploying an Agent and pointing an automation at it, not writing and maintaining another script.

Critical Infrastructure, Migrated Without a Cutover

Today the retailer classifies Files.com internally as critical infrastructure. The data that keeps inventory accurate and prices current across hundreds of airport and resort stores crosses the platform every day.

And none of it required a cutover. The FTP connections came over one vendor at a time while the automation layer was rebuilt in parallel, and the same Files.com platform that hosts the vendor SFTP exchange became the bridge between the company's data center and its cloud.