How a single Cursor conversation migrated 9 insights, 19+ pages, and an entire content architecture from Astro Content Collections to Strapi CMS — with minimal human intervention.
The Setup
The IB Solutions website runs on Astro 4 with content managed through Astro Content Collections — markdown and MDX files stored directly in the repository. It works, but it ties content editing to code deployments and doesn't scale for non-technical editors.
The goal: migrate the insights (case studies, AI demos, guides) to Strapi CMS so content can be managed through an admin panel, edited without touching code, and published independently from deployments.
Rather than spending days planning and manually executing this migration, I opened a single Cursor agent conversation and let it work.
What Cursor Built in One Session
From a single starting prompt — "plan out connecting Strapi CMS to this website" — Cursor autonomously:
- Created the entire Strapi CMS project with Insight and Tag content types, including schema definitions, API permissions, and bootstrap configuration
- Built the frontend integration layer — a typed API client, response interfaces, and a data access module that maps Strapi responses to the shape existing components expect
- Wrote a migration script that reads MDX files, parses frontmatter and markdown, converts to Strapi's blocks format, handles custom components, and pushes everything via the REST API
- Built a custom rich text renderer (StrapiBlocks.astro) because the third-party library required Astro 5 — incompatible with our Astro 4 setup
- Created a component system (StrapiContent.astro) that splits Strapi blocks at component markers and renders real Astro components — Stats cards, Testimonial cards with photos and LinkedIn links, tables, and styled dividers
- Migrated 19+ pages from Astro Content Collections to Strapi data fetching, updating imports, types, and data access patterns across the entire codebase
- Removed the old insights collection from Astro's content config, completing the migration with zero backward compatibility — a clean cut
The Numbers
Session Stats
Autonomy & Accuracy
What I Actually Did
Out of roughly 12 prompts across the full session, here's what my involvement looked like:
- Gave the initial direction — "plan out connecting Strapi CMS to this website" and answered 4 architectural questions (hosting: cloud, content: migrate, start with: insights, drafts: yes)
- Created one API token manually — the only step that required the Strapi admin panel, because API tokens can't be created programmatically
- Reported visual issues — compared the production page against the local Strapi-powered version and listed 6 discrepancies (text color, missing image, no dividers, missing stats, missing testimonials, broken table)
- Reported one syntax error — Astro showed an "Unexpected |" error from an export type statement in component frontmatter
- Asked two verification questions — "Can you confirm insights are pulling from Strapi?" and tested title changes to validate the data flow
That's it. No manual file editing, no copy-pasting schemas, no writing migration scripts by hand, no debugging type errors across 19 files.
Mistakes Cursor Made (And How It Recovered)
It wasn't flawless. Cursor made several mistakes during the session — but the recovery pattern is what matters.
1. Tried to use an incompatible third-party library
Cursor attempted to install @sensinum/astro-strapi-blocks for rendering Strapi rich text. It required Astro 5; we're on Astro 4. After confirming no compatible version existed, Cursor built a custom renderer from scratch — arguably a better solution since it gives us full control.
2. File persistence issues with the editing tool
Multiple file edits silently failed to persist to disk. Cursor detected the problem when verification commands showed old content, then switched strategy to overwrite entire files instead of making targeted replacements. Self-diagnosed and self-corrected.
3. Stripped custom MDX components during migration
The initial migration script used a regex (<[A-Z][^>]*/>) to strip all JSX components — including Stats, Testimonials, and other interactive elements. I caught this during visual QA. Cursor then designed a component marker system that encodes custom components in the Strapi blocks JSON and renders them as real Astro components on the frontend.
4. Syntax error in component definition
Used export type in Astro frontmatter, which doesn't support exports. Fixed in under 30 seconds after I reported the error.
5. Wrong Strapi v5 publish endpoint
Called POST /insights/:id/actions/publish which returns 405 in Strapi v5's REST API. Turned out content created via the REST API is published by default, making the endpoint unnecessary. Non-blocking — all content was already published.
The Architecture That Emerged
What's interesting is the architecture Cursor designed. It wasn't just a quick migration — it created a proper, maintainable system:
Data flow:
Strapi CMS → REST API → strapi.ts (API client) → strapi-insights.ts (data access layer with InsightEntry normalization) → Page components
Content rendering:
Strapi blocks JSON → StrapiContent.astro (splits at component markers) → StrapiBlocks.astro (standard blocks) + Stats.astro / Testimonial.astro / Table / HR (custom components)
Component marker system:
Custom MDX components are encoded as {{component:stats:{...}}} markers in the Strapi blocks field. The StrapiContent component detects these, extracts the JSON props, and renders real Astro server components with full access to content collections and styling. This means testimonials still fetch their contact photos and LinkedIn links from the testimonials collection — nothing was lost.
What This Means
A CMS migration is traditionally a multi-day project. It touches data modeling, content transformation, frontend integration, type safety, and visual parity. You'd typically allocate a sprint for it.
This one took a single conversation. The human contribution was strategic direction, one manual admin task, and quality assurance. Everything else — schema design, migration scripting, type definitions, page rewiring, custom component systems, error recovery — was handled by Cursor.
The key insight isn't that AI wrote the code. It's that the feedback loop was tight enough to ship. I could see the result, point at what was wrong, and Cursor fixed it — usually in the same response. That's not "AI assistance." That's a collaborative engineering session where the AI did 85% of the implementation.
The mistakes are part of the story. No developer gets everything right on the first pass either. What matters is the recovery speed and the final result: a clean, zero-error build with proper architecture, type safety, and full visual parity with the original.
Want AI to handle your next migration?
We use tools like Cursor to compress multi-day engineering projects into focused sessions. If you have a migration, refactor, or integration project, let's talk about what's possible.