A Luxury Fashion House Runs Every Retail Integration Through Files.com on Azure Blob Storage

A global luxury fashion house sells ready-to-wear, handbags, leather goods, footwear, eyewear, and fragrance in dozens of countries, through its own mainline stores, wholesale accounts at major department stores, and e-commerce.

An omnichannel operation of that shape runs on files. Orders from the e-commerce platform have to reach the warehouse. Sales, inventory movements, and shipping notices have to move between stores, the ERP, and logistics partners as far away as Japan and China. Every one of those handoffs is a file crossing between systems, and many of those systems belong to somebody else.

Partner Exchange Held Together by a Rename Convention

In 2021, those exchanges ran on infrastructure the company built and operated itself. Files moved to and from partners through separate SFTP client tooling pointed at the company's own SFTP servers. The safeguards were hand-built too. To keep a downstream system from picking up a half-written file, the team wrote every file under a temporary name and renamed it to its real filename only once the write finished. Exchanges still required manual intervention, and every integration or automated sync between the company's systems and a partner's was something the team had to assemble on its own.

The cost was not any single transfer. It was that correctness depended on a naming convention the team had to build into every flow, and that every new partner or system connection was another custom build. That held together at the scale it started at. It could not carry an integration estate heading toward point-of-sale, ERP, e-commerce, warehouse, and international logistics flows in EDI and CSV, some of them delivered every few minutes.

A Replacement That Had to Keep Commercial Data in Azure

Replacing the plumbing meant choosing a platform, and one requirement was fixed before the search began: the company runs on Azure, and its commercial data had to stay there.

The rest of the requirements were the old setup's failures, restated. The replacement had to pull and push files to partner servers natively, with no separate client in the middle. It had to treat a partially written file as not yet arrived, so nobody had to maintain a naming trick. It had to connect a mixed set of endpoints, from partner SFTP servers to the company's own systems. And it had to do all of that with the data in Azure.

The company selected Files.com to be that sync layer. Because Files.com mounts Azure Blob Storage containers as native folders, the company's commercial data lives in Azure while Files.com moves it.

What was bought for partner exchange became the route every retail integration takes.

Sync Jobs Instead of an SFTP Client

Files.com remote server sync took over the work the client tooling had done. Server-to-server folder syncs, running in push mode, move files between the company's folders and partner endpoints on the schedule each flow needs. Files.com treats a file as arrived only once it is completely written, so the temporary-file rename convention had nothing left to protect against. Both the convention and the client tooling were retired.

The rollout was deliberate. A separate test site validated each partner's SFTP integration before anything touched production. Partner sync jobs ran clean for about two weeks before the first live flow: e-commerce data exchange with a partner in Japan. Within a month of going live, a warehouse was delivering a heavy hourly stream of small files into the platform over SFTP.

The Partner Layer Became the Retail Integration Backbone

The same pattern, an outbound remote-server connection plus a folder sync, extended to system-to-system flows inside the business. Salesforce Commerce Cloud orders hop through Files.com to the warehouse. Point-of-sale systems, the ERP, and Azure Blob Storage endpoints exchange EDI and CSV transactions over the same connections, with retail data delivered at frequencies down to every few minutes. POS transaction types are split across separate connections, each mapped to a functional folder of its own, so a failing flow can be traced and fixed without touching the rest.

The file handling around those flows runs in the platform rather than in code. Files.com Automations move files on arrival or on a schedule, so one rule covers a whole class of files. The company's integration tools, Talend and MuleSoft, also drive the Files.com REST API. When the company implemented its Microsoft Dynamics 365 ERP, the integrations were built on Files.com from the start.

The Existing Pattern Absorbed the Growth

With the sync layer carrying the whole estate, the pattern kept absorbing growth.

• Filtering and file handling that would otherwise be custom code run as platform configuration, so a new flow is a rule, not a development project.
• Daily API calls and monthly transfer volume both grew substantially in a single year, and call volume climbed again through 2025.
• Outbound remote-server connections more than doubled in the most recent year. Each new connection is a system or partner reached through the existing pattern, not a new build.
• The company's integration flows kept running through cloud provider outages.

In the Middle of Every Exchange

Today, nobody at the company maintains a rename convention, and nobody hand-assembles the plumbing to connect the next system or partner. An integration is an outbound connection, a folder, and a sync job Files.com already knows how to run. The part of the operation that used to be hand-assembled is now the part its leadership describes as the center.

The company did not set out to buy an integration platform. In 2021 it bought a way to stop running an SFTP client and a naming trick. The years since have shown those to be the same purchase: a sync layer that handles files correctly on its own turned out to be the layer a global retail operation could route every integration through.