A Logistics Shared-Services Company Replaced MOVEit Cloud With Files.com Without Asking Hundreds of Partners to Change a URL

An industrial logistics shared-services company runs logistics and e-commerce operations jointly for a group of industrial manufacturers, sharing the cost of moving goods instead of each building the machinery alone. It operates warehousing, transportation, US foreign trade zone operations, and the e-commerce and system-to-system connections that let industrial distributors do business with multiple manufacturers through a single channel. The operation is large: more than a thousand people and a distribution hub inside a foreign trade zone that ships more than a million pounds of goods every day.

A business built to sit between other companies runs on documents that cross company boundaries. Shipping data, customs forms, invoices, and EDI messages move between the company, the manufacturers it serves, their distributor channel, and carriers all day long. By late 2021, hundreds of customer and trading-partner accounts exchanged files with the company, most of them driven by scheduled jobs rather than people. All of that traffic passed through one internet-facing platform: MOVEit Cloud.

Every Exchange Ran Through a Platform They No Longer Trusted

MOVEit Cloud, the Ipswitch and later Progress product, was the SFTP and file-sharing hub. Behind it, two on-premise servers ran hundreds of scheduled MOVEit Automation jobs, firing every few minutes: pick a file up from one location, rename it, drop it at another. Customers uploaded shipping data and customs forms, the company downloaded and processed them, and results flowed back the other way. The most critical of those loops carried shipment orders through the foreign trade zone, the workload the company's IT automation lead ranks highest for the need to be accurate, backed up, and fast.

Then the vendor failed them. MOVEit Cloud suffered a massive outage. Service came back within about ten hours, but a historical resync ran for weeks before all of the company's data was restored. The company wanted its partner exchange on a hub whose reliability and security record it could stand behind, and it wanted the move made without disrupting a single partner.

There was a second cost being carried alongside it. For a handful of trading partners, the company maintained AS2 connections fronted by a DMZ: an extra protocol with awkward certificate handling, kept alive to serve a few counterparties.

Hundreds of Partner Accounts, and None of Them the Company's to Reconfigure

Losing confidence in the hub was one thing. Replacing it was another, because almost nothing attached to it belonged to the company alone.

Each of those partner accounts carried its own connection configuration, maintained by someone else's IT department. Hundreds of job definitions across the two automation servers pointed at the hub. The traffic pattern punished weak infrastructure: SFTP connections opened in bursts at an afternoon peak and drained to almost nothing within a minute, and in the month of the migration the platform carried hundreds of thousands of transfers. A big-bang cutover across that many external parties was never realistic. One missed configuration strands a partner mid-shipment.

The replacement also had to preserve two guarantees the incumbent already covered. When a file needed reprocessing, the team had to find the upload fast enough to pull it back through. And when a third party claimed to have sent a file that never arrived, the company had to prove the negative: search all activity by filename and user and show the file was never received.

So the specification was clear before any product entered it: take over internet-facing exchange without forcing any outside organization to change anything, absorb bursts of machine-driven connections, and keep a searchable record strong enough to settle a dispute. Files.com fit it with support for the company's customer-owned transfer domain, capacity for bursts of machine-driven SFTP connections, and activity history searchable by filename and user. The company selected Files.com to be that hub.

Swap the Hub, Keep Everything Pointed at It

Files.com became the internet-facing exchange layer swapped in underneath the estate, while the estate itself stayed put.

The first decision was what not to replace. The on-premise MOVEit Automation scheduler worked, and its hundreds of job definitions embodied years of routing and renaming logic. The company kept it.

The second decision made the migration nearly invisible from the outside. The company fronted the exchange with its own branded transfer domain, a DNS alias pointing at its Files.com site. Every job and every partner configuration addresses that domain rather than any vendor's hostname. Hundreds of job definitions and partner setups came across without a URL rewritten, and the address has not changed since.

The third kept the automation estate uniform. Every scheduled job on both servers pointed at the same Files.com host, so hundreds of job definitions kept one consistent pattern rather than accumulating variations.

The cutover itself ran in parallel, staged customer by customer, while MOVEit Cloud stayed live. The company deliberately moved its most complicated partners first, because those take longest, and left the smaller ones for later, when the pace picks up. Its largest client ran a one-week test period before full cutover.

The same move retired AS2 entirely. The remaining AS2 trading partners were converted to SFTP, and the DMZ that fronted the protocol went with it.

The two evidence guarantees carried over onto the new platform. Files.com's activity history is searchable by filename and by user, so an uploaded file can be located and pulled back for reprocessing, and a claimed transmission that never arrived shows up as exactly that: no record. The company later extended the same record into self-service reporting, using the Files.com CLI to pull month-scoped activity across the foreign trade zone's users, folders, and files and export it to CSV, with no ticket to anyone.

Simpler Coming Out Than Going In

With Files.com in production, the company had taken the platform it no longer trusted out of the center of every partner relationship, and the estate came out of the migration simpler than it went in.

• The swap happened behind the company's own domain: hundreds of automation jobs and partner configurations moved to Files.com without a URL rewritten anywhere.
• AS2 is gone, and the DMZ that fronted it went with it. Every external exchange now runs over SFTP through Files.com, one protocol with no certificate handling to maintain.
• The machine-to-machine load runs as routine. Jobs still fire every few minutes, and the afternoon connection bursts pass without incident.
• Proving the negative is a search. When a partner claims to have sent a file, the activity record answers by filename and user, and foreign-trade-zone audit extracts go straight to CSV through the Files.com CLI.

The immediate result was escaping a distrusted platform with no partner-facing disruption. The compounding one is structural: every new trading partner now lands on the same SFTP pattern against the same hub, behind the same domain, and the exchange has kept growing on that footing since.

The Only Piece That Moved Was the One They Didn't Trust

By August 2025, the Files.com deployment had been operationalized for roughly three years. The company never had to replace the automation estate to escape the platform underneath it, and never had to ask hundreds of outside organizations to change a thing. The hub could be swapped alone.