Last time, we got the replacement site running. Now comes a migration question that should sound familiar to database people: how do you know you brought everything you needed?
Counting imported posts is useful. It won’t tell you that the SQL in one of them has turned into a single unreadable paragraph.
Inventory behavior, too
Look at what the existing site does, including the plugins. For each feature, decide whether to preserve it, replace it, or retire it.
Posts, images, and existing public URLs were requirements for me. An old event calendar wasn’t. You don’t need to rebuild every feature you’ve ever installed just because it appears in the backup.
Make those decisions before treating the importer as finished. Record missing media, unsupported embeds, and anything you deliberately leave behind. Otherwise, it’s pretty hard to distinguish an intentional retirement from something you forgot.
Follow somebody else’s bookmark
Keep existing post paths when you can. Where a path must change, give it an intentional redirect. Include old short links and feed addresses in that review.
Then follow a representative set of old links directly to their destinations. Check images, downloads, formatting, and code. Include old posts and unusual layouts, not just the newest article.
That sample helps you find classes of problems to repair across the archive. It doesn’t prove every page is correct. Track the remaining review rather than letting “the homepage looks good” become your acceptance criteria.
Some content also depends on somebody else’s website. I worked on keeping code and archived social content locally so an external embed disappearing wouldn’t take part of an explanation with it.
Assemble the pieces you still need
Here’s where the “Tech Lego” from the intro gets useful. Moving to static pages means choosing homes for the interactive bits WordPress used to handle.
My choices were:
- Comments: preserve historical comments as read-only content; use giscus, backed by GitHub Discussions, for new conversations.
- Email: use Buttondown to read a dedicated RSS feed and send new posts to subscribers.
- Analytics: collect new traffic data with Cloudflare and retain the old Jetpack history separately.
Those are choices to evaluate, not a mandatory shopping list. For example, giscus requires commenters to have GitHub accounts. Decide whether that fits your readers. Different analytics providers also count differently; joining their histories doesn’t make the numbers equivalent.
Test subscription behavior before enabling delivery. Verify signup, confirmation, and what the new feed considers a new post. Importing your archive shouldn’t email everyone a greatest-hits collection. I’ve already performed that particular experiment.
By the end of this pass, you should know what survived, what changed, and what’s still waiting for a decision. That’s a much more useful launch checklist than “all the files copied successfully.”