The move can give your business more control over development and infrastructure. But those benefits depend on replacing the services your existing website relies on—not simply uploading exported files to a different host.
This guide explains how to migrate from Webflow to code, from auditing your current website to rebuilding the CMS and checking the live deployment. It includes an example workflow for moving from Webflow to Astro and Sanity, plus considerations for Next.js and other custom stacks.
Before choosing a framework, write down the problem you want to solve.
Perhaps your team needs a code review process. Perhaps your content needs more flexible relationships. Or perhaps custom integrations have become difficult to manage across embedded scripts and external services.
Turn that problem into a concrete requirement. “Improve performance” could become “reduce the scripts loaded on article pages while keeping the existing interactions.” “Make editing easier” could mean “let editors preview and publish an article without developer support.”
If the only issue is an oversized hero video or a confusing page layout, fixing the current Webflow site may be a better investment. A migration makes sense when the benefits justify both the rebuild and the ongoing responsibility.
Start with an inventory that captures what the website does today.
Count unique page templates as well as URLs. Two hundred articles using one template present a different development workload from twenty individually designed landing pages. Content volume still matters for importing and testing, but page count alone does not describe the project.
Save screenshots of representative desktop and mobile pages. Record interactions that a screenshot cannot capture, such as a mobile menu opening or an animated section responding to scroll.
Also decide who will own the repository, hosting account, CMS, and maintenance after launch. Include those responsibilities in the scope before development begins.
Webflow code export provides HTML, CSS, JavaScript, and assets. Access depends on an eligible paid Workspace plan; a Site plan alone does not include code export.
The export does not provide a complete replacement for Webflow’s managed services. CMS content and functionality, ecommerce, search, form processing, and password protection require separate work. Localized content and code components also have export limitations. Check Webflow’s export documentation against your site’s features.
Keep an untouched copy of the export as a reference. Then choose whether to retain some exported markup or rebuild it into reusable components.
Separately, export your CMS Collections. Webflow supports CSV exports, with rich text represented as HTML and images and files represented by hosted URLs. Those URLs are not copies of the underlying assets. Download and migrate the media you need, including images embedded inside article bodies. See Webflow’s CMS export guidance.
For a multilingual website, verify that every required locale is included in your content migration plan.
The frontend determines how pages are built and delivered. The CMS determines how your team creates and maintains content. Evaluate them together using a real publishing task.
For example, ask an editor to create an article, add an image caption, choose an author, preview the result, and schedule or publish it using the proposed setup. This reveals requirements that a framework comparison can miss.
Astro is an option to evaluate for marketing websites, blogs, and other content-focused projects. Its islands architecture renders components to HTML and CSS by default, with client-side JavaScript added where interactive components need it. See the Astro documentation.
An Astro and Sanity setup can separate the page implementation from content editing. Your development work still needs to connect content queries, previews, media rendering, and publishing to the website.
Next.js is another option, particularly when your team uses React or the website needs substantial application functionality. Its server and client component model lets developers place different responsibilities on the server or in the browser.
Choosing Next.js does not automatically solve authentication, payments, content editing, or performance. Those remain implementation decisions.
Compare Sanity, Payload, Storyblok, or another CMS against the workflows you documented. Consider editor access, localization, preview support, content relationships, asset handling, and recurring costs.
Build one complete page with real content before committing the entire migration to the proposed stack.
Start with a page that includes the site's shared header, footer, typography, images, and a meaningful interaction.
Use it to establish reusable components and design tokens. Test long headings, missing optional images, narrow screens, keyboard navigation, and reduced-motion behavior early.
For a blog, the first complete article should include more than paragraphs. Add a list, a link, a captioned image, and any custom content blocks your editors use. This tests the connection between design, content structure, and rendering.
Exported JavaScript can support Webflow interactions and interface components. Do not remove it until you understand those dependencies. If you replace an interaction, verify the replacement before deleting the old implementation.
Once the representative page works, extend the component system across the remaining templates. This gives the migration a tested foundation rather than a collection of disconnected pages.
A successful Webflow CMS migration preserves relationships and publishing intent as well as text.
Create a field map before importing. For a blog moving to Sanity, an illustrative mapping could be:
| Feature | Destination field | Validation |
|---|---|---|
| Article name | Title | Complete and readable |
| Slug | Slug | Existing URL preserved where practical |
| Rich text | Portable Text body | Formatting, links, and media retained |
| Author | Author reference | Connected to the correct document |
| Featured image | Image asset | File imported and alt text preserved |
| SEO title and description | SEO fields | Existing values retained |
| Publication date | Date field | Original date and timezone handled correctly |
Sanity supports bulk imports, but the imported documents must match the intended data structure. Its documentation also notes that Studio validation rules are not automatically enforced on API mutations. Validate imported data explicitly rather than assuming a successful import means every document is complete. See Sanity’s import documentation.
For rich text, test HTML conversion against the content blocks your site actually uses. Sanity documents tools for converting markup to Portable Text.
Import a small sample first. Review it in both the CMS and the rendered website, then migrate the remaining content. Keep drafts and archived items from accidentally becoming public.
A website can look finished while its most important workflows are broken.
Test every form from submission to delivery. Confirm that messages reach the right inbox or CRM, required fields are validated, spam handling works, and visitors receive accurate success or error feedback.
For a calculator, compare outputs against known examples. For search, test common queries and empty results. For gated content, verify access with signed-out users and accounts with different permissions.
Treat ecommerce and membership systems as separate workstreams. Document which system owns products, customer records, subscriptions, and access rules before implementing replacements. A frontend rebuild alone does not migrate those business processes.
Include analytics in these checks. A working contact form with a missing conversion event can make a successful launch look like a sudden drop in leads.
Preserve existing URLs where practical. When an address changes, map it to the most relevant replacement and implement a permanent server-side redirect. Avoid sending unrelated removed pages to the homepage.
Check page titles, descriptions, canonical URLs, internal links, structured data, and the sitemap. Ensure production pages do not inherit staging restrictions such as a noindex directive.
Google recommends separating major changes where possible, preparing URL mappings, and monitoring traffic after a move. Rankings can fluctuate while Google processes changes; no migration can promise unchanged positions. Follow Google’s site migration guidance.
Create a launch checklist covering these essentials:
Agree on a short publishing freeze or a final content synchronization process. Otherwise, an article edited during development may be missing or outdated on the new site.
Before switching traffic, test the production build and confirm the steps required to restore the previous deployment if necessary. Keep your exports and migration records available.
Document the DNS changes separately from the application work. Website hosting and email services may share DNS administration, so preserve unrelated records when making the switch.
After launch, check your key journeys immediately: open a landing page, navigate to an article, submit a form, and confirm the submission arrives. Review error reports and search visibility over the following weeks.
Complete the handover with instructions for publishing, previews, deployment, backups, and routine maintenance.
A useful estimate should explain the work behind the price. Ask for separate scope covering templates, CMS conversion, interactions, integrations, SEO, testing, and handover.
A small brochure site and a multilingual publication need different budgets. Existing code quality, content consistency, access requirements, and review cycles can also change the workload.
Compare ongoing costs too: hosting, CMS usage, editor seats, external services, and maintenance. For example, Vercel’s free Hobby plan is intended for personal, noncommercial use, so it should not be assumed to cover a business deployment. Check Vercel’s plan terms.
Request a timeline tied to deliverables and approvals. A credible schedule should reserve time for content review and launch testing, not just development.
AI coding tools such as Claude Code, Cursor, and Codex can assist with tasks including component extraction, content transformation scripts, and debugging. Give them a documented component structure, a clear field map, and small tasks whose results can be checked.
Review generated changes before they reach production. Visual similarity does not establish that references, redirects, permissions, and form delivery are correct.
AI access alone is also not a reason to leave Webflow: Webflow supports AI-assisted workflows through its MCP tools. See Webflow’s MCP example.
Start with your current website, the problems you want to solve, and the publishing experience your team needs. Those details make it possible to choose a sensible stack and define a migration you can actually verify.
If you are considering moving from Webflow to custom code, contact Priz with your website URL and requirements. We can discuss what needs to move, what should stay familiar, and how to approach the next stage of your website.
Often not. If the site is under roughly 20 static pages, one or two people edit it, and nobody has asked for something Webflow refused, the migration costs more than the platform does and hands you a codebase to maintain. The cases that justify moving are per-seat cost as headcount grows, needing version control and a real review loop, and features that require a server you control.
$5,000 to $25,000 for a 50 to 100 page site, typically 4 to 8 weeks. Cost is driven by page count, CMS Collection complexity, custom interactions and locale count rather than by which framework you land on. The cost breakdown and timeline pages go through the drivers line by line.
No. Export gives you HTML, three CSS files, the JS folder, Assets panel images and empty Collection template pages. CMS content is excluded outright, along with User Accounts, Ecommerce, password protection, form submission processing, reCAPTCHA, site search, non-primary locales and code components. Export is also gated on your Workspace plan, not your Site plan.
IX2 interactions do export and continue to function through the JS folder, so they are not lost at the export step. Lottie animations need a web server to run. In practice most teams rebuild interactions in the new stack anyway, because carrying Webflow generated JavaScript forward defeats much of the point of moving.
