A Specialty Retailer Replaced Its Legacy FTP Backbone With Files.com Without Changing Vendor SFTP Drops

A North American specialty retailer sells novelty and pop-culture merchandise through hundreds of year-round stores and online. It also runs a seasonal business that opens, stocks, runs, and closes a large fleet of pop-up stores every year. The stores exist for a single season. The rest of the year is spent preparing for them.

That rhythm shapes everything the company's systems have to do. The peak runs for a few months each year, and during that window the platforms are frozen: no changes, no upgrades, no reconfiguration. E-commerce trades year-round, and every online order becomes files in motion. Order and shipment files travel between the e-commerce platform, the Koerber Nspire order management system, and the third-party fulfillment vendors who ship the goods. The interchange carrying those files takes the whole year's load in one compressed season, at exactly the time when nothing about it can be touched.

A Self-Hosted FTP Server Under the Heaviest Load of the Year

That interchange ran on infrastructure the team wanted gone. An in-house FTP server sat in the DMZ. Alongside it, an internal managed-file-transfer client hosted the FTP sites vendors connected to, and custom scripted routines moved the order files between systems.

The cost of that arrangement landed at the worst possible moment. The season's order volume crossed a self-hosted server during the freeze, when a problem could not be fixed by changing the system: whatever was running when the season opened had to hold until it closed. And every new requirement around the flow, from archiving processed files to notifying downstream systems, meant writing and maintaining more code. The retailer had outgrown the estate carrying its transactions. As part of a broader initiative to move file exchange off its self-hosted servers, the infrastructure team set one goal above the rest for this flow: retire the old FTP server.

The Fulfillment Vendors Could Not Be Asked to Change

The estate had lasted because of who sat on the other end of it. The fulfillment vendors were third parties, and asking them to connect through APIs meant asking outside companies to do development work, which the retailer was not going to do. Their SFTP drops had to stay exactly as they were, which meant the replacement had to happen entirely behind the interface: the same drop on the vendor side, a different platform underneath. The calendar tightened it further, because implementation work at the retailer started at the turn of the year and everything had to be proven before the seasonal freeze.

So the fix had a clear specification. Present an SFTP endpoint identical to the one vendors already used. Expose a REST API that MuleSoft, which carried the order-file routines, could call directly. Signal downstream systems the moment a file arrived. Connect natively to Azure Blob and S3 so archiving and analytics would not require custom code. And absorb the season's surges without falling behind.

The retailer selected Files.com to be that exchange layer.

The Same SFTP Drop in Front, Files.com Behind It

Files.com became the data exchange interface between the e-commerce platform, the order management system, and the fulfillment network.

Behind the drop, the flow is event-driven. When a vendor drops a file, a Files.com webhook fires and notifies the downstream systems. MuleSoft calls the Files.com REST API directly to move files between platforms, with a queue and connection throttling controlling seasonal surges. A file that fails processing lands in an error folder wired into the on-call alerting chain, so a broken transfer pages an engineer instead of failing silently. Files.com Automations, filtered on filename patterns, copy processed order files to Azure Blob Storage without custom code.

The cutover was staged behind the business. The interchange went live in 2024, weeks before the season, with the legacy FTP server running in parallel while fulfillment vendors were migrated across one at a time. Then hundreds of seasonal stores opened, and the new backbone took its first peak.

Peak Volume Moved With Delays Measured in Minutes

With the interchange in production, the retailer replaced a legacy FTP backbone with an exchange layer on Files.com, and the season that followed was the proof.

• Thousands of transactions move through the production site every day at the height of the season, with processing delays measured in minutes. The interchange runs the seasonal peak inside SLA.
• No fulfillment vendor changed anything. The modernization happened entirely behind the SFTP interface, so no third party did development work, and the drops they use today are the ones they have always used.
• The self-hosted DMZ server and the internal MFT client were retired. Archival is now configuration: Automations sweep processed files to Azure Blob, a job the team would otherwise have written and maintained a script for.
• The next feed lands on the same layer. The Adobe Analytics pipeline runs through the same site over an S3 mount at tens of thousands of files a day, absorbed without standing up new infrastructure.

The Backbone Behind the Season

Today, the files that turn an online order into a shipped package move through Files.com. At the year's heaviest moment, that flow used to depend on a self-hosted FTP server in the DMZ that nobody could change until the season closed, kept in motion by scripts someone had to maintain. Now a vendor's drop notifies the order management flow the moment it lands, a failure pages the engineer on call, and the archive sweeps itself.

The retailer rebuilt the transaction backbone of a business that earns its year in a single season, and did it without asking one fulfillment vendor to change a thing. The SFTP drop the vendors see is the one they have always used. Everything behind it is Files.com.