A Newspaper Publisher Replaced Dozens of Local FTP Servers With One Files.com Hub to Centralize Print Production

A US newspaper publisher runs dozens of local newspapers across the country. Its largest ad production center produces a large share of the company's ads and provides creative services to locations across several states.

That model has a hard physical requirement. An ad or a page built centrally is worth nothing until it reaches the paper that will print it, and it has to arrive before that paper's press deadline, every ad, every page, every night. Centralized production only works if delivery to every paper in the chain is just as centralized, and just as dependable.

Dozens of Papers, Dozens of FTP Servers

The publisher was consolidating ad and page production for its newspaper, magazine, and web editions into two production centers. The two centers would generate finished assets that had to be delivered to individual papers throughout the country.

The delivery estate they inherited was the opposite of centralized. Each of the dozens of papers ran its own FTP server, and no two were built alike. Every site carried its own hardware, its own configuration, and its own support burden, and nobody owned the delivery path as a whole. For the production centers, that meant dozens of separately maintained endpoints standing between a finished ad and the press that would print it, each one a place a deadline-bound transfer could go wrong, and each one supportable only by whoever kept that paper's server running.

The estate had grown that way honestly. When every paper made its own ads, a local FTP server was a local convenience and its quirks were a local problem. Consolidation ended that. Once two centers had to feed the whole chain every day, the patchwork stopped being dozens of small problems and became one large one.

Two Production Centers, One Delivery Path

What the publisher needed was a single hosted FTP location that removed the hardware and support burden from every individual site. It had to accept scripted, unattended writes from production systems as well as ordinary FTP client access from the papers, because both kinds of connection were already how the work moved. Storage had to be one shared pool sized for the group and able to grow with it, not fixed space carved up per site. And because the workflow was live print production, files couldn't be left to pile up: the working set had to clean itself.

The publisher selected Files.com to be that single hosted location, with its own IT team running the consolidation.

A Folder for Every Paper, a Script for Every System

The structure is simple: one folder per newspaper on one Files.com site, with subfolders covering finished ad PDFs, page PDFs, and a small text-file feed. The production centers' systems write finished work into each paper's folder over FTP and SFTP, and each paper's production systems pull it down for print. No person carries the file at either end.

Files.com's file expiration settings keep the working set clean without anyone doing cleanup. Ad PDFs, page PDFs, and the text feed each expire on their own schedule. At any given moment the hub holds hundreds of files in flight, and the platform, not a person, retires each one once it has outlived the press run it was made for.

Cut Over Site by Site, Never All at Once

Dozens of live print operations could not move to a new server in one synchronized event. They didn't have to. The publisher ran the migration as a series of discrete per-site cutovers: roughly a dozen papers came off their local servers in the first year, and the remaining locations were folded in over the following years, each one a routine folder-and-data-transfer event rather than a project. The two production hubs also began exchanging small files with each other nightly through the same site. The workflow the old estate carried stayed in production throughout its own replacement.

A Decade of Print Deadlines Through One Hub

With the hub in production, the publisher replaced dozens of locally supported FTP servers with one delivery path, and that path has now carried the chain's print production for a decade.

• The flow is automated end to end. Sending systems drop finished ads and page templates into the per-paper folders, and the publisher's automation drives the hub through the Files.com REST API at hundreds of thousands of requests a day, while named accounts are held only by the people who need them.
• The hub moves terabytes a month between the production centers and the papers.

Production Is Central Because Delivery Is

Now, an artist at the production center finishes an ad for a paper on the other side of the country, a script drops it into that paper's folder on Files.com, and the paper's production system pulls it down before the press run. Nobody at either end touches a server, because there is no server at either end to touch. The endpoints the papers spent years maintaining are gone, and what replaced them belongs to the company rather than to dozens of separate IT closets.

That is what made the consolidation hold. Producing a large share of the company's ads in one building is only workable because getting them out of that building is no longer anyone's local problem. And the publisher never needed a synchronized cutover to get there: the estate came down a site at a time, onto Files.com, while the print deadlines it served kept running.