A Luxury Fashion Group Retired On-Premises FTP and Cleared One Files.com Site for Several Fashion Houses

The regional shared-services arm of a global luxury fashion group gives several fashion houses of different national origins common commercial, operational and back-office rails, while each house keeps its own identity at the front. Those brands sell through hundreds of dedicated boutiques across the region.

The hard part of that model is the seam it creates. One back office runs operations for several distinct houses, so one IT function ends up moving files for all of them: retail data out of the stores, HR data, partner exchanges, integration feeds. Every house brings its own partners and its own data, and none of it may mix. Whatever platform carries that exchange has to hold the brands apart while serving them all. The answer had to do more than replace FTP: it had to clear the group's reviews once, keep each house's data separate and give each new feed or partner a common place to land.

The Replacement Had to Meet the Group's Controls From Day One

The function's file exchange ran on on-premises FTP infrastructure, and the team set out to replace it. What the group requires of a system in that position is specific: management-console access behind the group's own Okta identity, with SAML single sign-on and MFA; IP whitelist control on every connection; and independent storage for each user, so no account sees another's data. The replacement had to meet that specification from the first day it went live.

The volume made the specification harder to meet, not easier. At the start the workload was small: a modest number of files and only megabytes of data moving in and out per day. The controls did not scale down with it. The group requires the same identity, isolation and audit standard on a small workload as on any other, so the team needed enterprise-grade governance on a footprint far smaller than the platforms built for it usually assume.

There was a longer clock running too. Anything that handles house data inside the group's estate faces the group's scrutiny: a third-party security review, a disaster-recovery assessment against group audit policy, a data-classification review. The team needed one platform that could take SFTP and API traffic to external partners and to its Mulesoft API management layer and meet the controls from the first day.

The shared-services arm selected Files.com as that platform and retired the on-premises FTP infrastructure.

One Files.com Site, Every House Behind It

Files.com became the single governed exchange layer between the houses' store systems, their business applications and their outside partners. The site went live small and controlled, with the full control set active from day one.

The boundary work came first. Console login ran through the group's own Okta with SAML SSO and MFA. Connections sat behind IP whitelists. Every user had independent storage, and Groups with delegated Group Admins kept administration organized, so several brands shared one site without sharing anything else.

SFTP was the primary path: scheduled point-of-sale and HR extracts flowed through Files.com into the team's Dynamics 365 environment, while per-house Mulesoft service accounts let each brand's API integrations run under their own identity. Files.com Automations and sync rules routed recurring files without anyone touching them, and an outbound connection delivered files onward to SharePoint. Files.com thus handled recurring SFTP and API workflows across the houses while preserving separate identities and connecting to the application estate the team already operated instead of replacing it.

Cleared Once by the Group, Then Scaled Past Its Launch Profile

With Files.com in production, the shared-services function replaced its FTP estate with a platform that met the group's control requirements and that every house now builds on.

• A single security-by-design assessment cleared the entire solution, and the group's data-classification review separately cleared the platform's continued use for the retail data work.
• The team ran a full disaster-recovery assessment of the platform against group audit policy, covering recovery time objectives, recovery point objectives and the recovery procedure itself, and Files.com remains the exchange layer on the other side of that audit.
• The site opened with a small daily workload. It has since expanded to carry daily retail feeds from stores in several countries and hundreds of thousands of API calls a day.

The immediate result was an exchange layer that met the controls. The compounding result is what followed: every subsequent workload has been configuration on an already-cleared platform rather than a new tool paying its way through a new review, whether it involved a new house feed, a new partner or a new downstream delivery like SharePoint.

The Exchange Layer Every House Builds On

Today, when a house brings a new partner or a new system feed to the shared-services team, the work starts on a platform the group's own reviewers have already assessed: Okta at the door, whitelisted connections, storage that keeps each house's data its own. Without a cleared platform, the same request would mean introducing another tool into the estate and paying the group's review over again. For a back office whose whole purpose is giving several houses shared rails without eroding what makes each one distinct, that is the change Files.com delivered: the group's control regime became a cost paid once, and file exchange became something every house simply plugs into.