A Specialty Retailer Puts Oracle Fusion First in Its Phased SFTP Consolidation Onto Files.com

A North American specialty retailer sells licensed apparel, accessories, and collectibles across several hundred stores and a digital commerce platform, under multiple brands. Nearly everything it sells is licensed from someone else, and much of its own-brand merchandise is manufactured overseas.

A business like that runs on file exchange. EDI, inventory, and ordering data move between store systems, e-commerce, and the supply chain every night. Invoices flow into financial systems. Vendors and outside developers push artwork and product imagery in. And for years, nearly all of it crossed a single in-house SFTP server.

Rather than force every workload through a big-bang cutover, the retailer put net-new cloud workloads on Files.com first, Oracle Fusion among them, then began moving legacy jobs team by team, with each team cutting over when its own jobs were ready.

One In-House Server Under Every Nightly Job

Store systems, supply-chain ETL, EDI and ordering data, MuleSoft integration flows, and vendor accounts all pointed at that one server. Six ELT servers ran hundreds of nightly jobs against it, and dozens of systems, some in the cloud and some on-premises, connected to it.

The stakes were concrete. Order release for the order management system and merchandise visibility both ride on the files that layer carries, because those files feed multiple downstream systems at once. The retailer wanted its file layer on a platform every system could reach, without the company running the server underneath it.

The in-house server also would not work with the cloud systems the company was moving toward, which made it a ceiling on everything the company wanted to change next.

More Than a Hundred Accounts, Owned by Six Teams

Getting off it was a program, not a repoint. The server carried more than a hundred accounts, and before any of them could move, ownership had to be traced team by team across six teams; most proved to be active. A portion of the legacy scripts needed re-engineering rather than a simple repoint. And because order release rode this layer, the business could not tolerate an interruption. A big-bang cutover was never an option.

What forced the issue was the direction of the estate itself. The retailer was building out a new Oracle Fusion financials system and pushing its integrations cloud-to-cloud, and the old server could participate in none of it. The replacement had to do what a lift-and-shift could not: take net-new cloud workloads immediately, run alongside the legacy server for as long as each team needed, keep speaking SFTP for the jobs that already did, give the ETL and MuleSoft teams a supported API path, and keep every flow auditable. The retailer made Files.com that layer.

Net-New Workloads First, Then One Team at a Time

Files.com became the transfer layer every system could reach: SFTP for the jobs that already spoke it, and the REST API and a native MuleSoft connector for the integration teams. That reach is what made a phased retirement possible, because no workload had to wait for any other.

The sequencing put net-new work first, so the highest-stakes new system never touched the old server at all.

The XStore team's workflows migrated next. The MuleSoft team then tested the native Files.com MuleSoft connector against standard SFTP, found it measurably faster in its own testing, and went live on it for production inventory processing. Each team validated its own processes before cutover, using a development account and a separate Files.com child site, so testing never ran against production flows.

The old server's history was deliberately treated as disposable. Of the terabytes sitting on it, only a small fraction was expected to move; everything else was provisioned fresh on the platform. The program migrated workloads, not archives.

Separate accounts on each side made Oracle Fusion flows auditable end to end, while Active Directory group permissions and jailed root folders gave internal users appropriate access and confined each vendor and outside developer to its own folder tree on the retailer's branded domain.

The ERP Went Live, and the Load Came With It

With the phased program in production, the retailer put its next systems on a supported cloud file layer while the legacy migration continued.

• Oracle Fusion financials went live with Files.com as the ERP's file layer, entirely as net-new work that never depended on the legacy server. On go-live day in September 2025, daily API calls to the platform jumped sharply, and they have kept climbing since.
• Production inventory processing runs through the native Files.com MuleSoft connector, which the retailer's own testing showed to be faster than the standard SFTP transfers it replaced.
• All of the company's brands exchange files through one governed platform, with dozens of internal systems connected to it.

The migration continues team by team, with major legacy SFTP and MuleSoft workflows still to move. Every net-new file integration and every cloud-to-cloud transfer now lands on Files.com by default. Each phase of the program shrinks the legacy server's footprint, and no new work is ever added to it.

A File Layer That No Longer Dictates What Can Change

For years, the question in front of any systems change at the retailer was whether the in-house server could carry it, and for anything cloud-based the answer was no. For net-new systems, that question is gone. A new ERP went live with Files.com underneath it without waiting for the old server to be emptied. The MuleSoft team runs production inventory integrations through a supported connector instead of standard SFTP. And each team that still owns a legacy job moves it when the team is ready, not on a cutover weekend imposed on everyone at once.

That is what the retailer's program demonstrates: a business-critical SFTP estate does not have to be replaced in one synchronized cutover. Land the net-new work on Files.com first, migrate team by team, and let the old server run alongside until its last job moves.