Jason Group Begins Replacing FileZilla, WinSCP, and 15 Regional FTP/SFTP Servers With Files.com

Jason Group brings together two global manufacturing businesses: Osborn, which makes surface treatment and finishing tools, and Milsco, which designs and manufactures seating for OEM customers. Together, they employ 4,400 people across North America, Europe, and Asia.

A manufacturer with that footprint runs on file exchange. Suppliers send EDI documents that feed the group’s SAP environment. SAP generates delivery files that go out to customers over FTP and SFTP. In all, roughly 200 external vendors and customers exchange files with the group. How those files moved was the problem.

End-of-Life Servers, Free Tools, and Deliveries Nobody Could Confirm

The most visible failure landed on customer deliveries. SAP produces files that must reach customers over FTP or SFTP, and the in-house scripts that carried them had broken. Staff were uploading the files by hand, and nothing recorded whether a delivery had actually happened. There was no log, no alert, and no way to answer a customer who asked where their file was.

“And we don't have any visibility. Whenever it sends a file, we don't have any logs or email alerts saying a file has been sent.”

Behind that workflow sat the estate it depended on: roughly 15 on-premise FTP/SFTP servers spread across North America and Mexico, Europe, and Asia, with FileZilla and WinSCP serving as the free SFTP layer for inbound EDI from suppliers. The servers had reached end of life, so keeping them safe meant continuous patching, on every machine, in every region. That work fell on a global infrastructure and cybersecurity team of about ten engineers. And because partners connected to those machines directly, the group was presenting internal servers to outside parties every day the estate ran.

The diagnosis was bigger than one broken script. Partner file exchange had outlived the infrastructure it grew up on, and the cost showed as patching hours on one side and blind deliveries on the other.

Two Hundred Partners Who Could Not All Move at Once

None of it could be swapped in a single move. The estate had grown up region by region, and North America, Europe, and APAC each carried their own configurations. Roughly 200 counterparties held live connections into it, and the inbound EDI those connections carry is what keeps SAP supplied. A replacement that forced every partner to change at once, or that interrupted those feeds, was not a replacement the business could take.

So the constraint wrote the requirements. The new platform had to speak the protocols partners already used—SFTP, FTP, and AS2—so they could continue using familiar transfer methods. It had to sit outside the network, so partners stopped connecting to internal servers. It had to log and confirm every file movement, because the old estate never did. And it had to absorb the estate one regional connection at a time. The group was already moving infrastructure services to the cloud wherever it could; this became the next candidate.

“From a security standpoint, we expose our internal servers to partners.”

Jason Group selected Files.com and designed a repeatable migration pattern: prove one configuration, then apply it to each region in turn.

One Test Instance, Then the Same Pattern Region by Region

Files.com was selected to become the single exchange point between Jason Group and its trading partners: one cloud platform in place of 15 region-specific servers.

Kumar’s team designed the migration to be repeatable. The plan called for a single test instance capable of both sending and receiving files, with Files.com support alongside the team as it proved the pattern. That same configuration could then be rolled out across the regional connections, phased by region, so the differences in North America and Mexico, Europe, and APAC could be absorbed on their own schedules rather than reconciled all at once.

Three things make the pattern hold. Under the design, partners connect to Files.com over SFTP, FTP, or AS2 on the group’s own branded domain, allowing them to keep using familiar protocols without touching an internal server. The EDI platform reaches Files.com through a single connection, with roughly 200 counterparties behind it, so supplier files keep feeding SAP. Files.com also records file movements in its activity trail and sends email notifications, bringing delivery confirmation into the platform instead of requiring another in-house script.

Visibility Now, With Server Retirement Phased by Region

Jason Group is already using Files.com’s activity trail and email notifications. The broader retirement of its 15-server estate is a phased regional migration rather than a completed, synchronized cutover.

• Whether a customer file went out is now a lookup, against a prior state with no logs and no confirmation of any kind.
• As connections move, partners reach Files.com on the group’s own domain rather than servers inside the network, taking internal infrastructure off the partner-facing perimeter.
• Each retired server removes another end-of-life machine that the ten-engineer global team would otherwise have to keep patched by hand.

The result that compounds is the migration pattern itself. Once the first instance is proven, the payoff is straightforward: The next regional connection is not a new project; it is the proven test configuration applied again. That is how a 15-server, 200-partner estate can move onto one platform without a synchronized cutover that no manufacturer could schedule.

One Proven Pattern Instead of One Coordinated Cutover

Jason Group’s migration does not depend on North America, Europe, and APAC changing at the same moment. Each region can move when its own configuration and partner connections are ready, while the same Files.com pattern carries forward.

What Jason Group established is the part worth carrying away: a multi-region estate serving hundreds of partners does not need one coordinated cutover. It needs one configuration, proven once on Files.com, and applied region by region until the last server has nothing left to do.