[epic] Fully working migration system

Test site we created with migrated: https://app-67d6f672c1ac1810207db362.closte.com/

UPDATE 2025-09-25: we have successfully migrated the site

Regarding the overall-view we can have a look at the following links to see the current published posts and media files in the "closte.com/wp-admin" dashboard;

As follows: dashboard;

• Can go into the "Posts" sidebar and see the published posts/pages,
• Can go into the "Media" sidebar and see all the images uploaded.

Acceptance

• All blog and associated images from lifeitself.org Flowershow are migrated to Wordpress ✅2025-09-25 All posts and pages migrated (but what about the jsx stuff? assume not). See site here and admin here ... For more see detailed analysis in notes below or comment XXX
• We migrate all pages to Wordpress (as pages)

Tasks

Prep

• #4

ETL Steps

• Image naming correction
• Image uploading
• insert the additional stages ...
• make functional tests to check correctness of the migration

1. Run the migration end-to-end

Don’t over-engineer step-by-step right now.

• Clone the full lifeitself.org GitHub repo locally (with git lfs for images). Edit : Done with git commands in terminal and worked
• Configure the tool to point at the repo root and run against all content (posts, pages, media). Edit: Done, for this was used git lfs with the cloned repo on local machine
• Make a note of what breaks (Accept that things will break — that’s how you’ll surface issues). Edit: Got an analysis and most of images worked correctly on migration, unfortunately we had problems with some media files / corruption during migration

2. Functional tests

• Define “good enough” checks rather than pixel-perfect replication.

• Create some functional tests (2-3) to sample real pages (e.g. a few top blog posts). (can hard code tests or pull old pages on the site and then compare)
• Titles are preserved.
• Images display.
• Content renders without catastrophic formatting errors. Edit: Some posts preserved formating, but some with visual bugs.
• Authors - (Ignore authors for now; will be a later mapping step.)
• Note tricky areas likely to need custom handling:
  • Footnotes → how does WP Markdown/blocks handle them?

3. Rerun strategy

• Either via API deletion (all posts + media). Edit : The API provides this possibility, if we find any errors in the publication, we can delete old posts and try again.
• Or by spinning up a fresh WP instance (probably cleaner if feasible).
• Need to confirm how media deletion works (sometimes orphaned uploads remain). Edit: Same goes for media, all can be done via API for CRUD operations.

Notes

2025-09-17

• Do we switch to nodejs from python? There was no good reason to use Python now that I remember. Not really sure why we wrote with Python. 👍 MarkdownDB is in Node.js and the Node.js setup would allow us to use this tooling more around FlowerShow in the future if there was that potential usage. 👎 At the same time, any change has some cost and I guess it's not that hard to convert to Node.js later if we really wanted to.
  Edit: Thinking further, python was a good idea because of the ETL structure, overall is better to make isolated scripts and tests instead an overcomplicated workflow of a nodeJS for this type of migration
• How can we simplify the code and prompt better? (is this important)
  Edit: Tbh... having a spec-based workflow is a good aproach, there are some examples that people have done using .md files and also spec-kit demonstrated in this repo

Next steps

Next steps

• Run first full migration.
• Capture failure modes (images missing, Markdown quirks, authors, footnotes).
• Decide: cleanup via API delete vs. fresh instance.
• Collect repo stats to establish baseline.