Migrate a website from a CMS to raw code and Markdown
I migrated cursor.com from a CMS to raw code and Markdown. Task: I migrated cursor.com from a CMS to raw code and Markdown. I had estimated it would take 1-2 weeks, but was able to finish the migration in three days with $260 in tokens and hundreds of agents. Content is just code I was eating lunch with Roman and Eric at Cursor and we started talking about the cursor.com website. We recently shipped a redesign, and as part of that change, all content and web pages were now built through a headless CMS. We went around the table airing our grievances. The CMS wasn’t working. We had this beautiful new website design and yet it felt more difficult than ever to ship new content. Previously, we could @cursor and ask it to modify the code and content, but now we had introduced a new CMS abstraction in between. Everything became a bit more clunky. We went back to clicking through UI menus versus asking agents to do things for us. With AI and coding agents, the cost of an abstraction has never been higher. I asked them: do we really need a CMS? Will people care if they have to use a chatbot to modify content versus a GUI? We could eliminate so much complexity if we just went back to the raw code. Roman asked me how long it would take to migrate from the CMS back to code. My quick estimate was 1-2 weeks and we’d probably hire an agency to help with it. Maybe I just haven’t updated my timelines for the current state of AI, but I decided to try creating a plan in Cursor for how to migrate and then kicking off an agent to take a first pass. I was surprised by how far it got, although there was clearly much more work to do. It was enough to nerdsnipe me into taking on the migration. Here’s how I ended up migrating the site over the course of a long weekend. Removing complexity The Cursor website is a standard Next.js and React app. The new version was built on top of a CMS so that non-developers could build marketing pages and writers could add new blog posts. Again, using a CMS is pretty standard for most sites. For many teams, the cost of the CMS abstraction is worth it. They need to have a portal where writers or marketers can log in, click a few buttons, and change the content. It’s been like this since the dawn of time (WordPress). What is under-discussed is the amount of technical complexity needed to integrate a headless CMS well into a modern website. I’m familiar with all the products and solutions, and yes, some do a very good job of hiding that complexity! It’s still there, though, even if behind an npm package. Here’s a short list of the hidden complexity. If you’re not as interested in the technical details, you can skip over these: The first and most immediate issue is having user management in multiple places. In a world where designers are developers, it’s not a stretch to have your marketing team in GitHub as well. You already have GitHub SSO and RBAC set up anyway. New team members would try to make a change to the site, and then have to ask “Can I get added to the CMS, please?” Yes, Enterprise tiers and SCIM can solve this, but… complexity. We added our marketing team to GitHub instead. One account management system. You want to have a really fast marketing site, right? That means you would ideally prerender as much as possible ahead of time, so you don’t make your visitors compute a new version of the page on every visit. Yes, I know, caching. Prerendering is a form of caching. Speaking of removing complexity, a statically prerendered page removes a ton of operational complexity. You don’t want your marketing site going down when the CMS has a blip in availability. So, we want static pages. Having your cake (static pages) and eating it too (using a CMS) is doable but just… kind of annoying? In Next.js, you have draft mode. There’s even a great integration with Vercel where you can toggle into draft mode from the Vercel toolbar. This allows you to dynamically fetch the latest content from the CMS (e.g. a server-side render) when you are making changes to your site, while still keeping production fast and statically rendered. Great! But this is eating a lot of the complexity budget. Now if you want people to view URLs of draft content, they need to be logged into Vercel or have Vercel accounts. Again, doable, but now we’re in another Enterprise and SCIM account management solution. When the content is code, you can create a PR, get a link with your changes, and share it with anyone. No login is required. Simplicity.; tools: Cursor. Human role: The original post does not say how a person stayed involved.; limitations: The workflow assumes a Next.js/React stack and existing API access to the CMS. The author notes that the last 20% of engineering tasks often take the most time, indicating agents are not fully autonomous for complex refactoring. Source reliability is high as it is a first-person account, but specific costs and timelines may vary by project complexity..
Tools
Published on Agent Work Atlas:
Overview
I migrated cursor.com from a CMS to raw code and Markdown.
Workflow
I migrated cursor.com from a CMS to raw code and Markdown. I had estimated it would take 1-2 weeks, but was able to finish the migration in three days with $260 in tokens and hundreds of agents. Content is just code I was eating lunch with Roman and Eric at Cursor and we started talking about the cursor.com website. We recently shipped a redesign, and as part of that change, all content and web pages were now built through a headless CMS. We went around the table airing our grievances. The CMS wasn’t working. We had this beautiful new website design and yet it felt more difficult than ever to ship new content. Previously, we could @cursor and ask it to modify the code and content, but now we had introduced a new CMS abstraction in between. Everything became a bit more clunky. We went back to clicking through UI menus versus asking agents to do things for us. With AI and coding agents, the cost of an abstraction has never been higher. I asked them: do we really need a CMS? Will people care if they have to use a chatbot to modify content versus a GUI? We could eliminate so much complexity if we just went back to the raw code. Roman asked me how long it would take to migrate from the CMS back to code. My quick estimate was 1-2 weeks and we’d probably hire an agency to help with it. Maybe I just haven’t updated my timelines for the current state of AI, but I decided to try creating a plan in Cursor for how to migrate and then kicking off an agent to take a first pass. I was surprised by how far it got, although there was clearly much more work to do. It was enough to nerdsnipe me into taking on the migration. Here’s how I ended up migrating the site over the course of a long weekend. Removing complexity The Cursor website is a standard Next.js and React app. The new version was built on top of a CMS so that non-developers could build marketing pages and writers could add new blog posts. Again, using a CMS is pretty standard for most sites. For many teams, the cost of the CMS abstraction is worth it. They need to have a portal where writers or marketers can log in, click a few buttons, and change the content. It’s been like this since the dawn of time (WordPress). What is under-discussed is the amount of technical complexity needed to integrate a headless CMS well into a modern website. I’m familiar with all the products and solutions, and yes, some do a very good job of hiding that complexity! It’s still there, though, even if behind an npm package. Here’s a short list of the hidden complexity. If you’re not as interested in the technical details, you can skip over these: The first and most immediate issue is having user management in multiple places. In a world where designers are developers, it’s not a stretch to have your marketing team in GitHub as well. You already have GitHub SSO and RBAC set up anyway. New team members would try to make a change to the site, and then have to ask “Can I get added to the CMS, please?” Yes, Enterprise tiers and SCIM can solve this, but… complexity. We added our marketing team to GitHub instead. One account management system. You want to have a really fast marketing site, right? That means you would ideally prerender as much as possible ahead of time, so you don’t make your visitors compute a new version of the page on every visit. Yes, I know, caching. Prerendering is a form of caching. Speaking of removing complexity, a statically prerendered page removes a ton of operational complexity. You don’t want your marketing site going down when the CMS has a blip in availability. So, we want static pages. Having your cake (static pages) and eating it too (using a CMS) is doable but just… kind of annoying? In Next.js, you have draft mode. There’s even a great integration with Vercel where you can toggle into draft mode from the Vercel toolbar. This allows you to dynamically fetch the latest content from the CMS (e.g. a server-side render) when you are making changes to your site, while still keeping production fast and statically rendered. Great! But this is eating a lot of the complexity budget. Now if you want people to view URLs of draft content, they need to be logged into Vercel or have Vercel accounts. Again, doable, but now we’re in another Enterprise and SCIM account management solution. When the content is code, you can create a PR, get a link with your changes, and share it with anyone. No login is required. Simplicity.
Reported result
The migration was completed in three days with approximately $260 in token costs. Agents achieved about 80% completion in 10 runs, but the remaining 20% required significant manual effort and iteration. Post-migration, the team reported faster build times and reduced CDN costs, though these are attributed to the architectural change rather than direct agent metrics.
Human role
The original post does not say how a person stayed involved.
Limitations
The workflow assumes a Next.js/React stack and existing API access to the CMS. The author notes that the last 20% of engineering tasks often take the most time, indicating agents are not fully autonomous for complex refactoring. Source reliability is high as it is a first-person account, but specific costs and timelines may vary by project complexity.
Try it
I want to migrate my website from a headless CMS to static Markdown files using Cursor. My site is built with [replaceable: Next.js/React]. I have API access to the CMS. Please create a plan to export all blog posts and marketing pages into Markdown files in the /content directory. Write a script to fetch the data, convert it to Markdown, and save images to [replaceable: object storage path]. Run the script and then use Cursor agents to update the codebase to read from these local files instead of the CMS API. Before applying any changes to the main branch, show me a diff for one sample page and confirm the rendering matches the original. Do not proceed with the full migration until I approve the sample. If errors occur, stop and report them.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.