Everbase
Send your site
webflow to astro

Webflow to Astro or Next.js

Move off Webflow, onto code you own

When every change waits on a developer and the plan keeps climbing, I move the site to code your team owns. As a Webflow Professional Partner, I start with how your team actually runs the site, then decide Next.js or Astro in the audit.

Send your site

Fixed price from $5,000 typically 4–6 weeks 30 days of hypercare code in your name

The Everbase Stack

Astro or Next.js, with Sanity, on Cloudflare or Vercel.

Documented facts

What Webflow itself says.

Checked September 2026.

What moves

What actually migrates.

What you have What happens Why
Pages Rebuild Made again in the new codebase. The old version is a reference, not an import. Webflow exports the rendered HTML, CSS, JavaScript and assets. That is source material rather than an Astro component architecture, so it informs the rebuild instead of becoming it.
CMS content Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Collection data comes out separately from the code export, gets transformed, and lands in Astro content files or whichever headless CMS the new site reads from.
Interactions Rebuild Made again in the new codebase. The old version is a reference, not an import. They become CSS, written JavaScript or a motion library, and each one gets justified rather than carried across.
Forms and platform features Rebuild Made again in the new codebase. The old version is a reference, not an import. Form handling, search, localization, memberships and ecommerce are things the platform was doing. None of them are in an export, so each needs a destination chosen for it.
URLs Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Every public path stays unless there is a deliberate reason to change it, and the few that do change get a direct rule.

Mapping

Nothing here is a file move.

  • Webflow Collection A content model Fields, types and which of them are actually required, decided rather than inherited from whatever the Collection accumulated.
  • Collection item A content entry In Content Collections, or in a headless CMS, depending on who publishes and how often.
  • Collection template A route and components One template becomes a route that renders many entries, built from components the rest of the site shares.
  • Item slug A route parameter The existing URL is the input, not the output.
  • Multi-reference field A typed relationship References become real relationships the build can check, which is where most Webflow CMS structures gain rather than lose.

Hard parts

Where this migration gets complicated.

  1. 01

    Interactive behavior becomes deliberate code

    Astro can render most of a page without shipping component JavaScript to the browser, which is the reason to come here and cuts both ways. Everything configured in Webflow's Interactions panel gets reconsidered and then written by hand, and each one has to earn its island rather than be dropped onto the page.

  2. 02

    The editor has to be rebuilt, not just replaced

    Marketing could publish without a developer. After the move they can only publish what the new CMS was set up to let them publish, and every one of those fields is a build decision somebody makes.

Fit

Is this a fit?

A good fit when

  • Routine page changes wait on a designer or developer.
  • The CMS has outgrown collection limits or reference workarounds.
  • You want the code, content and hosting in accounts you own.

Not a fit when

  • The site is small, changes rarely and works well on Webflow today.
  • The team wants a designer to keep building pages visually without code.

Process

How the migration works.

  1. Audit

    Pages, collections, interactions and forms, written down while the site is still serving them.

  2. Rebuild

    Pages become components, Collections become a content model, and interactions get written rather than configured.

  3. Migrate

    Content and assets across, addresses and metadata preserved or remapped, forms and analytics verified before the switch.

  4. Hand over

    The repository, the migration map and documentation written for somebody who was not here.

Included

What is included.

  • Design rebuild

    Rebuilt as components, not approximated.

  • Responsive development

    Desktop, tablet and mobile, built and checked.

  • CMS architecture

    Collections and fields mapped before build.

  • Content migration

    Migrated and checked against the source.

  • Asset migration

    Collected, compressed and rehosted.

  • Forms and integrations

    Tested through to the final record.

  • URL coverage

    Every known public address preserved or deliberately redirected.

  • Metadata and canonicals

    Preserved wherever possible.

  • Search footprint preservation

    URLs inventoried before and checked after.

  • Pre-launch QA

    Forms, templates and old URLs verified.

  • Post-launch support

    30 days of indexing and traffic checks included.

After those 30 days, Continuous development is the optional way to keep shipping: $1,000 a month for the Everbase Agent, or $3,500 a month for the Partner Program (human QA on every deploy and one active request at a time), pause or cancel any month.

Search visibility can move during a migration. The goal is to preserve what search engines already understand, and to catch what changed quickly after launch.

And it is yours at the end. The repository sits in your organization rather than mine, the handoff documentation is written for somebody who was not here, and nothing about the project requires me: another developer or your own team can operate it.

Editing

Leaving Webflow does not have to mean handing every edit to a developer.

  1. 01

    Content Collections, in the repository

    For a team that publishes rarely and is happy in a pull request. The content is files beside the code, typed and checked at build time, with no service to pay for and nothing to keep running. It stops suiting you the day somebody outside engineering needs to publish without help.

  2. 02

    Sanity

    For a team that publishes regularly, or where the person writing is not the person deploying. Editors get a real interface, the model is explicit, and the site reads it at build time. It is another system to configure and pay for, and the modeling is the part that decides whether editors can work on their own.

  3. 03

    No CMS at all

    For a site whose pages change a few times a year. Everything lives in components, changes go through the same review as any other change, and there is no editorial layer to maintain. Honest for a small site, and the wrong answer the moment a blog is added.

Content Collections against a headless CMS, and how the choice is made.

Proof

A migration is not finished when the new site looks right.

  • 01 Codebase

    A codebase your team owns

    Components, routes and styles rebuilt deliberately, not cleaned up from exported markup.

    Verified by Repository and component structure

  • 02 Site

    Everything accounted for

    Collections, content, metadata and existing addresses checked against the source.

    Verified by Source inventory and migration checks

  • 03 Systems

    Handoffs that actually arrive

    Forms, analytics and CRM checked at their destination rather than at the button.

    Verified by Submissions, events and records

The migration is complete when these pass, not when the homepage looks right.

The figures above show the report's shape. Yours are counted from your own site.

See everything included in a migration

Maintenance

Built for people and agents to work on.

The important part is not that an agent can write code. It is that the project is structured well enough for its changes to be understood, reviewed and reversed.

  • Marketing

    Editor or AI assistant CMS Preview Publish

    On the headless CMS answer above. Choose content collections instead and this lane runs through the repository and the review with the developers, which is exactly why that decision comes before the rebuild rather than after it.

  • Developers

    Branch Components and routes Review Deploy

    The same workflow as any other repository, which is what makes a second developer able to pick it up.

  • Coding agents

    Project instructions Branch Review Deploy

    Coding agents use the same repository and review process as developers. Instructions explain the patterns; tests and a human review check the changes before release.

Integrations

Changing the frontend doesn't mean changing your stack.

All 24 integration guides

Questions

Questions about leaving Webflow.

Will moving off Webflow hurt our search rankings?

I map every URL, set a 301 redirect for anything that moves, and check the new pages against the old ones before the switch. A migration cannot guarantee rankings, but it should not lose the pages and links you already have.

Can we see the new site before we switch?

Yes. The rebuilt site runs on a preview link with your real content, and the domain moves only after you approve it.

Can our editors still change the site without a developer?

Yes, for content. Editors change text, images and SEO fields in Sanity Studio. A new kind of page or section is code, so it takes a developer, yours or me.

Does Astro replace the Webflow Designer?

No. Astro has no visual canvas: layout lives in code, built once from your design, and editors change content in Sanity Studio. If your team designs new pages visually every week, that is a reason to stay on Webflow.

Other guides

Coming from somewhere else?

Or weigh Webflow against a codebase before deciding

Next step

Let me plan your next step.

Send your site

I can scope a migration. Send a brief and I will reply by email with next steps.