Daniel's Jewelers Retired Progress MOVEit Mid-Migration and Tripled Outbound Connections

Daniel's Jewelers has been selling fine jewelry since 1948 and now operates more than 100 stores stretching from Southern California across the southern United States to Florida, alongside an ecommerce channel. What makes the business unusual is that it also operates an in-house consumer credit business. That model has helped carve out a distinct position serving the Hispanic market, and it comes with a consequence for IT: Credit and collection data carrying PII and PCI moves between Daniel's, its credit vendors, and its collection partners every day, on top of the sales, reporting, and supply data that more than 100 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, so Daniel's held a set of other companies' credentials and pulled files down onto a local server by hand. 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, with the risk of duplicate loads whenever a connection dropped and reconnected. Internal file sharing lived on Dropbox, a separate consumer product outside all of it.

None of these pieces shared logging, and none of them were automated end to end. When a file failed to move, there was no central record to show it. File movement at Daniel's had accumulated one flow at a time, and no layer governed the whole.

The estate had survived because each piece worked well enough 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, and vendor-side change control moves slowly. Then Daniel's launched a company-wide digital transformation, migrating its infrastructure to AWS and its legacy file server to SharePoint. The IT team put the file-transfer gap at the center of that program because vendor FTP flows with no logging and no automation could not be governed, monitored, or scaled 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.

Daniel's Jewelers 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 Daniel'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 Daniel's chasing files across vendor FTP boxes, vendors drop files into Daniel'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, eliminating the duplicate files and manual trigger logic the old scripts had carried. Credit-collection exchanges run through GPG-enabled folders, so files are encrypted and decrypted automatically as they move between Daniel's 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 5 TB 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 more than 100 stores. 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 Tripled Without Tripling 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 roughly tripled in about a year without the estate getting harder to run.

• Outbound connections grew from 13 in February 2025 to about 40 by May 2026. Roughly 20 production vendor sources were feeding the workflows by then, with some sources using multiple FTP connections.
• Eleven 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.

“I want to hug it.”

The File Layer Went In Before the Cloud Migration Finished

A credit file used to mean an employee holding another company's FTP password, a manual pull onto a local server, and silence if it failed. In redesigned vendor flows, it now lands on Daniel'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. Daniel's 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.