CMS migration: moving your site to code, and the day after

Marketing teams are moving their websites out of CMSs and into plain code, and the writeups all skip the same thing: how the team edits the site afterwards. In this post I’ll map the four editing setups actually in use, the costs nobody adds up, and what I’d do differently, from running these migrations for clients. The receipts from every published migration are in a table at the end. It’s plain markdown, so feel free to hand it to your agent.

A year ago, moving your marketing site off a CMS was a weird thing to do. Now the smartest teams are lining up for it (Eric Linssen’s roundup put the trend on the map):

Sentry: 2,500 pages off Contentful. Web Vitals 89 to 97. ~4x conversion.
Cursor: CMS deleted in 3 days for $260 in tokens. $57k/yr in CDN costs gone.
StackOne: left Webflow. Mobile Lighthouse 42 to 92.
Vellum: off Webflow in a week. $30k/yr saved.
Prefect: rebuilt by their VP of Product. Not an engineer. One week.

These aren’t experiments. The logic is simple. A CMS keeps your content in a vendor’s database where AI agents can’t touch it. Move it to plain files in a git repo and agents can do all the work that never got off your backlog. Internal links, content refreshes, technical SEO, landing pages in an afternoon.

One thing to get straight: most CMS migration guides are about swapping one CMS for another. WordPress to Contentful, Drupal to something headless. Same model, new landlord.

This post is about the other kind: taking your content out of a CMS and into plain files in your own repo. The trend is the second kind. So is everything below.

I’ve read every writeup in this genre back to back. They’re good. But they all end at the same moment: launch day, speed score screenshot, victory lap.

Not one answers the question a marketing leader should ask first:

After the migration, how does my team edit the website?

I run these CMS migrations for clients (we just moved inflection.io, and we’re moving Demand Collective’s own site as I write this). We hit this wall on every project. I’ve started calling it the day-after problem, and it decides whether the migration was worth doing at all.

Here’s what’s on the other side.

1.) The posts go quiet at the exact same spot

Watch how each one handles the editing question.

Lee Robinson (Cursor): the marketing team got added to GitHub. Half a sentence.

Sentry: non-engineers open pull requests through Claude Code.

Sid Bharath: “maybe you can train them.”

Behaim listed “content editable by non-technical staff” as a hard requirement at the top of their post. Then never mentioned it again.

“…the one area where WordPress genuinely has the edge.”

Behaim, on non-technical editing, in a 5-week migration writeup that never solves it

That’s the state of the art. It’s not an answer.

And it’s not just editing. A CMS quietly does boring work a git repo doesn’t do on its own. Drafts. Preview links for sign-off. Scheduled publishing. A place to fix a typo without knowing what a merge conflict is. Nobody mentions where those features went. They didn’t move. They disappeared.

2.) The four editing setups (and who each one is really for)

Across every migration I’ve read or run, there are only four.

The marketer in the terminal. Chris Shuptrine (VP Marketing, Torii) builds landing pages himself with coding agents. Works if you have that rare marketer who was building with AI before this trend had a name. Most teams have zero or one of them.

My warning here: this one is a bit dangerous at scale. When marketers change lots of pages through coding agents, the site starts to look generic. AI-made. Typography drifts, spacing goes off, layouts stop matching. The person editing doesn’t notice. Visitors do. And editing a component you don’t fully understand can break pages you never opened.

The Slack-to-agent pipeline. Prefect’s version: drop a request in #website, it routes to Linear, an agent does a first pass, a human reviews. Genuinely new. But be honest about what it is: a ticket queue with a faster back end. Great for new pages. Slow for “change this headline.”

Marketing as PR authors. Cursor added marketing to GitHub. Sentry frames the migration as upskilling the whole team. Those skills compound, I’m for it. But as the default workflow, your content calendar now depends on how everyone feels about branches and merge conflicts. Sentry’s marketers sit next to engineers all day. Most don’t.

