What happens to forty years of archives when you switch platforms
The question every publisher asks second and worries about first. Here is what actually moves, what usually breaks, and the questions to put to any vendor before you sign.
Every publisher we talk to asks about pricing first and the archive second. The order is misleading. The archive is the one they actually lie awake about.
It is a reasonable fear. The archive is the single asset a community newspaper owns that nobody can replicate: a hundred and forty years of a county's obituaries, meeting coverage, box scores and land transfers, in one place. A migration that damages it is not a technical inconvenience. It is the loss of the thing that makes the paper worth owning.
So here is the honest version of what happens, including the parts vendors tend not to volunteer.
What actually moves
Page images and PDFs. The straightforward part. Whatever form your back issues are in (press-ready PDFs, scanned TIFFs, microfilm digitizations of varying quality), they copy across. Volume is rarely the problem; forty years of a weekly is a few hundred gigabytes, which is unremarkable.
Searchable text. This is where quality varies enormously, and where you should ask hard questions. Text comes from OCR, and OCR quality depends on the source. Clean modern PDFs OCR nearly perfectly. A 1968 issue scanned from imperfect microfilm will not, no matter who processes it. Any vendor promising uniformly excellent search across a century of microfilm is overselling.
The question to ask is not "will it be searchable" but "what OCR confidence do you get on my oldest material, and can I see a sample before we commit?" Send three issues, one recent, one from the 1990s, one from the oldest material you have, and ask for processed samples back. A vendor unwilling to do that is telling you something.
Subscriber records. Names, addresses, expiration dates, payment history, and the print/digital status of each subscriber. The usual complication is that most papers hold subscriber data across two or three systems that disagree with each other: a circulation system, a payment processor, and a spreadsheet. Reconciling those is normally the slowest part of any migration, and it is work that has to happen on your side as much as the vendor's.
Your URL structure. The part most likely to be handled badly, and the most expensive to get wrong.
The part that usually breaks
If your old article URLs stop working and nothing redirects them, you lose the accumulated search value of every story you have ever published. Google drops the old addresses, finds new ones with no history, and treats your twenty-year-old site as new. Traffic falls and takes a long time to come back.
This is entirely preventable with a redirect map, a file that tells browsers and search engines that the old address has permanently moved to the new one. It is unglamorous, it is tedious, and it is the difference between a migration that is invisible to readers and one that costs you a year of rankings.
Ask any vendor, in writing: will you produce a complete 301 redirect map from our existing URLs to the new ones? If the answer is vague, that is your answer. It is worth noting that this matters somewhat less than it did five years ago, since search referrals to US news sites are down roughly 38% year over year regardless of what anyone does, but "less valuable than it was" is not the same as "worth discarding."
The questions to put to any vendor
Take this list to whoever you are evaluating, including us:
- Can I see processed samples of my own oldest material before I commit?
- Will you produce a complete 301 redirect map from our existing URLs?
- Who owns the digitized archive if I leave? The correct answer is that you do, and that you can get a complete export in a standard format on request. Get it in the contract.
- What is the export path? Not because you plan to leave, but because a vendor confident about their exit path is telling you something about how they expect to keep you.
- What happens to our e-Edition delivery during the cutover? Readers should not experience a gap.
- Who does the subscriber-data reconciliation, and how many hours of our time will it take? Any vendor claiming zero effort on your side has not done this before.
A realistic timeline
Four to six weeks for a typical community weekly, most of which is the vendor working and you reviewing.
- Week 1. Discovery. Inventory of archive material, subscriber systems, current URL structure.
- Weeks 2-3. Archive processing and site build. You review OCR samples and the site design.
- Week 4. Subscriber data reconciliation. This is your heaviest week, and it is unavoidable.
- Week 5. Staging review. The full site, with your archive in it, on a private URL. You break it before your readers can.
- Week 6. Cutover, with redirects live from the first minute.
You publish normally the entire time. If a vendor proposes a timeline with a publishing gap in it, that is a red flag rather than a scheduling detail.
What we do
We have moved a thousand community papers onto this platform since 2010, and the average publisher who joins us is still here eight years later. The archive comes across searchable, the redirect map is written before cutover rather than after, and the archive stays yours, exportable on request, in writing.
We are also happy to tell you when a migration is a bad idea right now. If you are three months from a contract renewal with someone else, or in the middle of an ownership change, or short-staffed heading into election coverage, the right answer is usually to wait.
If you would rather just ask a question than sit through anything, email us. It goes to a person.