Hot Topic Puts Oracle Fusion First in Its Phased Move From Red Hat Linux 6 to Files.com

Hot Topic, Inc. is the leading omni-channel merchandise destination for entertainment and music fans. Through three brands, Hot Topic, BoxLunch, and Her Universe, the company sells licensed apparel, accessories, and collectibles across roughly 900 stores in North America and a digital commerce platform, with around 10,000 employees behind it. Nearly everything it sells is licensed from someone else: the company negotiates arrangements with movie studios, musical artists, and graphic artists, 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, Hot Topic put net-new cloud workloads on Files.com first—including Oracle Fusion—then began moving legacy jobs team by team while the old server stayed live.

One Aging Server Under Order Release and Merchandise Visibility

That server ran Red Hat Linux 6 on an aging VMware host. Store systems, supply-chain ETL, EDI and ordering data, MuleSoft integration flows, and vendor accounts all pointed at it. Six ELT servers ran hundreds of nightly jobs against it, and roughly 25 Linux systems, some in the cloud and some on-premises, connected to it.

The cost was concrete. When the server went down, order release for the order management system went down with it, and merchandise visibility followed, because the files it carried feed multiple downstream systems at once. A retailer that cannot release orders or see its merchandise is not having an infrastructure problem; it is having a business problem.

And the machine itself had run out of road.

The hardware was end of life and end of support, a standing security risk that could not be patched away. Worse, it would not work with the current systems the company was moving toward, which made it a ceiling on everything Hot Topic wanted to change next.

Nearly 140 Accounts and Scripts Written for Systems That No Longer Exist

Getting off it was another matter, and the reasons it had survived this long were real. The server carried nearly 140 accounts, and before any of them could move, ownership had to be traced team by team across six teams; about 120 accounts proved to be active. Many of the legacy scripts had been written jointly for Hot Topic and a sister retailer it once shared systems with, and referenced systems that were no longer in service, so a portion of the estate 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. Hot Topic 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. Hot Topic standardized on Files.com as 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.

“We have been leveraging Files.com for all of our net-new processes, including this new Oracle Fusion financial system that we're building out.”

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 roughly 7 TB sitting on it, only about 10% 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 Hot Topic's branded domain.

The ERP Went Live, and the Load Came With It

With the phased program in production, Hot Topic 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 from under 50,000 to more than 400,000, and by January 2026 they ran at nearly one million a day, roughly forty times the level of early 2023.
• Production inventory processing runs through the native Files.com MuleSoft connector, which Hot Topic's own testing showed to be faster than the standard SFTP transfers it replaced.
• All three brands, Hot Topic, BoxLunch, and Her Universe, exchange files through one governed platform, with roughly 25 internal systems connected to it.

The legacy Red Hat server remains live for workloads not yet migrated, with major CASFTP 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 Hot Topic was whether an end-of-life 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 Hot Topic'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.