How to move off Webflow

Most guides to leaving Webflow open at the export button. That is the middle of the job, and starting there is the reason a move that looks like a weekend turns into six weeks.

Exporting gives you HTML, CSS and JavaScript. It does not give you the CMS, the forms, the site search, the memberships or the store, because none of those are files. They are things Webflow was running on your behalf, and each one becomes something you now run yourself, replace with a service, or decide to do without. Those decisions are the migration. The export is a download.

Here is the whole move in the order it actually happens, with the detail on each stage linked rather than repeated.

First, decide whether to go

This is the stage with the most leverage and the least work, and it is the one most often skipped. Most marketing sites should stay on Webflow. The move is worth it when the platform has stopped fitting the way the team works, not when somebody read that static sites are faster.

Three things decide it: whether you are hitting the CMS limits, what the platform costs once everything is added, and whether the real problem is the platform at all. When to leave Webflow, and when to fix the site instead is the honest version of that question.

Inventory the site before you export anything

The export takes a minute. The inventory takes a day, and it is the day that decides whether the rest goes well.

Four lists. Every page and every address, which is not the same list. Every collection, with the references between them drawn rather than described. Every integration, including the ones added years ago by somebody who has left. Every interaction, form and piece of custom code, with a note on what each one is for.

Build the address inventory from several sources: the live crawl, CMS records, sitemaps, existing redirects and available analytics, search and request data. A crawl can find linked archives and pagination, but may miss orphaned or historical URLs. No single source is necessarily complete.

Know what the export hands over

The code export includes static files and supported runtime behavior, but CMS-bound content needs separate handling. Audit assets and external references rather than assuming every image is packaged or that a CDN URL will expire on a particular date. The dedicated export guide explains the boundary.

Webflow export to Astro: what moves and what must be rebuilt goes through it line by line, including the custom code that is already code and still has to move.

Decide what the CMS becomes

This is the decision that shapes everything after it, and it is settled by one question: after the move, who publishes, and how often?

There are three useful publishing arrangements to evaluate: repository-managed content, a configured CMS, or content maintained directly in the components. Choose against the people who publish and the work they need to do. A content layer can connect different sources, so these are workflow choices rather than mutually exclusive framework capabilities.

If the answer is a headless CMS, the work is the content model rather than the content. Modeling content in Sanity for a marketing site is the shape to aim for, and Webflow to Sanity migration: content, references and publishing is what happens to the references, which is where CSV exports fall apart.

Rebuild rather than port

Templates become components. Interactions get written rather than configured. The structure that lived in the Designer becomes a routing decision and a content model, and most of it is better for being made explicit.

This is the part that looks like a redesign and is not one. The site should come out the other side looking the same. Webflow to Astro: what the migration actually looks like in code walks one page through it.

Keep every address you already have

Keep useful public addresses where possible. Record whether each known URL is preserved, redirected to a relevant replacement or deliberately retired. Flatten avoidable redirect chains and verify the expected outcomes before launch and on production.

How to protect SEO during a website migration is the sequencing, including the baseline to write down beforehand so that a measurement change and a traffic change can be told apart afterwards.

Verify before the switch, not after

Nothing breaks loudly in a migration. The failures that matter are the ones where every visible part of the system reports success and something behind it has quietly stopped, and they surface weeks later when somebody asks a question the data can no longer answer.

A form that submits is not a form that works. What actually breaks in a website migration is the list of those, and The Webflow to Astro migration checklist is the same list as something to work through.

What it takes, and who does it

Scope decides both the time and the price, and the things that move them are the same: how many distinct templates sit behind the pages, how the content relates to itself, how many integrations have to be rebuilt, and how much URL history has to be carried.

How long a Webflow to Astro migration takes sets the expectation, What decides the cost of moving off Webflow explains the number, and Hiring a Webflow to Astro developer: eight questions to ask is what to ask whoever quotes it, including me.

Turn the inventory into a migration brief

An inventory becomes useful when it produces decisions. A spreadsheet with 200 rows is not a scope until each row explains what happens to that part of the site. Start with a representative route from every template, then connect those templates to the collections, services and people that keep them working.

For an illustrative services site, that could mean a homepage, a service landing page, an article, an author archive and a contact page. The article may depend on three collections, while the contact page may depend on a form service, a CRM and an email notification. Counting both as one page hides the work that makes them different.

Use the following table as a starting artifact. The examples describe a hypothetical project, not a completed migration or a fixed package.

The brief should also say what is excluded. If the move preserves the existing design, a new visual identity is outside that scope. If the migration includes article content but not rewriting it, the source text remains the comparison point. Naming those boundaries makes it easier to accept improvements later without quietly moving the launch date.

Run a representative migration before moving everything

Choose a small sample that exposes the difficult parts. The newest, cleanest article is rarely enough. Include an older post with inline images, an author reference, a multi-category relationship and an embedded element. Add a page with a real form and a page with unusual responsive behavior.

Move that sample through the complete path: extract the source, transform its fields, create the destination record, render its route and compare the result. Check the route and metadata as well as the visible body. This reveals whether the planned schema can express the content and whether the renderer handles the blocks that actually occur.

Keep an exception list while doing it. Each exception should name the source item, the unsupported behavior, the proposed treatment and the person who decides. A table that cannot be converted automatically may need a dedicated content block. An abandoned embed may be deliberately removed. Those are different outcomes and should not disappear into a generic import warning.

A successful sample gives the team something concrete to approve. It also makes the estimate more defensible: the difficult transformation has been demonstrated rather than assumed.

Plan for content that changes during the rebuild

The live website usually continues to operate while the replacement is being built. An export from the first week is therefore a starting snapshot. Decide how later edits, new articles and deleted records will be handled before editors begin working in two systems.

One option is to keep Webflow as the editing source until a short, agreed freeze. Another is a controlled final import that applies only the changes since the previous export. Either approach needs stable identifiers and a rule for conflicts. A later import should not overwrite approved destination edits merely because the script can run again.

Record the final content checkpoint in the launch plan. It should include who confirms that publishing is paused or synchronized, who runs the last import, and who reviews its report. Resume ordinary publishing only after the team knows which system is authoritative.

What a useful handover contains

Ask the receiving team to perform a small edit before calling the handover complete. They should be able to find the content, review its preview and understand how the change reaches production. That exercise is more revealing than a folder of documentation nobody has tried to use.

For the detailed launch gates, use the migration checklist. For how those gates affect scheduling, read the migration timeline.

The order is the point

The sequence reduces avoidable rework. A late URL inventory leaves preservation decisions unresolved, while a late content-model decision can force conversion work to be repeated. Make the dependencies visible and agree the evidence required at each stage.

None of this requires trusting me, and none of it is exotic. It is the order the work goes in, and a quote that does not mention the first two stages is a quote for the rebuild only.

Documentation for this revision

• Webflow code-export documentation