Companies move from Webflow to Astro when the site builder hits a ceiling: CMS collection limits, capped custom code, and hosting that cannot be moved off the platform. Astro solves this by building the site into static HTML at build time and defaulting to zero client-side JavaScript - the project code becomes the team’s own property instead of something rented from Webflow. Below are the concrete limit numbers and the step-by-step migration process that avoids losing content or search rankings.
In Exceltic.dev web development projects we consistently see the same tipping point: a marketing site on Webflow ran fine while the CMS held 500-1,000 entries and a dozen custom scripts. Past 2,000+ items in a collection, and after one more block of custom code in an Embed element, Designer build speed and page responsiveness start to drop.
According to Webflow’s official documentation, updated in May 2026, the Premium plan caps a project at 40 CMS collections and 20,000 items, and the character limit for the Custom Code block is fixed at 50,000 characters regardless of plan. For a site with a blog, case studies, job listings, and multiple language versions, that ceiling covers 1-2 years of active content growth - no more.
The rest of this article covers what gets lost in a naive migration, how a pre-migration audit works, why Astro’s architecture specifically closes these limitations, and what Core Web Vitals numbers projects typically land on after the move.
The problem is not abstract. The marketing team cannot add a needed tracking script because it hit the Custom Code character limit. A developer cannot wire up their own CI/CD pipeline because hosting is locked to Webflow’s infrastructure. And a manager cannot calculate the real cost of ownership because the price climbs with every new plan threshold tied to collection and item counts.
Why companies leave Webflow
The decision to leave the site builder is almost never about design - Webflow remains a strong tool for fast visual builds. Companies leave because of three recurring limitations: the CMS ceiling, capped custom code, and hosting lock-in.
Vendor lock-in: a situation where moving a project to another platform is technically possible but requires rebuilding all the logic and data from scratch because of a proprietary storage format. Webflow stores content, interactions, and logic in a closed format that does not export in working form - only static markup exports, without the CMS data.
Every interaction added in the Webflow Designer - a scroll animation, a hover effect, a page transition - lands in a single shared webflow.js file that loads in full on every page of the site, even if that particular page uses none of those animations. As the number of interactions grows, so does the weight of that file and its client-side execution time, regardless of whether the visitor ever sees those effects.
Support costs stack on top: Webflow’s pricing tiers are tied to project growth - the number of CMS items, collections, and hosting traffic. Content and traffic growth converts directly into a rising monthly bill, while the project’s own code still does not belong to the team. WordPress site owners know a similar dynamic: they also hit a performance ceiling past a certain volume of content and plugins, just for a different technical reason.
What gets lost in a naive migration
A direct “as-is” move without a plan almost always destroys part of the signals built up over years: URL structure, redirects, metadata, and content tied to Webflow-specific entities.
Webflow CMS collections do not export together with their data - only the HTML template comes out, without content. Every collection item - a blog post, a case study, a job listing - has to be pulled out separately via the Webflow CMS API or Designer API, or the dynamic pages end up empty after the move.
Forms on Webflow run through a built-in handler that does not carry over to external hosting: without migrating to a third-party form-handling service or your own backend, every form on the site stops submitting data on the day of the move.
Webflow’s collection URL structure and slug patterns do not always match what makes sense for the new stack - without a 301 redirect map, part of the accumulated SEO value of the pages is lost over the following weeks, until Google reindexes the new addresses.
Animations and interactions that depend on Webflow’s own JS engine do not work outside the platform - webflow.js stays tied to Webflow’s infrastructure, and after export those effects simply stop firing.
Pre-migration audit checklist
Before designing the new architecture, you need to inventory everything currently holding the site together on Webflow - otherwise part of the content and logic gets lost unnoticed.
- CMS collections and the relationships between them - how many collections, how many items in each, whether there are multi-reference fields that will need to become relations in the new data model
- Custom code - all the code in Page Settings, Site Settings, and Embed elements: what each script does, where it pulls data from, which third-party services it calls
- Forms and their recipients - where form data currently goes: an email service, an external lead-intake system, an automation scenario
- Integrations and tracking - GA4, ad platform pixels, chat widgets, A/B tests
- URL and redirect map - the full list of current addresses, including collection pagination, tags, and filters
- SEO metadata - title, description, Open Graph tags, and structured data for every page template
The new Astro stack architecture
The target architecture for a content or marketing site leaving Webflow is Astro on top of a headless CMS, with rendering happening at build time rather than in the visitor’s browser.
Islands architecture: an approach where a page renders to static HTML with no JavaScript by default, and interactive elements - a form, a slider, a calculator - load as separate “islands” only where they are actually needed.
Astro solves three Webflow limitations directly:
- Hosting stops being a lock-in point - the built static site deploys to any infrastructure: Vercel, Netlify, Cloudflare Pages, or your own server
- Custom code is no longer capped by the Embed element’s character limit - any logic is written as regular code in the repository, versioned through git, and run through CI
- Content lives in a headless CMS - choosing the specific platform depends on the team and budget - with no ceiling on collection or item counts tied to a pricing plan
Because rendering happens at build time, the browser receives finished HTML without waiting for a framework to execute - this is the direct reason Astro sites consistently show low LCP compared to sites that rely on client-side rendering or a platform’s own JS runtime.
Step-by-step migration process from Webflow to Astro
1. Export content via the Webflow CMS API
Every collection is exported through the Webflow CMS API in JSON format - this is the only way to get the actual data, not just the template. The export is normalized to match the new headless CMS schema, including multi-reference and rich-text fields.
Example request to the Webflow CMS API
curl -X GET "https://api.webflow.com/v2/collections/{collection_id}/items" \
-H "Authorization: Bearer {token}" \
-H "accept-version: 2.0.0"2. Build components in Astro
Every Webflow visual block (hero section, testimonials, case study cards) becomes a separate .astro component. Animations that ran on webflow.js in Webflow get rewritten in CSS and IntersectionObserver, or with a lightweight library like Motion One - with no shared runtime file loaded on every page.
3. 301 redirect map
Every live URL is mapped to its new address. Redirects are configured at the hosting or CDN level before the DNS switch, to avoid a gap in indexing.
4. Migrate forms and integrations
Forms switch to a serverless function or a third-party lead-intake service; tracking scripts and pixels move directly into the project code, with no character limit.
5. Testing and launch
Before the DNS switch, you verify: that forms work, that redirects are correct, that metadata matches for every template, and page speed via PageSpeed Insights on the staging domain. The domain switches only after staging passes every check.
Core Web Vitals before and after
Webflow sites with an active set of interactions and connected third-party scripts typically show LCP in the 3-5 second range and INP above 200ms on mobile - because of the shared webflow.js file that executes on every page regardless of whether that page needs it.
In a typical Webflow-to-Astro migration of a content site, LCP drops to 1.2-1.8 seconds, and INP falls within the “good” threshold - under 200ms, per the Core Web Vitals methodology - on nearly every page except ones with heavy interactive widgets. CLS usually needs no dedicated work: Astro reserves space for images by default through its built-in <Image /> component.
The improvement comes from the architecture, not small optimizations: the browser gets finished HTML without waiting for a JS runtime to execute, and interactivity loads only where a page actually needs it.
Common mistakes when moving
- Moving without a redirect map - a drop in search rankings over the 2-4 weeks after the move, until Google reindexes the new URLs as replacements for the old ones
- Manually copy-pasting content over - relationships between CMS items (multi-reference fields) that worked out of the box in Webflow get lost
- Forgotten third-party scripts - tracking pixels and chat widgets baked into Custom Code do not carry over automatically and fall out of the new site
- Skipping the forms audit - leads stop arriving on the day of the move, because the old Webflow form handler only worked inside its own infrastructure
- Skipping staging tests - switching DNS before checking redirects and metadata on a test domain
Who this is for
Moving from Webflow to Astro solves this pain first for companies with a growing marketing or content site: 15+ employees, an active blog or case study library, a team that has hit the limits of its pricing plan or wants to own its code instead of renting infrastructure. If you are planning a site migration off any site builder to a modern stack, a pre-migration audit is the universal first step regardless of the source platform. For a single-page landing site with no active content growth, the migration can be overkill - the Core Web Vitals difference will not pay back the cost of the move if the site is simple to begin with.
Frequently asked questions
How long does a Webflow-to-Astro migration take?
For a site with a blog and case studies (50-200 pages, including CMS items), the typical timeline is 3 to 6 weeks, covering the audit, component build, content migration, and redirect testing. The timeline grows in proportion to the number of unique page templates and custom interactions that need to be rewritten from scratch.
Do you lose search rankings when moving to Astro?
Rankings are not lost if the 301 redirect map covers every live URL and metadata carries over unchanged at launch. A temporary dip of 1-2 weeks is possible due to reindexing, but that has nothing to do with the stack itself - the same thing happens with any domain or URL structure change.
Can you keep part of the site on Webflow and move the rest to Astro?
Technically yes, through a subdomain or a separate path, but it is rarely worth it: two different stacks increase maintenance complexity, and part of the problems - the CMS limit, the custom code cap - stay in place wherever the site remains on Webflow.
Do you need a headless CMS for a Webflow migration, or can content live in files?
For a site with a few dozen pages, markdown files in the repository are enough. For a site with an actively growing blog, case studies, or job listings, where non-technical staff edit content, you need a headless CMS with an admin panel - otherwise every content update requires a developer.
What happens to forms after leaving Webflow?
Forms switch to a serverless function (on Vercel or Netlify Functions, for example) or a third-party lead-intake service. All the validation logic and recipients need to move over before the DNS switch, so you don’t lose a single lead on launch day.
If your Webflow site has hit the CMS collection limit, or the plan cost is climbing faster than your content volume justifies - describe your current site’s architecture to the Exceltic.dev team. We’ll run an audit and estimate the scope of a move to Astro.