A Specialty Retailer Puts Files.com in Front of Its NetApp Design Archive in Three Weeks
A North American specialty retailer runs hundreds of year-round stores alongside a seasonal banner whose stores are opened, stocked, run, and closed every year, trading for a few months and spending the rest of the year in preparation. Behind both banners sits a company of thousands of employees.
Nearly everything on those shelves starts as a design file. The retailer creates its seasonal merchandise, décor, and licensed products in-house, with a US creative team, and manufactures overseas, mostly in China. A design becomes a product by crossing the Pacific: a multi-gigabyte Adobe Illustrator or CAD package goes out to one of hundreds of manufacturing vendors and comes back with revisions, over and over, against a season that arrives on a fixed date. If those files stop moving, merchandise misses the window. And for the seasonal banner, the window is the business.
The retailer ultimately replaced its self-hosted FTP and SFTP perimeter with Files.com while leaving the NetApp design archive in place. Designers kept their network folders, vendors kept their SFTP logins, and the files never had to move.
A Supply Chain Running on Self-Hosted Servers in the DMZ
That exchange ran entirely on servers the retailer hosted itself. An FTP server sat in the DMZ for the vendors whose tooling depended on that protocol. A separate SFTP server served the creative team. And because the design share lived on the internal network, a DFS replication job continuously copied it out to yet another externally facing server so vendors could reach it at all.
Keeping one vendor's designs away from another's came down to a hand-built directory structure, extended by hand every time a vendor was added. The retailer wanted vendor isolation enforced by the platform, and it wanted the servers, the replication chain, and the folder-by-folder administration gone.
The estate had also simply been outgrown. The vendor and partner population it needed to serve had grown to several hundred users, far more than it was built for, and the retailer needed one centralized file-transfer capability in place of the self-hosted servers.
What made replacement hard was everything that could not change. The design corpus lived on a NetApp ONTAP appliance on the internal network, and that appliance was the system of record: the data was not going to move. Internal designers had to keep saving files into the same network folders they had always used. Hundreds of overseas vendors had to stay reachable from China and keep the SFTP logins they already had. And the platform froze for months every year while the selling season ran, so any cutover had a hard deadline.
The Data Could Not Move, and the Window Was Fixed
An earlier plan for the file-storage component of a new vendor portal would have required the retailer to download the entire multi-terabyte archive, ship it on an external drive, and wait roughly a month while it was read in. For that month, the exchange with manufacturers would have been down.
The ingest was only one piece. That plan's estimate for moving the whole vendor population was more than a year.
What the fix actually had to do was narrower than a portal and harder than a migration. It had to sit in front of the appliance where the design files already lived, without moving them. It had to present the same internal folders to designers and the same logins to vendors. It had to keep hundreds of vendor companies isolated from one another, run under the retailer's own domain, stay reachable from China, and be finished before the seasonal freeze closed the window.
The retailer selected Files.com to take over the file-storage component of the vendor portal. Its IT team scoped the move itself: the internal server work, the sync and upload, the testing, and the full user cutover.
An Agent in Front of the NetApp, and One Changed Hostname
For the retailer, Files.com became the managed external face of storage that never moved.
The Files.com On-Premise Agent connected a dedicated new server to the NetApp ONTAP share holding the design corpus. A Files.com Remote Server Mount then presented that share through a dedicated child site: a live window onto the appliance, not a copy of it. Designers kept dropping files into the same internal network folders, and what they dropped was exactly what vendors saw, because there was only one set of files.
Files.com per-folder permissions enforced one account and one folder per vendor company, hundreds of folders each sealed off from every other. Vendors connected over SFTP, exactly as they always had. Their accounts were bulk-created from a spreadsheet, preserving the existing usernames and passwords for the great majority of the population, and the site ran on a custom domain under the retailer's own name. When cutover came, vendors were told a single fact: the hostname had changed.
The configuration was proven first on a separate test child site, then recreated in production, with the schedule staged around the selling season.
Live in Three Weeks, With Nothing for Users to Relearn
US designers now upload finished packages at 8 or 9 at night and have feedback from vendors in China the same day, a round trip the season depends on.
With the child site in production, the retailer replaced a self-hosted external file estate with a managed perimeter, on the timeline its own IT team had scoped.
- The cutover took three weeks from start to finish, against the more than a year the earlier plan had estimated.
- The design data was in place and tested in about a week, with no downtime, against the month-plus ingest and shipped hard drive of the earlier plan.
- Hundreds of vendor companies carried their usernames, passwords, and folder access straight across. The one change a vendor saw was a hostname, and internal designers saw no change at all.
- The DMZ FTP server, the SFTP server, and the DFS replication chain are retired.
Onboarding the next vendor no longer means hand-building another directory on a DMZ server. It is an account and a folder on Files.com, following a pattern that already isolates hundreds of them.
The Storage Never Moved
The exchange that stocks the seasonal banner's stores each year now runs through Files.com. Designers still save to the folders they have always used. The design corpus still lives on the NetApp appliance the retailer already trusted. Vendors in China still sign in over SFTP with the logins they already knew. What is gone is everything that continuity used to cost: the self-hosted servers, the hand-built vendor directories, and the replication job pushing internal data to an externally facing box. Files.com went in front of the storage rather than in place of it, and that is why a cutover estimated at a year, or a month offline, took three weeks with no downtime at all.
Related Customer Stories
A National Retailer Moves Multi-Gigabyte Vendor Files With Files.com, Without Vendor Accounts or a New Repository
A thin, governed transfer layer now carries multi-gigabyte transfers to changing external partners while existing storage stays in place.
Read The Story
A Luxury Fashion House Retired Its FTP/SFTP Servers One Workload at a Time With Files.com
Amid simultaneous ERP and cloud migrations, the fashion house kept dozens of live retail flows moving while completing its data-center exit.
Read The Story
One Counterparty at a Time, an Apparel Manufacturer Moves Off Its Progress Ipswitch FTP Server With Files.com
Files.com runs alongside the old endpoint, letting the manufacturer remove workloads it controls while vendors and remaining third parties move on their own schedules.
Read The Story
Get The File Orchestration Platform Today
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes