An Apparel Brand Moves Payroll, Order, and Vendor Feeds to Files.com Without Rewriting Its Integrations

A direct-to-consumer apparel brand runs an operation that is unusually vertical for fashion. The company designs its own clothing, manufactures in its own factory, and sells through its e-commerce channel and dozens of retail stores.

An operation like that runs on file exchange, even though nothing about it looks like a file-transfer business. Orders come off the e-commerce platform as XML for the order management system. Shipping carriers and product-feed platforms read and write data every day. HR and payroll systems trade CSVs of employee pay data for staff in three countries. The file-transfer layer underneath all of it had grown up one integration at a time, across three self-managed SFTP servers. The brand retired all three with Files.com without rewriting the order, payroll, and vendor integrations that depended on them.

Payroll, Orders, and Vendor Feeds on Three Self-Managed Servers

By 2024, those three servers were doing serious work. One ran in GCP, one on a hosting provider, and a third had been stood up separately to carry the HR and payroll exchange. The brand's VP of Engineering described them as workhorses, some of them business critical, and wanted them replaced by a platform the engineering team did not have to run.

The work crossing those servers was anything but marginal. Inbound CSVs from ChartHop, the HR system, and Paychex, the payroll provider, kept pay and terminations in sync for employees in the US, Canada, and the UK. Logistics carriers including FedEx and UPS, along with product-feed, marketing, and EDI platforms, exchanged files daily. And the handoff the brand considers absolutely mission critical, Salesforce Commerce Cloud dropping order XML to the order management system, ran as a file drop on an SFTP path.

The brand set two requirements for whatever replaced them. Every vendor had to work in its own space, with a guarantee that no partner could reach another's files. And access to employee pay data had to be held to a handful of named people, with a log that could prove after the fact who had looked at what. The VP of Engineering's standard was that not even the head of engineering should hold standing access to pay data. Both requirements followed from the SOC 2 Type 2 posture the company holds itself to.

The annual penetration test set the timing. Assembling the inventory of systems for it put all three servers on one list, and after the MOVEit and SolarWinds breaches, the brand wanted its file transfer on a platform someone else patched.

A Drop-In Replacement or Nothing

The estate had survived this long because everything was integrated against it. Internal scripts picked vendor CSVs off those servers and loaded them into BigQuery. The order flow depended on its SFTP drop. External partners had credentials and automations pointed at existing paths. A replacement that forced changes to those processes would be a deal breaker.

The team also had no intention of building vendor isolation and access logging itself on top of self-managed boxes. Engineers were hired to build the commerce stack, not to run file servers.

So the requirements wrote themselves: hosted SFTP that existing scripts and vendors could point at without rework, SSH key authentication for the partner that required it, encryption in transit and at rest, and the vendor isolation and access logging the VP of Engineering had set as the bar. The brand selected Files.com to be that platform.

One Silo per Vendor, Every Access in the Log

Underneath the automation, nothing moved. The internal scripts that collected vendor CSVs and loaded them into BigQuery still collected from an SFTP path; the path now terminated at Files.com. Salesforce Commerce Cloud still dropped order XML for the order management system the same way it always had. The servers changed, and the mechanics the business depended on did not.

Each external partner moved onto its own isolated Files.com account, with permissions scoped so that no vendor can see that any other exists. The partner that required SSH key authentication connects with keys rather than a password.

The HR and payroll exchange got the tightest treatment. ChartHop and Paychex deliver their CSVs into a space where access is restricted to a handful of people, data is encrypted in transit and at rest, and every access lands in the audit log. If anyone ever questions whether an administrator looked at pay data, the logs can answer. That was the VP of Engineering's requirement, and it is now simply how the system works.

Three Servers Retired, Nothing Rewritten

With the migration done, the brand replaced three self-managed servers with one governed platform:

• All three servers are gone, and the brand's engineers no longer patch or maintain any SFTP infrastructure.
• Vendor traffic is siloed. Each partner works in its own account and cannot reach another partner's data.
• Access to employee pay data is held to a handful of people and every access is logged, so payroll stays in sync across three countries and every look at pay data is on the record.
• The mission-critical order flow runs on managed infrastructure that the brand's engineers do not have to maintain.

The change also compounds. Onboarding the next partner is an isolated account and a set of permissions, not another server somebody on the engineering team has to own for the rest of its life.

File Transfer Became Someone Else's Full-Time Job

Today, the brand's engineers build the commerce stack and the data pipelines, and none of them runs a file server on the side. The burden of patching and maintaining SFTP infrastructure now sits outside the internal engineering team.

The servers were retired, and every script, vendor integration, and order flow that depended on them kept running exactly as before. The paths stayed. Only what stood behind them changed.