A visual editor that writes git commits. Content stays as plain files in your repo. Humans get a visual layer on top. Click the section, change the words, save. The save is a git commit. Previews build to a private link. Publish merges to main. Rollback is one click.

Full disclosure: this is what we build. Siguro CMS is that fourth option on top of the Astro site your developers (or we) built. We built it because every migration ended with the same client conversation: this is great, but how does the team edit it now?

One thing I’d push back on from the genre: people assume agents are for the big jobs. I think a lot of their power is in small edits. Count what changing one word used to cost. Log into the CMS. Forgot the password, reset it. Find the page. Find the section. Edit, save, publish. Marketers die by a thousand of these cuts every week. We’re way past the point where agents can handle that. The interesting frontier is agents generating whole page sets from rules you set once. That’s where this is heading.

3.) The costs nobody adds up

Tokens are the headline, people are the bill. “$260 in tokens” was 3 days of one of the best web engineers in the industry. StackOne’s “two weeks of evenings” was both founders plus a marketing lead. Our fastest client migration took one day, and that’s still a day of people who’ve done it before. Budget the humans honestly and the project survives the CFO conversation.

The new bill nobody mentions: what does your team’s AI access cost? If the whole marketing team works through Claude now, that’s either top-tier subscriptions for everyone (likely more per month than your old Webflow hosting) or API usage that swings every month. This bugged me enough that we built around it: one shared API key, cost visible per person and per task, and the CMS routes each job to the right model. Simple text change goes to a cheap fast model. Building a page goes to a big one. Marketers on raw Claude Code don’t get any of that.

4.) Don’t redesign. Go page by page.

Everyone assumes matching the old design is the hard part. It isn’t, if whoever runs the migration cares about details.

The actual trap: deciding that since you’re doing this anyway, you may as well redesign everything. Don’t. Move your homepage and key product page first, make them great, do the rest as you go. That’s what we did with inflection.io. It’s what big companies quietly do too. Intercom (now fin.ai) has redesigned more than once and you can still find old-style pages on their site from years back. They ship what matters and let the long tail catch up.

AI lets you move fast now. A big up-front redesign is how you throw that speed away.

5.) Nobody publishes the traffic numbers

Every post shows a speed score. Zero show organic traffic 30 or 90 days later. I don’t think the news is bad. I think most teams don’t measure it.

Vellum came closest, watching hour by hour through launch week because one page drove 80% of their organic traffic. Copy that:

Map every old URL to a redirect before launch.
Rebuild canonicals, sitemaps, structured data, and social tags on purpose.
Watch Search Console daily for two weeks.

Webflow and WordPress did this invisible work for you. In a repo, it exists only if someone builds it.

6.) The real prize is owning the repo

This is the part of the trend I agree with most, and it’s bigger than the AI angle.

Static files in your own repo means you’re not at anyone’s mercy. Vercel getting expensive? Spin up a cheap Hetzner box and be moved in a couple of hours. Netlify, Railway, Render, Cloudflare, all fine. The site is static, it runs anywhere. Try that with a Webflow site or a WordPress install wired into twelve plugins.

If an agency migrates you off Webflow and onto their own platform, you’ve just signed a new landlord. Demand the repo in your GitHub, hosting on your accounts, and an editing setup your team can use without calling whoever built it.

7.) The CMS migration checklist

The writeups tell you migration is easy. Then you find out on launch night what your CMS was quietly doing for you.

This is the list I run on client migrations, in order.

→ It’s plain markdown. Copy it into your agent and have it check every box against your site.

Before you commit

Decide how the team edits the site after launch. Pick one of the four setups above and get the actual humans to agree to it. Solve the day-after problem first.
Pull your top pages from Search Console. Know which pages drive 80% of your organic traffic before you touch anything.
Inventory everything: pages, posts, images, forms, existing redirects, tracking scripts.
Budget people time honestly, not just tokens. Days for a small site, weeks for a big one.

During the build

