Tommy Bahama Ended Day-Long FTP Queues in Its Seattle-to-India Photo Pipeline
Oxford Industries is a house of American lifestyle brands, and Tommy Bahama is its largest, selling nationwide through retail, e-commerce, and wholesale channels. At that scale, product photography is not a marketing task. It is the storefront.
Tommy Bahama's in-house studio in Seattle shoots weekly across women's, men's, product, flats, and still-life rotations, and every image follows the same route: captured on set, retouched by an external partner in India, and published through Adobe Scene 7 into AEM for the website. Three parties touch every photograph. And the path connecting them belonged to none of them. Finished images traveled over an FTP server owned and operated by the retouch vendor.
With the retouch team eleven and a half hours ahead of Seattle, a queue that formed during the studio's afternoon sat untouched overnight. Every stall cost a day.
Every Finished Image Traveled Over a Server the Studio Couldn't Fix
Creative Force, the studio's production platform, handed finished captures to the retouch team by way of the vendor's overseas FTP server, and retouched work came back the same way. When that server slowed, the studio slowed with it. Creative Force's own monitoring flagged assets stuck in post, and finished work queued up on the vendor's server waiting to move. When Creative Force pressed the vendor about it, the answer was that its pipeline simply was not big enough.
The studio's cadence left no slack to absorb any of it.
“It's per image, per shot. Everything is transferred.”
A pipeline moving files continuously, image by image, cannot be paused for a rebuild; the next rotation is always days away. And the choke point sat in infrastructure Tommy Bahama neither owned nor could repair. The studio could see exactly where the problem was and could do nothing about it.
The rest of the pipeline ran on hands. Staff moved files manually in Cyberduck, a desktop FTP client, both for the retoucher exchange and for delivering finished assets to Scene 7. At the end of each shoot day, digitechs—the technicians who run the capture stations—backed up the day's work to portable external hard drives. That was the handling for an archive growing by terabytes every year.
Files.com Became the Exchange Point the Studio Owns
The bottleneck was structural. Shoot volume kept growing, and the vendor had already said its pipeline could not keep up, so waiting for someone else to fix it stopped being a plan. What the studio needed was specific: an exchange point it controlled itself, speaking the FTP and FTPS its production platform and retouch partner already used, keeping each party inside its own folders, running the onward publishing without a person in the loop, and cutting over without pausing the weekly shoot. Tommy Bahama made Files.com that exchange point.
Rather than routing production through whichever server happened to sit between the parties, the studio put Files.com in the middle and connected each party to it on its own terms.
Creative Force and the retouch partner each got scoped access to dedicated folders. Separate users and root folders isolated new production jobs from live work, allowing the team to stand up and test them without disrupting production. Folder names carried job and date tokens, so assets sorted themselves as they landed.
The routing runs itself. Files.com Automations trigger on arriving files and move them folder to folder through the retouch loop, and syncs carry finished assets onward to Scene 7 and into AEM on a nightly cycle. That is the delivery work that used to be a manual Cyberduck session.
Backup became a drag and a drop. The Files.com desktop app went onto the Mac capture stations, with Okta sign-in and Finder integration, under a shared studio alias. Digitechs drag the day's shoot into Files.com at the end of the day, and the hard drives stay in the drawer.
The cutover ran alongside live production rather than in place of it. Both outside parties tested their credentials before anything moved, and only then was Creative Force's upload target repointed to Files.com. The weekly shoot never paused.
The Studio Now Operates the Pipeline It Used to Watch
With Files.com in the middle of the loop, Tommy Bahama replaced a pipeline it could only watch with one it operates.
A stall on the vendor's server used to cost a full day. Now that server is out of the production path, delivery to Scene 7 and AEM runs nightly, and nobody opens an FTP client to move an image.
- End-of-day backup went from portable hard drives to a drag-and-drop into Files.com, and a single nightly backup sync moved roughly 13,000 files.
- Adding a new production job is a folder and a credential, isolated from live work, which is how the studio has kept extending the pipeline since the cutover.
“Once I got the automations running, I was like, okay, great, I'm just going to let it do its thing and leave it like that.”
A Hub the Studio Keeps Branching From
Files.com did more than remove one bottleneck. It is now a hub the studio can keep extending as production changes, with new jobs branching from the governed exchange without disrupting the path already live.
“I just didn't realize I could keep branching off of it.”
Related Customer Stories
Retail & Consumer
Barnes & Noble Moves 30 GB Vendor Files With Files.com—Without Vendor Accounts or a New Repository
A thin, governed transfer layer now carries about a terabyte a month to changing external partners while existing storage stays in place.
Read story →
Retail & Consumer
Marc Jacobs Retired Its FTP/SFTP Servers One Workload at a Time With Files.com
Amid simultaneous ERP and cloud migrations, Marc Jacobs kept dozens of live retail flows moving while completing its data-center exit.
Read story →
Retail & Consumer
One Counterparty at a Time, Jockey Moves Off Its Progress Ipswitch FTP Server With Files.com
Files.com runs alongside the old endpoint, letting Jockey remove workloads it controls while vendors and remaining third parties move on their own schedules.
Read story →