NewBase
Get in touch

Lovable to Astro

Migrate from Lovable to Astro

A Lovable project is already code, which makes this the least like a migration of anything on this hub. The question is not how to get the site out. It is which part of what you built is still an application and which part has become a website. Keep the application. Extract the website.

Start a project

A migration like this usually takes 1–3 weeks

What actually migrates.

What you have What happens Why
The repository Stays put Does not move, on purpose. The old platform keeps this because it is the thing it is good at, and the new front end reads from it. Nothing has to be scraped from a published site. The existing project gives us the components, the logic, the assets and the integrations to work from, and what survives depends on whether each part belongs in the new architecture.
Components Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Existing React components are useful source material. The interactive ones can stay React inside Astro; the presentational ones are usually simpler to rebuild as Astro components that ship no runtime to the browser.
Routing Rebuild Made again in Astro. The old version is a reference rather than something that can be imported. Client-side routes become Astro pages whose primary content is rendered into the HTML. On a marketing site this is often the architectural change that matters most.
Database and auth Depends Not answerable in general. Which one it is turns on your plan, your export or a decision nobody has made yet. Application state, accounts and real user data stay application infrastructure. Copy, testimonials and FAQs should not need a database because the generated project happened to put them there. If it is genuinely an application, keep it where it is and put the marketing site in front.
URLs Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Every known public address is preserved where practical or deliberately redirected.

Where the line falls.

Which routes go where

Astro

Routes that are read

  • The home page, pricing and features
  • Resources, docs and the blog
  • Anything a search result points at
  • Rendered before anybody asks for it

The seam

Where one hands to the other

  • A link, for most of them
  • The signed-in handoff, at the product's door
  • Application data read where a public page needs it

Lovable

Routes that are used

  • Sign-in and accounts
  • The dashboard and everything behind it
  • State, records and real user data
  • Still an application, because it is one
One domain. The routes people are sent to become documents; the routes people sign in to stay exactly where they are.

Where this migration gets complicated.

  1. 01

    Generated code has no opinion about structure

    The output works and it was not designed. Components repeat, state is held in odd places, and the same value is fetched three ways, because each prompt solved its own problem. Reading it to find what is load bearing takes longer than rewriting the parts that are not.

  2. 02

    A single-page application can be unnecessary infrastructure for a marketing site

    If most routes exist to be read rather than used, making every visitor boot the application runtime first adds complexity the page may not need. The migration separates the document-like pages from the genuinely interactive product behavior and gives each the architecture it actually needs.

How the migration works.

  1. Audit

    Read what the generator produced and decide which of it is a website and which is an application.

  2. Rebuild

    Components kept where they earn their runtime, rewritten where they do not, and routes become real pages.

  3. Migrate

    Publishing content into the content model, application state left where it belongs, every route rendered and checked.

  4. Hand over

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

What is included.

The exact scope depends on where the website ends and the application begins. For the marketing surface, a migration includes the rebuild, the content move, the integration work, URL coverage, QA and post-launch monitoring.

  • 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

    One week of indexing and traffic checks included.

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.

Content should not live in application code because it started there.

A generated marketing page usually holds its headline, its testimonials and its pricing copy as strings inside a component, which is fine until somebody outside engineering needs to change one. The question is where those strings belong: in content collections beside the code, in a headless CMS such as Sanity with an editor and a preview, or genuinely in the component because the page changes twice a year. Choosing wrong is the mistake people feel a year later, so it is decided before the rebuild rather than after it.

  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

    A headless CMS, such as 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.

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

These are acceptance criteria rather than features. The codebase, the site inventory and the connected systems are each checked against what you started with, and the answer is a count rather than an opinion.

  • 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 are an illustration of the report's shape. Yours are counted from your own site.

See everything included in a migration

From prompting the site to maintaining the codebase.

Lovable proved the product by letting an agent build it quickly, and a migration should not throw that advantage away. What changes is that future agent work happens against a codebase with explicit routes, a content model, project instructions and a review boundary, rather than reshaping the architecture one prompt at a time.

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

    Against the real repository, under the same review a person gets. An agent is only as safe as the documentation and the tests it is working against, which is why those are deliverables rather than extras.

Integrations

Changing the frontend doesn't mean changing your stack.

The site is one part of a marketing stack, and a migration that leaves the rest of it broken has not finished. Each of these is a deliberate integration with a guide behind it, rather than a script pasted into a header somewhere.

All 24 integration guides

Coming from somewhere else?

Or weigh Lovable against Astro before deciding

Reach out and see if we are a good fit.

Get in touch

Currently booking two to four weeks out.