I had an old WordPress site I wanted back — but not in the obvious way.
The easy answer would have been to restore the old backup, point the domain at it and hope for the best. That would also have brought back years of old WordPress state I no longer wanted: settings, old assumptions, old structure and whatever else had accumulated around the actual things I cared about.
What I wanted was much simpler: the writing, the original dates, the URLs where they still made sense, and the real photos.
So instead of restoring the old site, I treated the backup as evidence.
1. Start with a clean WordPress install
The new Jenski site was built separately. New WordPress, new theme, new structure. The old site was never allowed to become the new production runtime.
That gave me a useful boundary: anything coming across from the archive had to earn its way into the new site deliberately.
2. Extract the public content, not the whole old system
I recovered the old public posts from the database and built an inventory before importing anything. That turned out to be 28 posts plus one old page.
For every recovered item I kept the original title, publication date, slug and body copy. I also created a hash of the recovered content so I could later prove the copy stored in WordPress was the same copy I had extracted.
The old page did not automatically come back just because it once existed. Its job had been superseded by the new Places system, so I kept it as source history instead of recreating pointless clutter.
3. Import everything as drafts first
This was probably the most important decision.
All 28 recovered posts went into the new WordPress installation as drafts. Nothing became public just because it had been public ten years ago.
That matters because old writing can contain stale links, old prices, factual claims that need checking, advice you would phrase differently today, or simply things that made sense in another version of your life.
Recovery and republication are two different jobs.
4. Preserve the original voice
I did not want to quietly rewrite old posts and pretend that was what I wrote at the time.
The better answer was to preserve the recovered body and let the new theme provide context around it. Historical posts can carry an archive note explaining that the piece is old and that links or factual details may have changed.
That leaves the old writing honest while still making it clear to a reader that it is an archive piece rather than a brand-new guide.
5. Recover original media selectively
The posts were only half the archive. Some of the old images mattered too.
I did not copy an entire old uploads directory into the new site and call it done. I identified the original files actually tied to the recovered posts, recorded their sizes and hashes, and restored only those verified originals.
In this case that meant 17 original media files. Fourteen were the original featured images for historical posts and three were additional images used inside old articles.
After import, every original file was read back and checked again. The featured-image relationships were recreated and the three old inline image references were repaired.
6. Take a rollback point before touching production
Before importing the archive, I took a full production backup and verified that the backup really existed.
That sounds boring until something goes wrong. Then it becomes the most interesting part of the entire job.
I also kept the site in maintenance mode and blocked search indexing while the migration work was happening. That meant I could make mistakes, verify the result and fix things without a half-finished archive appearing in search engines.
7. Verify the resulting state, not just the action
“The import command succeeded” is not enough for me.
I wanted to know that the posts existed as drafts, the stored content matched the recovered source, the media bytes matched the originals, no public post had accidentally appeared, and temporary migration tools had actually been removed afterwards.
That distinction — between an action ran and the intended state is now proved — is one I am increasingly using everywhere.
What I would do again
- Build the new site first. Do not make an old runtime your foundation merely because it contains the content you want.
- Treat backups as evidence. Extract what you need and preserve provenance.
- Import old content as drafts. Recovery is not approval to republish.
- Keep original dates and URLs where sensible. History is useful.
- Restore original media, not random generated leftovers.
- Hash important recovered material. It gives you something objective to verify later.
- Take a rollback point first.
- Verify the final state independently.
The result is that the old Jenski archive is back where I can work with it, but the old site itself stayed in the past.
That was exactly what I wanted.