Ediwise Is Retiring Ipswitch WS_FTP Through a 12-Month Parallel Run

Ediwise sells paper inventory software and EDI transaction services into the pulp-and-paper supply chain. Over 450 newspapers and 25-plus mills and warehouses rely on it to manage inventory and to exchange the documents that move paper: X12 shipment manifests, invoices, and purchase orders, alongside the papiNet XML standards Ediwise itself helped write. The company has spent more than 20 years 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 Ediwise, 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.

Ediwise 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 Ediwise 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 Ediwise's EDI workflows behind it.

The server was aging, and it was a single point of failure. Every trading document passed through one box that Ediwise had to run, patch, and keep alive itself. When that server had a problem, the problem was not an IT ticket. It was the service itself: a mill's shipment manifest or a newspaper's purchase order that did not move, for a company whose entire pitch is that those documents always move. 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 had survived this long because it 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, that was not a risk worth taking. So the server stayed.

The Replacement Had to Speak the Old Protocols

What Ediwise 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 Ediwise'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 Ediwise maintained sat underneath the whole EDI business.

Ediwise 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.

Ediwise 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, Ediwise 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. Ediwise 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.

The Single Point of Failure Is Being Phased Out

With Files.com carrying partner traffic, Ediwise began replacing a server it had to keep alive with a managed platform, removing the one place its business could break as the migration progressed.

• EDI traffic moved to Files.com no longer runs through a server Ediwise has to maintain. Ediwise 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 Ediwise has to keep running. That is the operating model Ediwise is leaving behind: a service sold on documents always arriving, delivered through one aging machine the company maintained itself.

The lesson in how Ediwise 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. Ediwise 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 Ediwise is retiring WS_FTP: cohort by cohort, while the business keeps moving paper.