A Global Cosmetics Company Replaced Progress MOVEit Without Pausing Latin American Shipping

A global cosmetics company develops and manufactures its own skin care and cosmetics and sells them through independent consultants in dozens of markets.

A business built that way runs on file exchange. The manufacturing group trades new formulas and bid requests with raw-material vendors. Regional offices move payroll and supplier data. And in Latin America, the offices that get product onto trucks do it by file: an order and a shipping ticket go out to the carrier, and a tracking file comes back. When the company committed to a cloud-native infrastructure strategy, all of that file movement was running on a platform that could not make the trip.

An Aging MOVEit Estate Ahead of a Cloud Migration

For years, Progress MOVEit Secure Managed File Transfer, running on the company's own on-premises servers, was the primary tool for moving data. Around it sat the workarounds that accumulate around an aging platform. Payroll staff in one Asian market opened a MOVEit folder every day and pulled their file out by hand. A delivery to a health-services provider went out over manual SFTP. Other files were scattered across on-premises shares, SharePoint Online, and Teams, with little automation connecting any of it.

The company wanted access rebuilt on the corporate directory, with accounts provisioned and revoked from Azure Active Directory instead of administered on the transfer platform itself.

The deciding factor was the calendar: the data center MOVEit ran in was being closed, under the corporate mandate to go cloud native. The platform was aging, and it was losing its home on a deadline.

Shipping Traffic That Could Not Pause for a Migration

What made the move hard was that the MOVEit estate was not one workflow. It was dozens, each configured differently, and the most important of them could not stop.

That carrier exchange ran across four countries, with every job configured differently and files arriving throughout the day. Around it ran the rest of the estate: an SFTP sync with Kallik, the company's content-management platform; a recurring backup retrieval from Tenrox, one of its software vendors; the Asian payroll flow; and supplier data for a Latin American market. The file shares in three Latin American countries that many of these jobs read from and wrote to were staying on-premises, so whatever replaced MOVEit had to reach storage that lived behind the firewall.

The replacement had to speak the protocols these jobs already used, chiefly SFTP. It had to reach on-premises shares from the cloud without exposing them. It had to run the archive cycles and schedules that people had been handling by hand. And it had to rebuild access on the corporate directory instead of a local account list. The company selected Files.com to be that platform.

One Agent, Every Workflow, and a Parallel Run With MOVEit

Files.com became the single transfer platform, with one piece of infrastructure on the company's side underneath it: a Files.com Agent installed on a jump server in AWS, connecting outbound to Files.com and brokering between the cloud platform and the regional file shares in Latin America. The shares were never exposed to the internet, and the shipping jobs kept reading and writing the storage they always had.

The carrier workflows were rebuilt as SFTP jobs driven by Files.com Automations. Files.com archived each day's files nightly, so carriers opened folders each morning containing only the current day's work. A single carrier's working folder held thousands of files, with new uploads arriving throughout the day.

Recurring vendor and regional feeds moved onto the same platform. The recurring Tenrox backup ran as a scheduled sync: the first run took hours to move the full backup, and every run since has finished in minutes because the sync moves only what changed. The Asian payroll file stopped being fetched by hand. The payroll team got a permissioned user and folder access, and the file is simply there.

Access was rebuilt at the same time. Sign-in runs through single sign-on against Azure Active Directory, with users provisioned from the directory rather than added by hand on the platform.

The cutover ran workflow by workflow, behind a parallel run. One country's shipping suppliers moved first, then the next country's, then the vendor feeds, one at a time, with MOVEit still running underneath. The carrier workflows went live on Files.com in September 2024, and MOVEit was disabled the same month, at the end of the parallel run.

MOVEit Disabled on Schedule, With the Manual Work Gone

With MOVEit off, the company had replaced an on-premises transfer estate held together by manual handling with a single cloud platform, on the schedule the migration required.

• MOVEit is fully decommissioned. The transfer platform left the closing data center on schedule, and there is no on-premises MFT server left to run.
• The daily manual handling is gone. Nobody in the Asian office pulls the payroll file out of a folder by hand anymore, and the health-services delivery moved from manual SFTP to a scheduled, permissioned workflow.
• Outbound connections expanded across trading-partner transfers, syncs, mounts, and automations. The carrier exchange, the backup retrieval, and the vendor feeds run on schedules, not on people.
• Access is governed. Accounts are provisioned from the corporate directory, so the people who hold accounts are the people who actually use the platform.

The larger result is that the estate became a pattern instead of a pile. Adding a carrier or a vendor feed is now a connection and an automation on a platform the team already runs, not a new project. The architecture has already proved portable: when the company later moved the underlying on-premises shares to Amazon S3, the Agent remained in AWS and the workflows above did not change. And demand inside the company has followed, with more teams asking to bring their external file exchange onto Files.com.

A Transfer Platform That Moves With the Company

Today, when a Latin American office has an order on a truck, the shipping ticket goes out and the tracking file comes back through Files.com, on schedules nobody watches, into folders that clean themselves up overnight. The payroll contact in Asia opens a folder they are permissioned into instead of fetching a file from a server in a data center that was being shut down. That is the distance traveled: the file movement the company depends on no longer lives on an aging platform in a closing data center, and when the next storage move or the next market comes, the workflows are already built to survive it, because Files.com sits between the storage and the work rather than inside either one.

The company never ran a big-bang cutover. A legacy MFT replacement does not have to be a leap. It can be a sequence.