Skip to main content

Spencer Gifts Retired Legacy FTP in Three Weeks—Without Moving Spirit Halloween's NetApp Data

Files.com gave hundreds of overseas vendors managed access to the existing design archive while preserving the workflows and logins they already knew.
Spencer GiftsFiles.com

Spencer Gifts is the specialty retailer behind two of the most recognizable names in North American retail: Spencer's, the novelty and pop-culture chain with more than 650 year-round stores, and Spirit Halloween, the largest Halloween retailer on the continent. The Spirit Halloween model is an operational feat with few parallels. Roughly 1,500 pop-up stores are opened, stocked, run, and closed every year, trading for about three months and spending the other nine in preparation. Behind both banners sits a company of more than 10,000 employees.

Nearly everything on those shelves starts as a design file. Spencer Gifts creates its costumes, décor, and licensed merchandise in-house, with a US creative team of 100 to 250 people, and manufactures overseas, mostly in China. A design becomes a product by crossing the Pacific: an Adobe Illustrator or CAD package of 2 to 15 GB goes out to one of roughly 350 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 at Spirit Halloween, the window is the business.

Spencer Gifts ultimately replaced its legacy 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 Servers Kept Old on Purpose

That exchange ran entirely on servers Spencer Gifts hosted itself. A Windows FTP server sat in the DMZ on an operating system kept deliberately old, because the legacy protocols its vendors depended on would not run on anything newer. A separate legacy SFTP server, also on an old Windows version, served the creative team. And because the design share lived on the internal network, a Windows 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 file exchange the company's entire manufacturing operation depended on was running on internet-facing machines too old to keep current and administered folder by folder.

The estate had also simply been outgrown. The vendor and partner population it needed to serve was approaching 600 users, far more than it was built for, and Spencer Gifts needed one centralized file-transfer capability in place of the aging 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 Windows and Mac 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 every year from August through mid-November while the Spirit Halloween season ran, so any cutover had a hard deadline.

A Mailed Hard Drive and a Month Offline

A replacement was already in flight, and it was failing. Spencer Gifts had engaged a third-party provider to deliver the file-storage component of a new vendor portal, and the provider's plan for moving the design data was to have Spencer Gifts download all 6 TB, ship it on an external drive by mail, and wait roughly a month while it was read in. For that month, the exchange with manufacturers would be down.

And in the meantime our system's down.
Greg Young, Associate Director, Server Administration, Spencer Gifts

The ingest was only one piece. The portal project'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 roughly 350 vendor companies isolated from one another, run under Spencer Gifts' own domain, stay reachable from China, and be finished before the seasonal freeze closed the window.

Spencer Gifts selected Files.com to take over the file-storage component of the vendor portal. Greg Young scoped the move himself: the internal server work, the sync and upload, the testing, and the full user cutover.

I estimated it out at a three-week project, three weeks from start to finish, that I can have everybody over there. That's in comparison with the current project that they're saying would take them over a year.
Greg Young, Associate Director, Server Administration, Spencer Gifts

An Agent in Front of the NetApp, and One Changed Hostname

For Spencer Gifts, Files.com became the managed external face of storage that never moved.

The Files.com On-Premise Agent connected a dedicated new Windows 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 from Windows and Mac, 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: roughly 350 folders mapped one-to-one to 350 vendors, 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 Spencer Gifts' 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 Spirit Halloween 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, Spencer Gifts replaced a self-hosted external file estate with a managed perimeter, on the timeline Greg Young had scoped rather than the one the portal project had quoted.

  • The cutover took three weeks from start to finish, against the more than a year estimated by the project it displaced.
  • The 6 TB of design data was in place and tested in about a week, with no downtime, against the month-plus ingest and mailed hard drive the previous provider had proposed.
  • Roughly 350 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 legacy SFTP server, and the DFS replication chain are retired, and with them the operating systems that had been kept old for the sake of a protocol.

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 350 of them.

The Storage Never Moved

The exchange that stocks roughly 1,500 Spirit Halloween stores each season now runs through Files.com. Designers still save to the folders they have always used. The design corpus still lives on the NetApp appliance Spencer Gifts 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 servers kept old on purpose, 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 quoted at a year, or a month offline, took three weeks with no downtime at all.