An Integrated Logistics Provider Moves Customer Order Exchange to Files.com Without Changing a Single ERP Connection

An Asian integrated logistics provider moves freight across several countries, runs customs brokerage, and operates bonded and non-bonded warehousing. It owns the operation end to end: its own trucking fleet, its own warehouses, its own container freight stations.

The warehousing side of that business runs on its customers' data. A customer's ERP sends an order file; the provider's warehouse management system executes the transaction; a confirmation file goes back for the customer's ERP to collect. Goods move when files move. And for more than a decade, every one of those files passed through a single on-premise FTP server.

The provider moved the integration backbone of its warehousing business to the cloud without asking a single trading partner to change how it connects.

A Server the Provider Chose to Retire, Not Refresh

That server had carried the order flow for more than ten years, and the provider decided its next move would not be another server. The company wanted the exchange on a platform it did not have to operate: no hardware to refresh, no capacity ceiling as file volumes grew, and a record of exactly when each file arrived and left, so a customer's question about an order could be answered from a log.

A second on-premise server carried EDI for one major customer over the GXS network, with production and test environments the provider maintained itself. The provider wanted that connection to run as configuration, with acknowledgements handled on the same platform as everything else, rather than as a server pair of its own. Around both servers, file volumes were growing toward the limit of what the hardware could hold.

Out of the Server Cycle Entirely

Replacing the hardware was the obvious option, and it would have reset the clock without changing anything: the company would still be patching, still securing, still planning capacity, and still buying the next server when this one aged out. The IT lead wanted out of that cycle entirely.

The timing pushed the same way. The provider was moving its wider operations, including its Infor warehouse management system, to the cloud, and its file volumes were outgrowing on-premise capacity.

What made replacement hard was who was connected. Customer ERP systems pushed and pulled order files directly against the FTP endpoint, and the AS2 connection was fully integrated into the major customer's own systems, so it could not be moved to a different protocol. Whatever replaced the servers had to speak SFTP and AS2 exactly as the old machines did, keep each customer's traffic apart from every other's, record precisely when each file arrived and left, and meet the IT lead's first requirement, which was security.

The provider selected Files.com to be that exchange layer.

One Files.com Site Between Customer ERPs and the Infor WMS

The rollout was a fresh build: an SFTP connection for each customer ERP and one AS2 connection. Using Files.com's per-user folder and protocol permissions, each customer got its own inbound and outbound folders, with access locked to those folders and to the protocol that customer used. No customer can see another's traffic.

Files.com kept each SFTP exchange sorted between the customer ERPs and the Infor WMS. Customers sent order files into isolated inbound folders, and the WMS returned transaction confirmations through outbound folders for their ERP systems to collect.

The major EDI customer ran the same order-and-confirmation loop over AS2 through GXS. Files.com handled acknowledgements on the same site, returning a signed digital receipt for every transmission. There was no AS2 server behind any of it, and no self-maintained production and test environments to keep alive.

A custom domain was planned into the cutover so that customer-side scripts would not need rewriting. Customers kept connecting the way their integrations were already written to connect. The resulting traffic is almost entirely machine to machine; people log into the web interface only to confirm that a file arrived, usually when a customer asks.

No Servers to Patch and a Timestamp on Every File

With every connection cut over, the provider replaced two servers it had to operate with a platform it does not.

• The order flow between customer ERPs and the Infor WMS runs on a platform the provider does not have to keep alive, so keeping goods moving no longer depends on keeping a server up.
• There is no hardware to refresh, no operating system to patch, and no capacity plan to revisit as file volumes grow.
• The EDI connection for the major customer runs as configuration on the same site rather than as a server pair the provider maintains.
• Every file movement is recorded with a precise timestamp, so the provider knows exactly when an order arrived from a client and when a confirmation went back.

That last point was one of the things that set Files.com apart for the provider.

The larger result is repeatable onboarding on the existing Files.com site. The provider is moving everything to the cloud, and its WMS will integrate with most future customers over the same file exchange. Onboarding one requires a set of folders and a credential, using protocols the customer's ERP already speaks, rather than additional server capacity.

The Servers Left and the Customers Never Noticed

Today, one of the provider's customers sends an order the same way it always did: its ERP drops a file on an SFTP endpoint, or transmits over AS2 through GXS, and a confirmation comes back for its system to collect. What changed is everything behind that endpoint. Keeping order files flowing no longer means keeping a server alive, and a question about whether a file arrived is answered from the Files.com web interface, timestamp included.