CoLinx Replaced MOVEit Cloud With Files.com Without Asking 200 Partners to Change a URL

CoLinx is a shared-services company with an unusual charter. Four premium industrial manufacturers, among them SKF and Timken, founded it in 2001 to run their logistics and e-commerce operations jointly, sharing the cost of moving goods instead of each building the machinery alone. Today 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: roughly 1,200 people, about 1.6 million pounds of goods shipped every day, and a 1.3-million-square-foot distribution hub in Tennessee sitting inside a foreign trade zone.

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 CoLinx, its owner-manufacturers, their distributor channel, and carriers all day long. By late 2021, roughly 200 customer and trading-partner accounts exchanged files with CoLinx, 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 5 to 15 minutes: pick a file up from one location, rename it, drop it at another. Customers uploaded shipping data and customs forms, CoLinx 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 Matt Garren, CoLinx'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 CoLinx's data was restored, and the disruption caused real problems in the meantime. Around the same period, major vulnerabilities were publicly disclosed in the product. A partner exchange hub cannot be pulled off the internet; being reachable by 200 outside organizations is its job. CoLinx was left running its customs documents and every partner relationship through a system that had to stay internet-facing, from a vendor whose reliability and security record had broken their confidence. That was the condition every day the platform kept running.

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

Two Hundred Partner Accounts, and None of Them CoLinx's to Reconfigure

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

Each of the roughly 200 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: CoLinx observed around 170 SFTP connections opening at once in an afternoon peak and draining to three within a minute, and in the month of the migration the platform carried close to a million transfers moving over 800 GB of data. 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, CoLinx 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 200 outside organizations 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 CoLinx's customer-owned transfer domain, capacity for bursts of machine-driven SFTP connections, and activity history searchable by filename and user. CoLinx 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. CoLinx kept it.

The second decision made the migration nearly invisible from the outside. CoLinx 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 200 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 authenticated to Files.com through a single service account, so hundreds of job definitions shared one host and one credential rather than accumulating variations.

The cutover itself ran in parallel, staged customer by customer, while MOVEit Cloud stayed live. CoLinx 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. CoLinx 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, CoLinx 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 CoLinx's own domain: hundreds of automation jobs and roughly 200 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 5 to 15 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, Matt Garren described the Files.com deployment as operationalized for roughly three years. CoLinx never had to replace the automation estate to escape the platform underneath it, and never had to ask 200 outside organizations to change a thing. The hub could be swapped alone.