A Jewelry Retailer Retired Progress MOVEit Mid-Migration and Multiplied Its Outbound Connections

A US jewelry retailer sells fine jewelry through a multi-state store footprint and an ecommerce channel. What makes the business unusual is that it also operates an in-house consumer credit business, and that comes with a consequence for IT: Credit and collection data carrying PII and PCI moves between the retailer, its credit vendors, and its collection partners every day, on top of the sales, reporting, and supply data that its stores produce.

File Movement Ran on Vendor FTP Boxes, MOVEit, and Hand-Run Scripts

Before Files.com, that exchange was a patchwork. Credit vendors hosted their own external FTP servers, and the retailer pulled files down from each of them onto a local server. Transfers ran through Progress MOVEit SFTP and an on-premise server full of scheduled batch scripts, held together with PowerShell. Sales transaction reports left the on-premise ERP as CSV files that someone moved to an S3 bucket manually. Internal file sharing lived on Dropbox, a separate consumer product outside all of it.

IT wanted every transfer across those pieces logged in one place and automated end to end. File movement at the retailer had accumulated one flow at a time, and the team wanted one layer to govern the whole.

Each piece worked in isolation. No single tool in it could bridge the on-premise ERP and file server on one side and cloud storage on the other, and the external endpoints could not simply be rewritten: They belonged to the vendors. Then the retailer launched a company-wide digital transformation, migrating its infrastructure to AWS and its legacy file server to SharePoint. The IT team put file transfer at the center of that program because the vendor flows had to be governed, monitored, and scaled from one place as connections grew, and because those workflows had to move from on-premise infrastructure into AWS and SharePoint without waiting for either migration to finish.

The Replacement Had to Bridge Both Sides of a Migration in Progress

The requirements described the gap precisely. The new layer had to speak the SFTP and FTP the vendors already ran. It had to reach the on-premise ERP and file server without exposing them to the internet. It had to connect the cloud destinations the company was moving toward, including S3 and SharePoint, before those migrations finished. It had to encrypt and decrypt credit files automatically inside the workflow. It had to log every event into the company's SIEM. And it had to go in flow by flow because production file exchange could not go dark during a cutover.

The retailer selected Files.com to be that layer.

One Agent Inside the Perimeter, One SFTP Front Door for Vendors

Files.com became the single hub between the retailer's on-premise systems, its cloud storage, and its vendors.

Inside the perimeter, a single on-premise Files.com Agent mounts the local file-server paths over an outbound-only connection, so nothing new was exposed to the internet. Protected landing folders keep legacy automations isolated from people working in nearby folders.

For redesigned vendor flows, the direction reversed. Instead of the retailer chasing files across vendor FTP boxes, vendors drop files into the retailer's own SFTP. Files.com Automations route each arrival into the ERP ingest folders and archive the intake daily. The team also replaced interval-based automations with sync-based workflows, so a file moves once, when it arrives, with no trigger logic to maintain. Credit-collection exchanges run through GPG-enabled folders, so files are encrypted and decrypted automatically as they move between the retailer and its partners.

On the cloud side, Files.com Remote Server Mounts connected SharePoint and S3 as folders. The ERP's sales-transaction CSVs now flow to S3 through an automation instead of by hand, while the legacy file server synced into SharePoint during its migration, including terabytes moved into the archive. Files.com also syncs order files from the on-premise supply system to the supplies vendor's FTP so materials ship back to every store. Files.com events post to New Relic over webhooks, giving the SIEM visibility into transfers, automation runs, and logins. Internal sharing moved off Dropbox and onto access-controlled Files.com folders.

The cutover matched the requirement. Legacy FTP systems ran alongside Files.com through the transition, each workflow was tested in parallel, and production moved over one flow at a time.

Outbound Connections Multiplied Without Multiplying the Operating Burden

The operating model made growth additive rather than cumulative: Connecting a new source now means configuring a connection and an automation rather than adding another script on a server. The outbound connection count multiplied in about a year without the estate getting harder to run.

• Dozens of outbound connections now feed the workflows across the production vendor sources, some of which use multiple FTP connections.
• Integrations were live within about a month of activation.
• Progress MOVEit, Dropbox, the batch-script server, and the PowerShell glue are retired, and the Files.com estate runs through a single on-premise Agent.
• Sales data reaches S3 and supply orders reach the vendor without the manual export and trigger logic the old workflows required.

The File Layer Went In Before the Cloud Migration Finished

A credit file used to mean a manual pull from a vendor's server onto a local one. In redesigned vendor flows, it now lands on the retailer's own SFTP, gets decrypted, routed into the ERP, archived, and logged to New Relic without anyone touching it.

The instinct on a project like this is to finish the cloud migration first and fix file transfer after. The retailer did the opposite: Files.com went in while the AWS and SharePoint moves were still under way, bridged the on-premise and cloud sides throughout, and let each flow cut over when it was ready. The transformation did not have to wait for the file layer, because the file layer is what carried it.