Michelin Is Replacing IBM DataPower With Files.com, One Partner Flow at a Time

Michelin is a global tyre and mobility manufacturer, supplying tyres around the world for everything from bicycles to earthmovers to commercial aircraft. Its manufacturing, suppliers, and logistics partners span the regions it serves.

An operation built that way runs on file exchange. Inside Michelin, that job belongs to the enterprise integration team, which owns middleware, file transfer, and external partner connectivity for the whole group. Files arrive from business partners and get integrated into Michelin's systems; files go out to partners for processing. It is continuous, production-critical traffic, and every byte of it has to cross the boundary between Michelin's network and the outside world.

For years, all of that traffic crossed through a single piece of hardware.

The Whole Partner Perimeter Ran Through One Appliance

Communication between Michelin's network and external networks ran through IBM DataPower, an on-premises appliance handling SFTP connections and file routing, with per-flow services polling for files and Michelin's internal middleware built around it. Then Michelin decided to stop using DataPower.

That decision turned the appliance from infrastructure into a liability. Every production partner flow depended on hardware the company no longer wanted to run. Worse, the estate was growing in the wrong direction: partner integrations kept being added, and each new flow built on DataPower deepened the dependence on a box that had to go.

A Perimeter You Cannot Cut Over in a Weekend

The obvious fix, a single synchronized cutover, was never realistic. On the other end of every flow sits an external counterparty with its own systems and its own schedule. Partners pull production files of 300 to 700 MB each. Internal middleware collects inbound files every few minutes. Cutting an entire external exchange perimeter over in one event would mean coordinating all of those partners at once and betting production traffic on the event going well. For a manufacturer operating continuously across three regions, that bet was off the table.

So the replacement had to meet a specific set of requirements. It had to be a production-grade SFTP endpoint under Michelin's own name, one that partners could reach with the standard clients they already use. It had to serve teams and partners in Asia-Pacific, Europe, and the Americas without taxing whichever region sat farthest from the storage. It had to plug into Michelin's own identity system rather than duplicate it. It had to keep every flow isolated, so each one could move independently. And it had to run alongside DataPower for as long as the migration took.

Michelin chose Files.com to be that endpoint.

Files.com Plus Axway CFT: A Landing Zone for Every Flow

The design made Files.com the external face of Michelin's file exchange and Axway Transfer CFT the internal drain, with each migrating flow moving between them.

Michelin set up two production instances, one for Europe and one for North America, behind Michelin-branded custom domains. Partners connecting over SFTP see Michelin, not a third-party vendor. Top-level folders were zoned for Asia-Pacific, Europe, and the Americas, with Files.com per-folder storage regions keeping each zone's data local.

Michelin integrated Files.com with its NetIQ identity system through SAML single sign-on and just-in-time provisioning, avoiding the need to replicate its corporate directory into the platform.

Every use case received its own dedicated directory and service account. No project could overwrite another's files, and each flow could be built, tested, and retired without touching its neighbors. That isolation made a flow-by-flow migration possible in the first place.

On the internal side, Axway CFT connected to Files.com over SFTP, collected each flow within minutes, and moved it into Michelin's systems. Meanwhile, DataPower kept serving whatever had not yet moved. The two stacks continue to run side by side, and each flow migrates when it is ready.

Every Flow That Leaves DataPower Lands on a Pattern That Already Exists

With the pattern in production, Michelin replaced a cutover it could never have scheduled with a retirement that happens as ordinary work.

The retirement remains underway. DataPower continues serving flows that have not yet moved, while new partner exchanges land on Files.com and existing ones migrate progressively.

• Moving a flow off DataPower is routine rather than a project: a directory, a service account, and a CFT job definition, against a platform that is already standing. The next flow follows the same pattern as the last one.
• Partners on three continents pull 300 to 700 MB production files directly over SFTP, against storage in their own region, under Michelin's own domain, with no appliance behind it for Michelin to maintain.
• Resident storage hovers around 250 GB even while both instances carry heavy traffic, because files do not rest there. They land, CFT collects them within minutes, and they move on. The platform is a transit point for production data, not a place it accumulates.

Retiring an Appliance as Ordinary Work

Today, when a Michelin team stands up a new partner exchange, it lands on Files.com. The external perimeter is moving away from an appliance in a data center, per-flow polling services, and a middleware estate coupled to hardware with no future, toward a service that Michelin's own middleware drains on its own schedule.

The lesson in Michelin's approach is that the appliance never had to go first. Retiring a box that carries an enterprise's entire external file-exchange perimeter does not require one synchronized cutover; it requires a destination sound enough to run in parallel for as long as the move takes, so that every flow can leave when it is ready, and the old system simply runs out of work.