An EDI Software Provider Is Retiring Ipswitch WS_FTP Through a 12-Month Parallel Run

A supply chain EDI software provider sells inventory software and EDI transaction services into one industrial supply chain. Hundreds of customers, from buyers to mills and warehouses, rely on it to manage inventory and to exchange the documents that move goods: X12 shipment manifests, invoices, and purchase orders, alongside the industry's own XML standards. The company has spent decades doing B2B EDI integration for this one industry, and it positions itself as the direct liaison between its customers and their suppliers when a transaction fails, because EDI is time-sensitive and someone has to fix it immediately.

That last fact is the one that matters here. For this company, file transfer is not infrastructure that supports the product. It is the product. Every document its EDI services carry rides on the transfer layer, and the company is judged on whether those documents arrive.

The company selected Files.com to replace Ipswitch WS_FTP, but it did not stake live production traffic on a one-day cutover. Instead, it planned a 12-month parallel run that kept the legacy server available while internal users moved team by team.

One Server Carried the Entire EDI Business

That transfer layer was an Ipswitch WS_FTP Server that the company hosted itself on Azure infrastructure. The server did two jobs at once. It was the SFTP and FTP endpoint that trading partners connected to, and it was the integration point for the custom Azure Logic Apps platform that orchestrated the company's EDI workflows behind it.

The server was aging, and every trading document passed through one box that the company had to run, patch, and keep alive itself. For a company whose entire pitch is that those documents always move, the transfer layer belonged on a platform someone else keeps running. Around the server, manual processes handled parts of the EDI exchange with trading partners, including the setup work each new partner required.

Too Wired In and Too Live to Switch Off

The server could not simply be turned off. Trading partners pointed their own systems at it, over SFTP and FTP sessions carrying live production traffic. The Logic Apps platform was built against it. Retiring it in one move would have meant re-pointing every partner and every workflow at once, with business-critical traffic depending on the cutover going right. For a company whose product is the reliable movement of these documents, the replacement had to arrive beside the server, not in place of it overnight.

The Replacement Had to Speak the Old Protocols

What the company needed was specific. The new endpoint had to serve SFTP and FTP natively, so trading partners could keep connecting with the clients and scripts they already ran. It had to integrate with the Logic Apps platform, which was staying: the orchestration layer was the company's own, and it was never the problem. It had to keep each partner's inbound traffic separate. And it had to be a platform someone else operates, so that no server the company maintained sat underneath the whole EDI business.

The company selected Files.com to replace WS_FTP as that endpoint.

A Write-Only Folder per Partner and a Year of Parallel Running

Files.com became the partner-facing endpoint for trading-partner communications. Because Files.com serves SFTP and FTP natively, nothing on the partner side had to be rebuilt: the same protocols, the same clients, the same scripts, pointed at a new home.

The company provisioned each trading partner as its own Files.com user with a write-only inbound folder. A partner delivers documents into its own folder and does nothing else: it cannot read other traffic and it cannot browse the site. Bringing on a new partner became that pattern applied again, in place of manual setup on a server.

Behind the endpoint, the company wired its Azure Logic Apps platform into Files.com as the transfer hub. The workflows that route and process EDI documents did not change. Only the system they collect from and deliver to changed.

The migration itself was built to avoid a cutover day. The company planned a parallel run, keeping the WS_FTP server open for 12 months while internal users moved by team. The dev and QA teams went first, for a quarter or two, with additional teams following as they came up to speed. No partner and no workflow ever depended on a single weekend going right.

Partner Traffic Now Runs Without a Server the Company Maintains

With Files.com carrying partner traffic, the company began replacing a server it had to keep alive with a managed platform, one cohort at a time.

• EDI traffic moved to Files.com no longer runs through a server the company has to maintain. The company does not patch, monitor, or restore the Files.com service, and its uptime is not one team's side job.
• Onboarding a trading partner is a repeatable pattern, a user and a write-only folder, rather than manual setup on a server.
• Partner traffic is separated by construction. Each partner writes into its own inbound folder and reads nothing.
• The EDI line can keep growing without the transfer layer becoming the constraint. Each new partner arrives as configuration, and there is no box underneath to outgrow.

Retiring a Live Server Without a Cutover Day

Today, EDI traffic already moved to Files.com does not pass through a server anyone at the company has to keep running. That is the operating model the company is leaving behind: a transfer layer the company hosted, patched, and kept alive itself.

The lesson in how the company is getting there is the part worth carrying away. A live, partner-facing FTP server with production traffic on it looks like it demands a risky one-day cutover. The company did not take that risk. It stood up Files.com beside the old server, moved its own teams first, and used a year of parallel running to absorb the transition, with Files.com speaking the same protocols on the other side so the work itself never had to change. A legacy FTP server does not have to come out in one night. It can be retired the way this company is retiring WS_FTP: cohort by cohort, while the business keeps moving goods.