Move the homepage and your key product page first. Match the current design. No redesign.
Run copy parity checks so nothing gets silently dropped or reworded. Behaim wrote 419 tests for this. An agent can write yours.
Rebuild what the CMS did invisibly: canonicals, meta titles and descriptions, social tags, sitemap.xml, robots.txt, structured data.
Rewire forms and analytics, then test them. A migrated site with a dead demo form is worse than a slow one.

Launch

Map every old URL to a 301 redirect before DNS moves. Every single one.
Submit the new sitemap in Search Console the same day.
Crawl the live site for 404s and broken internal links.

The two weeks after

Watch Search Console daily. Impressions and positions on your top pages, not just the totals.
If one page drives most of your traffic, watch it hourly through launch day like Vellum did.
Decide where drafts, previews, and scheduled posts now live. If the answer is nowhere, that’s a decision too.

CMS migration questions I get

What is a CMS migration?

Moving your website’s content from one CMS to another, or out of a CMS entirely into plain files in a git repo. This post is about the second kind, which is where the trend is heading.

How long does a CMS migration take?

The published range runs from 3 hours for a small blog to 2 months for 2,500 pages. Our fastest client migration took one day, with people who had done it before. Budget by page count and by who’s doing the work.

How much does a CMS migration cost?

Tokens are the cheap part. Cursor’s whole migration cost $260 in tokens. The real bill is people’s time, plus whatever your team’s AI access costs every month afterwards.

Do you lose SEO traffic when you migrate?

Not if you do the invisible work on purpose: a redirect for every old URL, canonicals, sitemaps, structured data, then two weeks watching Search Console. Vellum held their traffic through launch. Skipping that work is how migrations go wrong.

What I’m watching

This is the situation in July 2026. Things are moving fast, and I’ll update this as more teams publish real numbers.

One more honest note: every published migration comes from an AI-native company with strong engineers who wanted to do it. Nobody writes up the failures. Nobody writes for the team with no developer. That gap says more about the genre than the risk, but keep it in mind.

My current take: “move your site to hard code” is the catchy version. The real shift is getting your content into git, because git is the one place agents, developers, and (with the right editor on top) marketers can all work on the same site without waiting on each other. The posts proved the migration. The editing setup is what you live with every day after.

Are you seeing the day-after problem too? If you’ve done a migration, I’d especially love to hear what happened to your traffic, since nobody publishes that. And who did I miss in the receipts below? I read all replies.

If you’re weighing a migration up, grab time with me, even if it’s just to sanity-check the plan your dev team is proposing.

The receipts

→ This table is plain markdown. Give it to your agent, along with the linked posts, and ask it to build the migration checklist for your site.

Who	Migration	Time and team	What they reported
Sentry	Contentful + Gatsby to Astro + Markdown, ~2,500 pages	~2 months, 2.5 devs	Web Vitals 89 to 97, builds 14 to 4 min, ~4x conversion
Cursor	Headless CMS to code + Markdown	3 days, solo	$260 in tokens, 279k lines deleted, $57k/yr CDN saved
StackOne	Webflow to Astro + MDX on Cloudflare	2 weeks of evenings, 3 people	Mobile Lighthouse 42 to 92, new pages in 1 to 2 hours
Prefect	Headless CMS to MDX + Next.js	~1 week, solo (VP Product)	Landing pages in 30 min instead of 2 weeks
Vellum	Webflow to Next.js + Sanity	1 week, marketing team + CTO	$30k/yr saved, SEO held through launch
Behaim	WordPress to Next.js, two languages	5 weeks part-time	49 pages, 419 tests, word-for-word copy checks
Pauline Narvas	WordPress to MDX	One afternoon	367 posts moved in ~4 hours
Sid Bharath	WordPress to Astro + MDX	3 hours	PageSpeed 67 to 100, hosting $20 to $0/mo
ichi.co.uk	Ghost to Next.js + MDX	Not shared	Open-source converter tool

Looking for a specific path? Webflow to Astro is the StackOne pattern. WordPress to Astro is Sid Bharath’s 3 hour version, or Pauline Narvas’s one afternoon for 367 posts.