A Specialty Retailer Moved Critical Traffic Off Fortra Globalscape EFT Without Rewriting Integrations or Stopping Its Warehouse

An omnichannel specialty retailer runs dozens of retail stores, a wholesale dealer network, and a digital-first e-commerce channel, all fulfilled from a single warehouse.

That last fact shapes how the whole company runs. When one warehouse ships for every store and every online order, the business lives on files moving between systems. Point-of-sale feeds go out to stores overnight. Orders and pick waves flow into the warehouse. Catalog and inventory data lands in the e-commerce platform. For years, nearly all of that traffic terminated on a single on-premises SFTP server.

A Globalscape Server Carrying More Than It Was Built For

The server was a Fortra Globalscape EFT instance in the retailer's data center, and it had accreted production integrations for years: POS feeds, warehouse orders, e-commerce file delivery, exchanges with third parties, dealer downloads. It was never designed to carry that much, and the problem was not any one integration. The server itself had been outgrown.

Then it began to fail where the business could least afford it. The PredictSpring point-of-sale application stopped reliably retrieving its files. Connection tests passed while the actual downloads stalled, and those were files that had to reach stores overnight so they could open the next day. Salesforce Commerce Cloud could not connect to the on-premises server at all. And latency between the server in the data center and the warehouse management systems in another state degraded the MuleSoft integration that feeds the warehouse, which put shipping itself in question.

Too Deep in the Estate to Replace Under Pressure

A server like this survives because everything points at it. Years of integrations across POS, ERP, warehouse management, and e-commerce terminated on it, most of them orchestrated through MuleSoft. Dozens of accounts and years of folder paths had accumulated on it, and integration code depended on every one of them.

The obvious fix, standing up a new platform and rewriting every integration to point at it, was not available. Stores had to open every morning with their files delivered, and the warehouse could not stop shipping while anyone rebuilt integration code. Whatever took over the failing paths had to do it without waiting on a rewrite, preserve the integration code and file paths already delivering files in and out, keep the warehouse protected through the transition, and not become another single point of failure.

The retailer brought in Files.com to mount the old server behind it and move the failing paths one at a time, starting with POS.

Put Files.com in Front of the Old Server, Then Move the Traffic

The move that made the migration possible was not replacing the old server first. It was mounting it. Using Files.com's remote server mount, the team configured the Globalscape server as a remote server and mounted it as a folder in Files.com. PredictSpring then pointed at Files.com, and Files.com passed every operation through to the old server in real time. The integrations that delivered files in and out kept running exactly as they were. Nothing was rewritten.

The warehouse path came next, and it was too critical for a hard cutover. The MuleSoft warehouse integration ran on Files.com in parallel, with the on-premises server retained as a fallback, so warehouse operations stayed protected while the new path proved itself. Once it had, POS, Salesforce Commerce Cloud, and warehouse traffic all moved to Files.com production.

Two more pieces completed the production architecture. The e-commerce platform connected through the Files.com Agent deployed on-premises, which reaches internal systems over an outbound-only connection, so no new inbound path into the data center was needed. And the MuleSoft integration moved to an SSH-key-authenticated SFTP connector, removing a longstanding ceiling: the prior connector path failed on any file over 10 MB.

The three critical production paths had moved, but Globalscape remains in the estate for legacy batch and overnight processes, vendor and dealer access, SMB shares, and the remaining older connections.

Back to Operational Stability, at Hundreds of Thousands of API Calls a Day

With the cutover complete, the retailer had moved its critical production retail paths off a failing single-server architecture and onto a managed platform, and the difference showed up where the failures had.

• The POS connection failures ended, Commerce Cloud connected, and the warehouse integration stabilized. POS, e-commerce, and warehouse workloads have run on Files.com continuously since the cutover.
• The warehouse never stopped shipping. The parallel run kept operations protected through the entire migration.
• Files.com now carries hundreds of thousands of API calls a day through the MuleSoft integration driving the warehouse's 6 River Systems robots: a stream of small pick-wave files feeding the one warehouse that fulfills dozens of stores plus the e-commerce channel.
• Files over 10 MB transfer without failing on the SSH-key SFTP path now in production.

The quieter result compounds. Because the old server can sit mounted behind Files.com, moving an integration is now a re-point rather than a rewrite: the code that delivers files stays intact while the path underneath it changes. The pattern that moved the POS feed first is one the retailer can apply to any integration, on its own schedule.

The Old Server Never Had to Go First

The instinct when a legacy MFT server starts failing is to plan its replacement: a migration project, a rewrite of everything that points at it, a cutover weekend. The retailer did the opposite. Files.com went in front of the failing Globalscape server, took over the paths that were breaking, and let the traffic leave one integration at a time, while stores kept opening and the warehouse kept shipping.

Today Files.com is the file plane between the retailer's point-of-sale, ERP, warehouse, and e-commerce systems. A store's overnight files arrive without anyone checking whether a scheduled job stalled. The warehouse robots get their pick waves at whatever volume the day demands. And the critical production workloads that once depended on a server grown past its design now run on a platform built to carry them.