Collection caps, item limits, and shallow reference depth begin dictating the content model instead of the other way around.
Real component architecture
Components with props and typed content, instead of symbols, duplicated classes, and combo-class archaeology.
Integrations without embeds
Custom code blocks and injected scripts replaced with first-class integrations you can test and version.
Git-based workflows
Branches, code review, preview deploys, and rollback, instead of everyone editing one shared canvas.
Performance headroom
Zero JavaScript by default and static edge delivery, rather than a fixed platform runtime you can't tune.
Marketing autonomy stays intact
A visual CMS layer keeps editors publishing without filing developer tickets.
Honest assessment
When Astro is, and isn't, the right answer.
Most Webflow teams should move to Framer. This page is for the ones whose site genuinely needs a coded stack.
Move to Astro when
You've hit CMS collection or item limits
Content needs to be reused across pages and channels
Integrations require real control and testing
Multiple people need to work in parallel safely
Performance matters commercially
You want a design system, not a class soup
Move to Framer instead when
The site is a marketing or content site
Nobody on the team wants a Git-based workflow
Marketing wants to design and publish visually
You have no appetite for a build step
You want the lowest running cost and effort
What happens to your Webflow project?
Usually it gets decommissioned once content has moved and redirects are live. There's rarely a reason to keep paying for a platform nobody is publishing to.
Occasionally it's worth keeping on a cheaper plan as a landing-page sandbox for campaigns that need to ship without a deploy.
Decommissioned once redirects are live
Kept temporarily during a phased migration
Campaign pages rebuilt in Framer if marketing wants a visual tool
Blog kept in Webflow, marketing pages moved
Publishing experience
Autonomy doesn't have to be the trade.
The reason teams hesitate to leave Webflow is the visual editor, not the platform. You can keep the editing experience and lose the constraints.
Edit pages visually
Editors work in a visual interface with live preview, not YAML in a repository.
Guardrails by design
Pages are composed from approved components, so the design system survives contact with a deadline.
Structured underneath
Everything the editor writes is typed, validated content that other pages and channels can reuse.
Architecture
How it fits together.
Integrations (CRM, analytics, forms, search) attach at the build or edge layer instead of living in custom code embeds.
Headless CMS
Editors work visually
Content stored as typed collections
Roles, drafts, and preview built in
Astro
Components and content collections
Static output, zero JS by default
Git-based, previewable, reviewable
CDN hosting
Served static from the edge
No platform runtime in the way
Instant global performance
Process
How the migration actually runs.
Discovery and audit
Every collection, template, symbol, interaction, custom code embed, and redirect in the current Webflow project gets catalogued.
Content model
Webflow collections are re-modelled as proper content collections with the reference depth the site actually needs.
Design
Existing design translated into a real component system, or refreshed if that's what the project calls for.
Build and migrate
Astro build, component library, CMS wiring, and scripted content migration with a reconciliation pass.
Validate
Redirect testing, Core Web Vitals, accessibility audit, analytics parity, and a full content diff against the old site.
Launch and monitor
Staged DNS cutover, then Search Console, crawl errors, and vitals watched closely for the first weeks.
Content migration
Content moves by script, not by hand.
Export collections
Webflow CMS collections are exported via the API, including reference and multi-reference fields the CSV export flattens or drops.
Convert static pages
Static page markup and combo classes are translated into components, with design tokens replacing one-off class overrides.
Assets
The asset library is migrated, re-optimised, and re-referenced, including anything hotlinked from the old CDN.
Reconcile
An automated diff compares every source URL against its destination so nothing is quietly lost in transit.
SEO & redirects
The part that decides whether this goes well.
Full URL inventory
Every indexed URL is pulled from Search Console, analytics, the sitemap, and a fresh crawl, not just the ones the CMS knows about.
Redirect map
A one-to-one 301 redirect map, built and tested against the live inventory before launch.
Metadata parity
Titles, descriptions, canonicals, Open Graph, and structured data carried across and diffed page by page.
Crawl and index
Sitemaps, robots, and internal linking rebuilt, then submitted and monitored through Search Console after cutover.
Post-launch watch
Rankings, crawl errors, redirect hits, and Core Web Vitals monitored for the first weeks, with fixes shipped fast.
Not if the redirect map, metadata, and internal linking are handled properly, which is most of what this project actually is. Expect short-term fluctuation and a return to baseline or better within weeks.
Do we lose the visual editor?
No. A visual CMS layer sits on top of Astro so editors keep composing pages from approved components with live preview.
What happens to our Webflow interactions?
They get rebuilt as real animation code, usually cleaner, and no longer limited to what the interactions panel can express.
Can we keep the current design exactly?
Yes. Migrating as-is is a legitimate choice and often the right one when the design is working and the platform isn't.
How long does it take?
A straightforward marketing site is six to eight weeks. Several hundred CMS items with a redesign and complex integrations is typically twelve to twenty.
We've built a lot in Webflow. Is any of it reusable?
The design decisions are. The implementation mostly isn't, and that's the point: you're moving because the implementation layer is what's limiting you.