A Luxury Fashion House Retired Its FTP/SFTP Servers One Workload at a Time With Files.com

A global luxury fashion house sells in dozens of countries through its own stores alongside wholesale and e-commerce. Behind that omnichannel operation sits a constant exchange of data. Every sale, shipment, product update and order has to move between the point-of-sale systems, the ERP, the warehouse, the e-commerce platform and trading partners, and at this company most of that movement happens as files. For years, the servers moving those files lived in a data center the company ran itself. Closing it would mean moving dozens of live file-transfer flows one workload at a time while the systems around them were also changing.

Nearly 500 Servers of Accumulated Technical Debt

The estate had grown the way retail IT estates grow: a server per system, per integration, per era. By the time the company decided to do something about it, there were nearly 500 of them. Among them sat the internal SFTP and FTP servers that the company's integrations depended on to exchange sales, shipping notices, product data and orders.

Every one of those machines was work. Each was an operating system to update, a box to secure, and a point of failure to watch, and together they were a building the company had to keep open. When the company committed to moving its ERP to Microsoft Dynamics 365 and its infrastructure to Azure, the data center was slated to close. The file transfer servers were among the workloads standing in the way.

Dozens of Live Retail Flows, and No Way to Cut Over at Once

Those servers were not idle legacy. POS transactions, warehouse exchanges, e-commerce orders from Salesforce Commerce Cloud and partner files crossed them daily. And the systems on both ends of every flow were themselves in motion: the ERP was being replaced by D365 while the infrastructure underneath moved to Azure. A synchronized cutover of dozens of live retail integrations, in the middle of an ERP migration, was not realistic.

So whatever absorbed the transfer estate had a specification. It had to take workloads one at a time. It had to speak the SFTP and FTP the existing endpoints already spoke, so a flow could move without rewriting the systems around it. It had to keep every flow running while the endpoints themselves changed. And it had to need no patching once a workload landed on it, or the exercise would only relocate the debt.

Files.com already carried the company's partner file exchange. The company decided the internal transfer estate would move onto it too: shut down the internal SFTP servers and put everything on Files.com.

Six Months, One Endpoint at a Time

Files.com became the hosted transfer layer between every retail system, so the servers underneath could be retired as their workloads left. Over roughly six months of 2025, running in parallel with the physical data-center-to-Azure migration, integrations moved one at a time and finished in December 2025.

Using Files.com outbound remote-server connections and server-to-server folder sync, the company moved POS transactions, Salesforce Commerce Cloud orders bound for the warehouse, and sales, shipping-notice and product-data flows independently without rewriting or disrupting the surrounding systems. As the D365 and Azure migration finished, the last of the on-premises FTP moved onto Files.com and the internal SFTP and FTP servers were shut down for good.

A Tenth of the Servers, and Nothing Left to Patch

With the last workload moved, the company had replaced a self-managed transfer estate with a hosted layer it does not maintain.

• Every previously on-premises FTP and SFTP workload now runs on Files.com, and the internal transfer servers are gone.
• Every flow remained running as the integrations moved one at a time.
• The server estate went from nearly 500 servers to around 40 or 50, and the data center closed.
• The transfer layer carries more than twice the system connections it did a year earlier, on infrastructure the company does not run.
• No one on the IT team patches, updates or installs antivirus on a file transfer server anymore.
• When Azure and AWS suffered provider outages in late 2025, the flows running on Files.com kept moving.

The larger change is what the next integration costs. Every integration the company runs — sales, shipping notices, product, orders — transmits through Files.com, so adding one means standing up a connection on the platform, not building a server that someone will still be patching in five years.

The Layer in the Middle of Every Exchange

What changed at the fashion house is what file transfer is. It used to be infrastructure: machines the company bought, housed, patched and eventually counted as technical debt. Now it is a service the integrations ride. An engineer who needs to move data between the POS and the ERP, or the e-commerce platform and the warehouse, wires up a connection on Files.com, and the flow is live, hosted and logged, with no machine behind it that the company owns.

The transfer estate never had to hold the data center open. It moved endpoint by endpoint, in the middle of an ERP migration, with every flow still running — and when the last workload left, Files.com had taken the servers out from under it.