# Restoring a publisher's lost archive after a CMS migration

> A publisher's CMS migration had carried over only the most recent years of content, leaving the rest of a nearly two-decade archive behind. The old database backups still existed. I built a recovery pipeline, restored more than 316,000 content items without overwriting anything live, and helped Google rediscover roughly 247,000 pages within five weeks.

**In brief:** A publisher lost most of a nearly two-decade archive in a CMS migration: Search Console listed about 180,000 URLs it could no longer find. The content still existed in roughly 1.9 GB of legacy database backups spanning two CMS platforms. I built an extract-and-import pipeline, piloted it on one article before scaling, and restored more than 316,000 content items without overwriting live content. Within five weeks Google had indexed roughly 247,000 more pages, and 77.6% of the broken URLs that other sites linked to were live again.

**Digital publisher · Data recovery · CMS migration · Solo build**

## Before → After

Before: Most of the archive missing after a CMS migration, with Google still requesting the vanished URLs.

- **316k+**: content items recovered
- **~247k**: more pages indexed in five weeks
- **77.6%**: of broken link destinations live again
- **0**: live articles overwritten

## The stakes

The publisher's sites went back nearly two decades, but a recent CMS migration had carried over only the last couple of years of content. Everything older was gone from the live sites: the articles, the pages, the URLs. Google was still trying to crawl the old addresses, and Search Console listed about 180,000 URLs it could no longer find. Meanwhile the sites kept publishing every day, so whatever the fix was, it couldn't touch the current content.

## Why the lost content wasn't actually gone

**The archive wasn't destroyed. It was left behind, sitting in old database backups.**

The previous developer still had database snapshots from before the migration, about 1.9 GB across four databases, built on two different CMS platforms with incompatible structures. The content was all there: 357,557 published articles, plus pages. So this was a data recovery problem, not a redirect exercise: get the real articles out of four legacy databases and back onto the live sites, safely, without treating those sites like empty containers.

## What I did

I built a recovery pipeline in two stages. First, extractors read each legacy database locally and wrote the content into portable files, filtering out empty and near-empty records along the way. Then an importer streamed those files into the live sites in logged batches, skipping any address that already existed so nothing current could be overwritten, and verifying random samples against the source afterwards.

I scaled it up only as it proved itself. The first production run imported one article. Then ten. Then a batch of about 925 chosen because Google was actively asking for them. Only then the full archives, each preceded by a fresh backup. Where the old sites had used different URL structures, I added narrowly scoped redirects so old links land on the recovered article, and left URLs alone when there was no honest destination for them.

## The result

More than 316,000 content items came back: articles and pages spanning publication years 2007 through 2025. Within five weeks, Google's indexed page count across the sites had grown by roughly 247,000. Of the broken URLs that other websites still linked to, 77.6% were live again purely because the content was back, and a set of 73 carefully reviewed redirects rescued several thousand more inbound links.

To be honest about the limits: the old archive did not turn into a traffic engine. Most of the restored pages get little or no search demand today. The value was preservation: nearly two decades of publishing history that existed only as database backups became a live, browsable archive again, with its URL history largely intact.

## What I learned

At this scale I would gate more, earlier. Letting Google index every recovered page immediately was too blunt; the thin tail should have been held back from day one and only the substantial, linked, or traffic-earning pages exposed first. And restoring the content is not the same as restoring the presentation: images, metadata, and bylines were a separate cleanup phase that followed. Both lessons are now part of how I plan migrations.

**What this proves:** A migration that drops the archive feels permanent, but the content usually still exists somewhere. The job is getting it back without breaking what's live, and being honest about which pages deserve to be findable again.

Lost content in a migration? Let's talk it through. Book a call: https://calendly.com/nerijus-masikonis/intro-call