Your site keeps working. What is underneath it changes.
A Webflow site becomes an Astro codebase: the pages your visitors see stay recognizably the same, and the system that produces them is rebuilt so your team owns it. I am a Webflow Professional Partner, which is also why I will tell you when to stay.
The distinction
The export is not the migration.
Webflow exports rendered HTML, CSS, JavaScript and assets. That is the output of the system, not the system. Dropping it into Astro gives you the same pages with none of the structure that made them maintainable, and a CMS that no longer exists. The work is reconstructing what produced the output, one decision at a time.
- 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.
- Interactions and custom code Components, or nothing Some of it is a few lines of JavaScript on one page. Some of it was doing work the platform is no longer doing, and has to be rebuilt deliberately.
- Integrations Rebuilt connections Forms, analytics, consent and CRM each have to be re-established and tested. Nothing about them is carried by an export.
Stay or move
Not every Webflow site should leave Webflow.
Webflow is a good product and most marketing sites should stay on it. The move is worth making when the site has started behaving like a software project, and it costs you more than it returns when it has not. Here is the trade, stated as a table rather than a pitch.
| What is being compared | Webflow | Astro |
|---|---|---|
| Structural changes | Webflow Visual editing, inside the site | Astro Code, a review and a deploy Content editing is the separate question, and the answer depends on whether the Astro site reads Markdown, a Git workflow or a headless CMS. Structure is the part Webflow wins outright, and it is the thing you are giving up. Be sure. |
| JavaScript shipped | Webflow Webflow's runtime, plus whatever the site adds | Astro Little by default, with each island added on purpose The reason to pick Astro over the alternatives, and the reason every interaction becomes a deliberate decision rather than a panel setting. |
| Content model | Webflow Structured collections, inside Webflow's CMS | Astro Markdown, content collections, or a CMS the project connects to |
| Ownership | Webflow The platform, the hosting and the publishing, all managed for you | Astro Your team owns the codebase, the dependencies, the build and the deploy |
If more of those rows land on the Webflow side for your team, that is the answer, and it is a perfectly good one. The longer version of this decision goes through it properly.
What survives
What is accounted for, and what that is worth.
Each of these is handled deliberately rather than hoped for. None of it is a guarantee about search performance: a migration can affect rankings, anyone who tells you otherwise is selling something, and what care buys you is that nothing is lost by accident.
- Existing URLs Inventoried before the rebuild, and kept unless there is a reason to change one.
- Redirects Mapped for every URL that does move, including the ones nothing links to any more.
- Titles, descriptions, canonicals Carried across as content rather than regenerated from a template.
- Structured data Rebuilt to match what the pages already declared.
- Internal links Re-pointed, so the rebuilt site links the way the old one did.
- Sitemap and indexability Checked against the old site before cutover rather than after.
- Analytics and consent Re-established and verified firing, which an export does not do.
- Editorial workflow Whoever published before still has to be able to publish after. This is the decision most migrations get wrong.
Your CMS has to become something
The publishing question decides the architecture.
Leaving Webflow means leaving its CMS, and what replaces it depends on who publishes and how often. A team that ships a post a month and a team that runs a content operation need different answers. Content Collections, a headless CMS such as Sanity, or no CMS at all are all correct in different cases, and choosing wrong is the mistake people feel a year later.
Content Collections against a headless CMS, and how the choice is made.
| What you have | What happens | Why |
|---|---|---|
| Pages | Rebuild Made again in Astro. The old version is a reference rather than something that can be imported. | 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 Astro. The old version is a reference rather than something that can be imported. | 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 Astro. The old version is a reference rather than something that can be imported. | 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. |
How the work runs
Audit, model, rebuild, cut over, verify.
Five stages. The content, URL and integration work is not a phase at the end; it happens inside the rebuild and the cutover, which is the only way the site on the other side is the same site.
-
01
Plan
Pages, collections, interactions, forms and everything the platform was quietly doing, written down while the site is still on it, and where the content lives next: Markdown, Astro content collections, or a CMS somebody picked on purpose.
-
02
Build
Pages become components and the interactions become code that somebody now maintains.
-
03
Migrate
Content and assets moved across, and URLs, metadata and structured data carried over unchanged. The map exists to prove that they were.
-
04
Launch
Forms arriving, every route rendering, tracking intact, then the deploy. Typically 2–4 weeks, then a week of watching what the old addresses return.
The parts that are actually hard
Where a Webflow migration goes wrong.
Named up front, because these are what a quote is really pricing, and a migration that has not thought about them is the one that runs long.
- 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.
- 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.
Reach out and see if we are a good fit.
Currently booking two to four weeks out.