Quick devlog on a content migration I'm running for my personal site (davdevs-laravel): moving from a flat-file Astro content repo into a Laravel app backed by PostgreSQL, with Cloudinary handling media.
The wasted day (sort of)
I spent a full day writing .md guideline documents — step-by-step instructions for Claude Code to handle the migration autonomously.
The next day, reviewing it with fresh eyes, I realized the whole plan was built around the wrong topology: I'd designed it as a local-to-local transfer, since both the old and new repos live on my dev machine right now. But the actual migration target is local-to-cloud (Cloudinary for media, hosted Postgres for data), and that changes sequencing, validation, and rollback enough that the original docs weren't salvageable as-is. Today's commits tell that story pretty directly:
- Updated migration docs
- Updated migration plan to audit images
- feat: content migration audit + import commands (Phase 22, step 1)
I'm also still somewhat skeptical of how cleanly Claude Code will execute a migration like this end-to-end — subtle content breakage is easy to miss — so I made the image importer resumable and resilient to per-file failures (Make migration:import-images resumable and resilient to per-file failures) rather than treating it as one big atomic job. If it dies on file 340 of 500, I don't want to start over.
Two content types that needed real design decisions
1. Tool pages with attached React components
Each /tools post has a React component embedded alongside it. The instruction to Claude Code was scoped narrowly:
- Migrate only the components inside /tools
- Update the color scheme to match the new site — e.g., yellow buttons replacing blue
Shipped as Add React Component Manager for Tools.
2. Ebook product pages (uniquely designed, per ebook)
This was the harder one. Every ebook product page was hand-designed as a one-off — great for bespoke launches, terrible for migrating raw code into storable DB records.
The solution: stop treating each page as unique. Consolidate all ebook product pages into two layout variants — individual and bundle — and adapt the publications module to support full design customization within those two variants. This landed as Publication Template Manager for eBooks, in the same commit as the tools work — 87346c7: Add React Component Manager for Tools + Publication Template Manager for eBooks.
Worth noting this builds on a longer architecture already in place from prior phases — publication manager, taxonomy CRUD, headless REST API, JSON-LD/OG tags — so the template consolidation slots into an existing content model rather than a bolt-on.
Top comments (0)