A Housewares Retailer Replaced Its Windows FTP Server With Files.com—Without Rewriting Partner EDI

A European housewares retailer runs hundreds of points of sale across its home country, including directly managed stores, franchises, and corners inside other chains. It also manufactures many of the products it sells under its own labels, and its logistics run through national hubs that feed its retail and online operations.

A business shaped like that runs on machine-to-machine file exchange. Orders, documents, and catalog data move continuously between the retailer’s systems and the systems of its suppliers and customers, with no person in the loop. For years, all of that traffic passed through a Windows FTP server that the retailer hosted itself.

Moving that external endpoint could not mean rebuilding everything connected to it. The replacement had to preserve the protocol and conventions used by partner scripts while continuing to hand files to the retailer’s internal systems where they already looked for them.

An FTP Server on the Perimeter, Carrying Every Partner Transaction

The server was the company’s external file-exchange endpoint. Every supplier and customer that traded files with the retailer transacted against it, and most did so programmatically: scripts on the partner side connected, dropped files, and collected files on their own schedules.

That put the ICT team in the business of running an internet-facing server that the rest of the company’s trading depended on. They owned its uptime, patching, and security. A self-hosted point of exposure sat on the perimeter every day, carrying business-critical order and document flows, and every hour spent keeping it current was an hour spent on infrastructure rather than on the exchange itself. As traffic across the network grew, so did the exposure.

The retailer’s ICT team concluded that its external FTP traffic belonged on a managed platform rather than on a machine the company had to defend itself.

Partner Scripts on One Side, Internal Systems on the Other

The server had survived as long as it did because it sat between two constituencies, and the retailer controlled neither freely.

On the outside were the partners. Their scripts had been written against the retailer’s endpoint and folder conventions, and they ran unattended. A replacement that changed the protocol or broke those conventions would have meant asking counterparties to rework their own integrations.

On the inside were the retailer’s systems, which read and wrote files only on the company’s own servers. Whatever received a file from a partner still had to hand it to those systems where they already looked for it.

So the replacement had a specification before it had a name. It had to speak the plain FTP the partner scripts already used. It had to keep each partner’s traffic separated in its own folder structure. It had to move files automatically between the external endpoint and the retailer’s internal servers. And it had to take the hosting, patching, and securing of an internet-facing server off the ICT team entirely.

The retailer selected Files.com as that managed endpoint for its external file exchange.

The Same FTP, the Same Folders, No Server Behind Them

Suppliers and customers connected to Files.com the same way they had connected to the old server. Each partner retained a separate folder tree for inbound, outbound, and processed files. Partner scripts transacted over FTP, while some wrote to the platform programmatically through the Files.com API.

The Windows server and Files.com operated in parallel while partners moved across. Once the traffic had shifted, the retailer retired the old server, completing the migration by early 2024.

The retailer’s internal systems continued to read and write files on its own servers. The team subsequently designed direct synchronization between those locations and Files.com. Files.com Automations and Remote Server Syncs now carry files between the platform and the retailer’s own servers. Inbound partner files move to where internal systems read them, while files those systems produce move to the appropriate partner pickup folders.

A Year Later, More Traffic and Nothing to Scale

With the cutover complete, the retailer replaced a server it had to defend with a platform it only has to configure.

• The in-house Windows FTP server is retired, and every external FTP transaction with suppliers and customers runs through Files.com.
• Partners kept their scripts and folder conventions. Nothing on the partner side had to be rebuilt.
• The ICT team no longer patches, monitors, or secures an internet-facing FTP server.
• The exchange kept growing after it moved. Overall platform usage was up year over year: growth the retailer no longer had to scale, patch, and defend an external endpoint to carry.

The Perimeter Moved First

The lesson in how the retailer did it is the part worth carrying away. It did not have to modernize everything at once. Moving the external endpoint onto Files.com secured the perimeter first, while the partner scripts on one side and the internal systems on the other kept working as before. The riskiest piece of infrastructure went away, and nothing that depended on it had to change.