Lovable to Webflow
Migrate from Lovable to Webflow
Lovable can get a working site or application surprisingly far, surprisingly quickly. Moving the marketing surface to Webflow does not mean throwing that work away. I separate the public website from the application, keep the code and services that still have a job, and rebuild the part marketing needs to own.
A migration like this usually takes 2–4 weeks
What the migration covers
What moves, and what we figure out first.
What moves
- The marketing pages, rebuilt as Webflow templates and components
- Copy, posts and case studies into pages and collections
- Images and assets, rehosted and compressed
- URLs, metadata, redirects and analytics
- The link between the site and whatever stays in the repository
What we figure out first
- Whether anything in the project is actually an application. It decides which of the two branches you are on, and therefore the scope, the price and whether anyone is maintaining a codebase this time next year.
- Who owns the repository afterwards. If it survives the move it needs somebody whose job includes it. A repository only one person understands is a single-person dependency however it was written, and generated code does not change that either way.
- Which routes the application keeps. Sign-in, the dashboard and anything behind them. The usual end state is the marketing site on the primary domain and the application on something like app.example.com, but the list has to exist before the redirect map either way, because a path claimed by both is a bug that only appears for logged-in users.
- Whether the design gets rebuilt or reconsidered. A generated design is a starting point somebody accepted quickly. Some of it is good and worth keeping exactly. Some of it was never chosen, and the rebuild is the cheapest chance to choose.
Lovable gives you the code, so this is not an escape from a platform that has locked anything up. The question is whether the repository still has a job. If it holds a real application, Webflow takes the marketing surface and the application stays where it is. If it only ever held marketing pages, retiring it is the cleaner outcome.
The part that usually should move is the marketing site. Not because the generated pages are bad, but because a marketing site has a different set of requirements than an application: people who are not developers need to change it, often, without reading a diff or waiting for a deploy. That is what Webflow is for, and it is the one thing a React codebase makes structurally awkward no matter how good the code is.
The part that usually should stay is anything with a user in it. If there is sign-in, a dashboard, data, or logic that runs for someone who is logged in, that keeps its repository and its services: the database, the auth and whatever else the product depends on stay with the product, and Webflow sits in front of them rather than trying to absorb them. If the repository is retiring instead, those services get the same question everything else gets, which is whether anything still needs them.
What is left is the interesting middle: the custom components. Some of them are a section that was prompted into existence and can be rebuilt in Webflow in an afternoon. Some of them are genuinely an interface, with state and behavior that would be silly to recreate. I read them before quoting rather than assuming, because that reading is the difference between a two-week project and a four-week one.
Why people move
What changes when you move from Lovable to Webflow.
| What is being compared | Lovable | Webflow |
|---|---|---|
| What the tool leaves you with | Lovable A React codebase, in a repository you own | Webflow A site in the Designer, and no repository to maintain Lovable genuinely wins this and it is the reason this migration is a decision rather than an escape. You own the output. The question is whether you want to keep owning it for the marketing pages specifically. |
| Changing a headline | Lovable A change to the application project, and another deploy of it | Webflow Editing the text and publishing the marketing site on its own |
| Repeating a section | Lovable Whatever the generation produced, which may be five copies | Webflow One component, and a symbol override where it differs |
| The services behind it | Lovable Supabase, auth and anything else wired in by the project | Webflow Untouched, and reached from the site rather than contained by it |
| Content model | Lovable The application's backend, and the data model built for it | Webflow Collections designed for publishing, and for the people who do it |
| Who maintains it | Lovable Whoever owns the application code, on the terms code is owned | Webflow Webflow for the platform, your team for the content |
What happens to the repository
Keep the application, or retire it.
Now
The project today
- One Lovable repository
- Marketing pages and the app
- One deploy
Then one of these two
Once you have decided
What actually migrates.
| What you have | What happens | Why |
|---|---|---|
| Marketing pages | Rebuild Made again in Webflow. The old version is a reference rather than something that can be imported. | Rebuilt as templates and components. The generated markup is worth reading for the design decisions in it and is not worth porting, because the thing being bought here is a system that marketing can operate. |
| Copy, posts and case studies | Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. | This is real content and it moves as content, into pages and collections, rather than staying as text inside a component file. |
| The application and its services | Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. | If there is a signed-in product behind the marketing pages, it keeps its repository, its deploys and whatever it is wired into, Supabase included, and Webflow sits in front of it. If the project was only ever a marketing site, the repository retires at cutover and that is the cleaner outcome. |
| Custom React components | Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. | Worth reading before assuming. Some are a layout somebody prompted into existence and are an afternoon to rebuild. Some are a real interface with state in them, and those are an argument for keeping a route on the application rather than recreating it in a marketing site. |
| URLs and redirects | Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. | Mapped from the routes the site currently serves, with anything the application keeps answering excluded rather than redirected. |
Before you budget it
Where this migration gets complicated.
- 01
Repeated sections were often copied rather than made reusable
Generated code answers the prompt in front of it, so the same hero can exist five times with five sets of values. That is fine to look at and misleading to estimate from: what looks like one component to rebuild is sometimes five pages that have quietly drifted apart.
- 02
The intent is not always written down anywhere
The code reads fine and is as inspectable as any other code. What is missing is why: whether a component is a reusable layout, real application behavior, or scaffolding from an earlier prompt that nothing calls any more. Reading the implementation is often the only way to tell, and that is an hour nobody budgeted rather than a difficult afternoon.
The part quotes leave out
How I move it without losing the search footprint.
-
The search footprint is inventoried before anything moves
A crawl shows what the current Lovable site links to now. Analytics and Search Console show which addresses people and search engines are still reaching, including ones nothing on the site points at any more, so the list is the union of all three. The traffic, the top pages and the queries earning impressions get written down at the same time: without a baseline, a change in how you count and a change in what you get are the same graph.
-
What can stay where it is, stays
Addresses first, then the titles and descriptions attached to them, then the canonicals. Metadata is the easiest thing to lose in a rebuild, because the new site will happily generate something plausible for every page and nothing will report a problem.
-
Everything that changes gets one rule, not a chain
A redirect pointing at a redirect still arrives, so nothing looks broken. Each address gets an intentional destination rather than an inherited one: individual rules where the destinations differ, a pattern where a whole route family changes predictably. The new sitemap goes in at cutover carrying the canonical addresses and nothing else.
-
Every old address is requested after launch and the response recorded
The whole list, not a sample. Looking for anything returning 404 that should not, anything returning 200 that should have moved, and anything taking more than one hop. Then indexing and traffic by landing page for the week after cutover, which is the window included, and longer by arrangement where the site is large enough to warrant it.
None of this guarantees a ranking, and search results can move during a migration for reasons nobody controls. The goal is to change platforms without unnecessarily changing what search engines already understand about the site, and to notice quickly when something did change. Afterwards I watch indexing, what the old addresses return and traffic by landing page, so normal recrawling can be told apart from an implementation problem.
How it runs
Six stages, and what each one looks like.
- Repeated content A collection, with its fields decided
- One-off pages A page, built from components
- Categories and tags A reference field, or a collection of its own
- Anything with no equivalent Named now, not discovered later
Four outcomes, not two. "It moves or it does not" is the framing that gets a quote wrong.
A mapping, not a pipeline
A Lovable project is usually a dozen marketing pages and a handful of posts, so the import is modeling the collections and filling them, then checking each field against the repository it came from.
-
/features-overview/features -
/pricing-plans/pricing -
/about-our-team/about -
/blog/launching-v2/blog/launching-v2 -
/dashboard/dashboard
Every changed address gets an intentional destination: a direct rule where the mapping is particular, a pattern where a whole route shape moves predictably. These paths are an example of the shape.
- Every form checked at the record, not at the button
- Every template at 1280, 1000 and 390
- Structured data still present on the pages that had it
- Every old URL requested, and what came back recorded
- The analytics baseline written down before cutover
The step most often cut when a quote is being squeezed, and the one that decides whether the failures are found before launch or by somebody using the site afterwards.
Coming from somewhere else?
-
HTML to Webflow
Typically 2–3 weeks
Learn more → -
WordPress to Webflow
Typically 3–4 weeks
Learn more → -
Squarespace to Webflow
Typically 2–3 weeks
Learn more → -
Wix to Webflow
Typically 2–3 weeks
Learn more → -
Next.js to Webflow
Typically 3–4 weeks
Learn more → -
HubSpot CMS to Webflow
Typically 3–4 weeks
Learn more →
Reach out and see if we are a good fit.
Currently booking two to four weeks out.