When to move off Framer or Webflow, and when not to

Framer and Webflow are very good at what they do. A designer can ship a polished marketing site in a week, edit it without a developer, and never think about servers. For most companies' websites, that's the right trade, and we tell people so.

But some teams hit a point where the site builder stops being the fast option and starts being the thing everyone works around. This article is for those teams: how to tell whether you're there, and what moving to your own CMS actually involves.

01When to stay where you are

You probably shouldn't switch if:

• Your site is mostly marketing pages, a blog and a contact form.
• The people editing it are designers or marketers who like the visual editor.
• Your content is a handful of flat lists: posts, team members, case studies.
• Nothing else in your business needs to read or write that content.
• You don't have someone to own a codebase once it exists.

If that's you, the money is better spent on content and design. A custom CMS solves problems you don't have, and gives you new ones: hosting, updates, and a developer to call when something breaks.

02Seven signs you've outgrown it

1. Your content has relationships

The first crack is usually structure. A blog post is a flat item. A therapy that treats several conditions, belongs to several programmes, and is delivered by certain practitioners at certain locations is a graph.

Site builders can model some of this with reference fields, but there are ceilings. At the time of writing, Webflow allows 20 reference fields per collection even on its Team plan. Framer's Pro plan includes 10 CMS collections, and you can pay to raise that to 40. When the content model is fighting the tool, editors end up duplicating content across collections, and duplicates drift apart.

We saw this with Biowell, a wellness clinic. Their therapies, health goals, conditions and programmes all link to one another, and every route through the site should end at a consultation. The finished platform has 39 content types. That's not a number you want to squeeze into a site builder's collection limits.

2. Every change needs a developer anyway

The promise of a site builder is that non-developers can publish. If your team is filing tickets because the page they need doesn't fit the existing templates, or because the CMS can't hold the content they're trying to add, you're paying for a no-code tool and still waiting on code.

Biowell's starting point was exactly this: every new therapy or programme needed a developer before it could go live. Afterwards, the clinical team publishes it themselves.

3. Your content needs to live in more than one place

Your booking system, email platform, mobile app or internal tools often need the same content as your website: the same services, prices, locations and staff. If someone copies that between systems by hand, it will eventually disagree.

An API-first CMS makes the content a source other systems can read and write. At Biowell, the CMS syncs with Mindbody, their booking system, so the site and the bookings work from the same records.

4. The limits and seats start to add up

Plans are priced on pages, CMS items, collections and editors. At the time of writing:

Check Framer's and Webflow's pricing pages for current figures, because they change. The point isn't that these tools are expensive; for a marketing site they're good value. It's that the costs scale with exactly the things that grow when your content gets serious: more items, more types, more editors.

5. You need logic, not just pages

Logged-in areas, gated content, approval workflows, per-user content, content that depends on stock or availability, forms that write to your own database. Each of these is possible on a site builder through embeds and third-party glue. Past a certain point, the glue is the product, and it's held together by tools you don't control.

6. You'd like to be able to leave

Lock-in is easy to ignore until you need to move. Framer doesn't support exporting your site as code. Webflow can export static HTML and CSS, but its CMS content isn't included in that export. With your own stack, the content sits in a database you own, and the front end is code you can host anywhere.

7. You need finer control over search and performance

Both tools handle the basics of SEO well. Where teams start to want more is in the details: structured data generated from the content model, server-side redirects at scale, exact control over what's in the HTML, crawler rules at the edge, and page weight. If search and AI visibility matter to your business (we wrote about that in SEO, GEO and AEO are one problem), owning the rendering layer gives you every lever.

03A quick decision table

One or two "consider" rows isn't a reason to move. Three or more usually is.

04What a move actually involves

A move to your own CMS doesn't mean building a CMS from scratch. The usual shape is a headless CMS for the content and a modern front end for the site. For Biowell that was Strapi, open source and self-hosted on PostgreSQL, with a Next.js front end. Here's how a move like that tends to go.

1. Model the content first. Before any code, write down the content types, their fields and how they relate to each other. This is the most valuable step. It's also where you find out what your site builder was hiding: half the "pages" turn out to be the same type, and the other half have no structure at all.

2. Design the editing experience. The CMS is a product your team uses every day. Name fields in their language, add help text, set up previews, and decide who can publish what. If editors don't like it, they'll go back to asking a developer.

3. Migrate the content. Export what you can (Webflow exports CMS collections as CSV, and Framer does it through its CMS Export plugin), transform it into the new model, and import it through the CMS's API. Rich text and images usually need the most care.

4. Keep every URL, or redirect it. Map each old URL to its new home and set up permanent (301) redirects before launch. This is what protects your search rankings. Skipping it is the most common way a migration costs traffic.

On Biowell, the old /therapy/ pages became /treatments/. The redirect table lives in the CMS, about 50 rows, so an editor who renames a page can add its redirect without waiting for a deploy. Some old URLs take two hops, /therapy/cryotherapy/ to /therapy/cryotherapy to /treatments/cryotherapy, which is well within what search engines follow. Biowell uses 308 rather than 301: search engines treat the two the same way.

5. Run both, then switch. Build the new site on a staging address, have editors publish real content in it for a week or two, then move the domain.

6. Plan for afterwards. Someone has to own hosting, updates, backups and the occasional bug. Budget for it honestly, whether that's your own team or a partner.

05A middle path

You don't have to move everything at once. A common pattern is to keep the marketing site where it is and move only the structured, connected part (the product catalogue, the knowledge base, the service directory) into a headless CMS that other systems can read. You get the editing speed of the site builder for campaign pages, and a proper data model where it matters.

06In short

Site builders are the right default. Switch when your content becomes data: when it has relationships, feeds other systems, or needs logic. When you do, start with the content model, protect your URLs, and make the editor experience something your team actually wants to use.

If you're weighing this up, we're happy to look at your setup and tell you honestly whether it's worth it.