If marketing has to ask engineering for every change to the site, a coding agent offers an appealing way out. It can read the code, modify the content, and prepare a preview for someone to review. That possibility opens up a harder discussion than how to build a page: what does the site need to change so that marketing can run it day to day?
Two software companies arrived at different answers. Vellum, which builds AI tools, moved off Webflow and kept a content management system (CMS). Sentry, which helps engineering teams detect and diagnose errors in their applications, moved its content into files and rebuilt the publishing flow around code. Both expanded what an agent could do. Each one left editing, permissions, and publishing in different places.
Where does the content live when marketing works with an agent?
Vellum changed the site and kept the editor
In May 2026, Anita Kirkovska described how Vellum migrated off Webflow, a visual platform for building and managing sites. The team rebuilt the public site with the Next.js framework, adopted Sanity to manage content, and used Postgres as its database. According to Kirkovska, the migration took a week, and the CTO moved most of the content over a weekend.
Sanity is a headless CMS. It stores content separately, and the public site queries it to display that content. That way, marketing could keep working with an editor and structured fields, while assistants connected to the CMS could propose changes to that same content. Changing a page and changing how the site displays it are operations the team can handle separately.
Kirkovska says Vellum stopped paying roughly $30,000 a year to Webflow and that it multiplied its publishing speed tenfold. The account gives the subscription cost they saved. To estimate the net savings, you’d still need the costs of infrastructure, services, and engineering work. She also mentions trouble reproducing designs precisely and keeping consistency across pages. The team could publish faster, but it still needed shared rules so each landing page would fit with the rest of the site.
Sentry moved content into files and rebuilt publishing
On Sentry’s marketing site, agents could modify the code, but the CMS content sat outside that loop. Matt Henderson explains that this separation complicated requests that touched both things at once in his account of the migration.
The team replaced Gatsby with Astro, another web framework, and moved the CMS content into files. According to Eli Lennox’s technical writeup, they migrated roughly 2,500 pages with 2.5 developers over a two-month window. They also consolidated about 200 custom-built pages into three templates.
Sentry reported that build time for the site dropped from fourteen minutes to under four, and that staging build failures fell by 95%. The team changed the framework, the templates, and the content management all at once. With those numbers, you can’t isolate the effect of dropping the CMS by itself.
What’s most telling is what they had to build so the site would still be editable. The team prepared reusable instructions so agents would ask for the right fields, validate images, and generate previews. Changes go through automated checks and human review before merging, and the site keeps technical controls over its content security policy. What the platform used to handle on its own ended up split between the repository, the tooling, and whoever approves the changes.
What do other migrations show?
At Prefect, a software company that coordinates data workflows, the VP of Product rebuilt the site in roughly a week’s worth of work, spread across part-time sessions. Change requests go from Slack to Linear, where the team manages tasks, and from there to Devin, a coding agent that prepares a first version for human review. When the case study was published, the site had been in production for about a week. The account shows how a request gets processed, though there’s still little track record for judging how it holds up over time.
StackOne, a company that offers integrations for software products, moved from Webflow to Astro in two weeks. It switched to writing content in MDX, a format that combines Markdown with web components, and deployed the site on Cloudflare Pages. Two founders and one product marketer did the work. Afterward they found redirects that had been left out, along with indexing, caching, and consent issues. Optimizing performance took longer than the migration itself. The company reported that its mobile Lighthouse score, a lab test, rose from 42 to 92. It took that measurement before reinstalling the cookie banner, so the score describes that specific configuration.
At Cursor, which builds an AI code editor, Lee Robinson recounts that the team moved content from a CMS into code and Markdown in three days and spent $260.32 on agent usage. That figure puts a price on model consumption. A full budget would also need to include the team’s own work, since they kept managing permissions, media assets, and per-language versions.
Scope also varies a lot between smaller projects. Pauline Narvas, who works at Vercel, a platform for deploying sites and applications, says she migrated 367 posts and five pages from WordPress to MDX in about four hours. Her public site was already running on Next.js, so the work consisted of changing where the content was managed. In the bilingual migration documented by Rory Miller, by contrast, it took five weeks of part-time work, 49 routes, and 53 proposed changes. Part of the work involved reorganizing a template of more than 1,100 lines, fixing language issues, and recovering passages the agent had paraphrased without being asked to.
These accounts help anticipate what might go well and what work shows up afterward. We found several of these cases in the public resources of No Devs Were Harmed, a Slack community for marketing teams looking to rebuild their sites with Claude, Anthropic’s assistant. To understand each migration, we relied on the accounts of the people who carried them out. It’s a sample dominated by teams with access to engineering and people who already knew how to code. Open questions remain about how many migrations get reversed, how much it costs to run the new site a year in, and what timelines a team with less technical support can expect.
Can an agent connect to the CMS a team already uses?
Yes. Here we use agentic CMS to describe a workflow in which an agent can act on structured content while the team keeps permissions, editorial states, and a change log. That workflow can run on files, on a CMS separate from the public site, or on a visual platform.
Sanity describes how it connects agents to its CMS through MCP, a protocol that lets a model use external tools. The agent can query, modify, and prepare content without losing the references between documents. That explanation comes from the vendor itself. For its part, Webflow’s MCP tools for managing content allow reading, creating, and updating CMS entries without opening the visual editor. Saving a draft and publishing it are separate operations.
That separation matters if the team’s problem is, say, that updating twenty product sheets takes too long. You can test whether the agent prepares the changes in the current CMS and leaves publishing in the editor’s hands. The criterion for choosing an AI website builder is usually what it lets you build. For choosing how to run the site, you also need to look at how what’s already published gets reviewed and corrected.
What work remains after migrating?
The site still has dependencies, credentials, services, and deployments that someone has to maintain. For a branded media team, that includes preserving the archive, keeping links working, and being able to correct a published piece. You also need to know who can touch a form, replace an image, or update every language version of a page without mixing them up.
If the URLs change, Google Search’s documentation on migrations with URL changes says you need to map old addresses to new ones, set up the appropriate permanent redirects, and review internal links, canonical tags, and references between language versions. Google also warns that search visibility can fluctuate during the transition. If the plan is to keep the URLs, check that pages keep their addresses and remain indexable.
When the framework, the templates, and the content all change together, it’s harder to figure out what caused a traffic drop or why a form stopped working. Likewise, to know whether the new architecture pays off financially, you need to count the work it takes to publish a correct change. Add up preparation, agent usage, review, fixes, services, and maintenance. One less subscription can come paired with more hours from the person who knows the repository.
How do you test which architecture works best?
| Team’s situation | What’s worth testing | What needs to be sustained |
|---|---|---|
| One main site, repeated components, and technical support | Content in files with changes reviewed in the repository | Content structure, access, previews, and deployments |
| Multiple editors, languages, or cross-referenced content | A dedicated site with a separate CMS connected to agents | Content model, coordination between editors, and permissions |
| A CMS that works, with delays on specific tasks | Giving the agent access to a few operations in the current CMS | Platform limits and control over who publishes |
In a test environment, ask whoever will run the site to create a landing page, fix a post, update a shared piece of data, and roll back a change. Run the same exercises with the current workflow and with the proposed one. Note who gets involved and how long it takes for the change to get approved.
| What to test | What the team needs to be able to do |
|---|---|
| Shared data | Update a piece of data and check which pages it changed on |
| Permissions | Let the agent prepare a draft while reserving publishing for the authorized person |
| Preview | Review what changed, including forms, links, and language versions |
| History | Identify who requested, modified, and approved the change |
| Recovery | Revert to a previous version without rebuilding the original request |
| Continuity | Edit and fix the site if the model becomes unavailable |
During the test, also check accessibility and form behavior. Make sure technical permissions reflect who actually has authority to publish. If the change reaches production sooner and the team can review, fix, and roll it back, the pilot gives you a reason to adopt the workflow. If every fix ends up back on engineering’s desk, you should factor that time into the cost of the migration.
Frequently asked questions
What is an agentic CMS?
It’s a content management workflow in which an agent can query or modify content with defined permissions. The team can tell a draft from a published piece, review changes, and recover earlier versions. That workflow can run on files, a headless CMS, or a visual platform.
Can you migrate off Webflow with AI and still use a CMS?
Yes. Vellum rebuilt its public site with Next.js, adopted Sanity as its CMS, and connected assistants to the content. Webflow also offers operations that let an agent prepare changes within its own CMS. The choice depends on which part of the workflow the team needs to change.
What should you watch out for with SEO when migrating a site with AI?
If the URLs change, prepare an address map, set up permanent redirects where needed, and review internal links, canonical tags, and hreflang. After launch, keep an eye on indexing. If the URLs stay the same, check that they still resolve and that pages keep their indexing signals.
Which teams does it make sense for to run their site with agents?
It’s worth testing when there are recurring requests, reusable components, and a clear way to review and roll back changes. If the site depends on multiple editors, languages, or relationships between pieces of content, test those operations with the people who’ll be maintaining them before settling on an architecture.