Leave Webflow, Framer, WordPress, or Ghost without a pretty-rebuild hangover

You have outgrown Webflow, Framer, WordPress, or Ghost, and you are about to hire a shop for a "rebuild," let an agent ship a marketing site over a weekend, or delay another quarter. A measured migration keeps the business intact while the renderer changes: URLs, analytics, forms, and a lab baseline before anyone touches design. Clearly Design rebuilds in Next.js or Astro, runs the same measurement after cutover, and writes what improved and what did not. This is not a prettier template swap. Below is who it fits, what the engagement includes, and when you should stay in the builder.

Who this is for (and who should stay in the builder)

This is for Series A to growth SaaS teams, and specialist B2B firms that sell like SaaS, when the marketing site argues with the product. Two design systems. Experiments that are just another script tag. Editors who can ship a page but cannot own performance, redirects, or SEO. A CMS shape that breaks on calculators, portals, or localized routes. Or a stack the product team can actually call when marketing needs to share components or auth.

Say it plainly: this is not for teams that only need a prettier marketing page and are happy in the builder. If you are still in that decision, start with Framer vs Webflow for SaaS marketing sites (who edits after launch) or Framer vs custom development (builder vs Next.js). If you have already decided to leave, this page is the measured cutover offer.

Rebuild vs measured migration

Why not just vibe-code it yourself

A first deploy can look right in a weekend. The hard part is everything that has to stay true after cutover. We are not anti-AI. We are pro-ownership of the boring jobs that decide whether marketing still works in month two.

Deploys. Preview is not production. Env vars, DNS, and rollback should not mean hoping the old host is still up.

Analytics. Events that still fire after cutover. Consent behavior. A rebuilt tag plan, not a pasted GTM container.

Page speed. LCP image, fonts, third parties, Core Web Vitals. Local "feels fast" is not the mobile lab.

Forms. Validation, spam, CRM handoff, thank-you URLs that should not rank.

Security. Headers, dependency updates, secrets out of the repo, gated tools not left open.

SEO continuity. Apex vs www decided once. One canonical. Redirect map. Sitemap. Real schema. Keep URLs that already have impressions.

Content ops after launch. Who edits a page, what is noindexed, what breaks when a collection changes.

Example (problem class, not a win): on a baseline we captured on 2026-10-04 for a Webflow marketing site (Hire Team Up, migration in progress), the mobile lab homepage showed performance 37, LCP 9.7 s, and 1,296 KiB transfer while document TTFB was fine (~15 ms, Cloudflare cache HIT). Desktop on the same run was 88 with 1.4 s LCP; an about template hit 18.8 s LCP. The LCP element was a lazy-loaded PNG. Render-blocking Webflow JS was estimated around 2,620 ms on the critical path. The homepage canonical sat on apex while apex 301s to www. We cite this only to show the class of issue a cutover has to fix. We do not claim a post-live delta until the same lab method runs after go-live.

We have also shipped custom marketing surfaces from Ghost (churnkey.co/blog) and WordPress (suggestionox.com). That is platform range, not a performance brag on those domains.

Astro vs Next.js — how we choose the stack

Same engagement either way. The stack is a recommendation, not the product.

Choose Astro when the site is content-first, islands are enough, marketing stays separate from the product app, and Core Web Vitals on organic pages are the brief.

Choose Next.js when marketing needs to share product UI, auth, design-system packages, middleware, or app-like tools (calculators, gated flows, experiments) with the product.

The usual SERP advice ("content site → Astro, app-adjacent → Next.js") is directionally right. Our addition: we pick after the baseline and sitemap, not before a stakeholder workshop picks a logo font.

What the engagement includes

1. Discovery + baseline — Sitemap, templates, forms, third parties, redirect intent. Lab performance on the homepage (mobile and desktop) and two to three real templates, same method every time.

2. Design / system carryover — What stays pixel-close, what moves into the product design system, what gets deleted. CMS collection inventory, not a clone of every builder interaction.

3. Custom rebuild (Astro or Next.js) — Pages that actually rank or convert. Shared layout. Fonts and images done properly: no lazy-loaded LCP image, no builder JS on the critical path.

4. Content / CMS migration — Map collections to MDX, a headless CMS, or both. Keep URLs that have impressions unless there is a deliberate reason not to.

5. Redirects — Apex vs www once. One redirect map. Thank-you and thin archives get deliberate index or noindex.

6. QA — Forms, analytics events, consent, 404s, canonicals, schema as valid JSON-LD. GTM rebuilt, not pasted.

7. Cutover — DNS, cache, first-hour monitoring. Old host as rollback only, not a second canonical.

8. 30-day post-live comparison — Same URLs, same lab method, same fields, plus Search Console and analytics once access exists. A short written diff, including anything that got worse.

How we measure (the proof, not a promise)

Before cutover (public): lab LCP, CLS, FCP, Speed Index, TTI, performance score; mobile and desktop home; mobile on main templates; TBT as a lab INP proxy when field INP is missing; JS weight, transfer, and requests; document TTFB and cache headers; third-party list.

After go-live: identical URLs and method; both JSON runs kept on file.

With access (ask day one, do not block the build): Search Console clicks, impressions, indexing, field CWV; analytics conversion events you already care about.

We publish numbers only from those runs. If a tool fails, we say which tool and what replaced it.

Proof set (what we can say today)

Hire Team Up is the template for the before/after story once post-live lab runs exist. Until then, the offer is the method: baseline first, same URLs, written diff.

Package shapes (and how pricing works)

We do not publish fixed dollar amounts for a one-time migration package on this page. Shapes only:

Standard rebuild — Known template set (home, a few landers, blog/resources, legal, forms). Baseline → rebuild → content move → redirects → QA → cutover → 30-day lab comparison. Design carried over, not a new brand.

Advanced — Standard plus real design-system handoff (tokens and components the product team can import) and portal or app hooks: logged-in entry, a calculator or tool that should not be a builder embed, experiments, content synced with the product. Still not a full product build.

After either shape, many teams want the site to keep moving the month the project ends. That is a design-build subscription or broader product design subscription beside engineering — the design partner for SaaS model. Clearly's public monthly rates (Standard $4,995/mo · Advanced $7,495/mo) apply to that ongoing delivery; confirm inclusions on homepage pricing.

When you should not leave yet

Stay in Webflow, Framer, WordPress, or Ghost when the site is small, launch speed beats deep control, marketing needs day-to-day visual editing, and SEO and ops requirements are still straightforward. Framer vs Webflow and Framer vs custom cover stay-or-leave while you are still in the builder. CMS choice and migration are related but different jobs; we are not rebuilding a full CMS chooser essay here.

Related decisions

• Framer vs Webflow for SaaS marketing sites — who edits after launch while you stay in a builder.
• Framer vs custom development — whether a visual builder is enough vs Next.js.
• Design partner for SaaS — embedded partner model after the platform call.
• Product design subscription — queue vs ownership for ongoing product design.
• Design-build subscription — when monthly should include Framer, Webflow, or React shipping.
• Marketing and product UI consistency — shared tokens across surfaces.
• Optional: designgov.md when AI governance for the new repo is part of the brief.

Still deciding whether to leave Framer for code? Read Framer vs custom development before you book. Ready to baseline the live site? Book a discovery call from the homepage.