Import
Moving a Lovable project to Q-Code
A guided import wizard moves a Lovable project into a Q-Code project you own, and your domain moves last of all.
It runs in five visible steps: source, pre-flight, import, gates and result. The project comes across onto a hosting account, a repository and a database held in your name, and it keeps its own design. The steps that are hard to undo wait for an explicit check from you, so nothing dangerous is automated away.
- 01SourceDone
- 02Pre-flightDone
- 03ImportDone
- 04GatesWaiting
- 05ResultLocked
Gates before the domain moves
- A member signs inVerified
- A payment event arrivesVerified
- Secrets rotatedWaiting
The domain stays where it is until all three read Verified.
5 steps
Source, pre-flight, import, gates, result.
Each step is visible, and each one is passed before the next opens. You can stop after any of them with your live site still answering on its own domain.
01
Source
Say which Lovable project is coming across and where it lives. Nothing has moved at this point, so getting it wrong costs a correction rather than a recovery.
02
Pre-flight
What could go wrong is checked before anything moves, and reported in plain words. A problem surfaces while the project is still untouched.
03
Import
The project comes over onto infrastructure held in your name: your Cloudflare account, your repository, your database. It keeps its own design and palette.
04
Gates
The three verification gates below have to clear. Until they do, the imported site is live on a preview URL and your domain is still answering where it always did.
05
Result
What came across, what it looks like now, and what is left for you to decide. From here it behaves like any other project on the platform.
The gates
Three things that have to be true first.
A migration that reports success and quietly leaves the sign-in broken is worse than one that stops. So the gates check the things that would actually be noticed, with real events rather than green ticks.
01
A member signs in
A real person has to sign in successfully on the imported site, not a test account on a staging copy.
02
A payment event arrives
A real payment event has to arrive from the payment provider, so the money path is proven and not assumed.
03
Secrets are rotated
The API keys and tokens are rotated, so the old project cannot act on the new one after the move.
Nothing dangerous is automated away. The wizard does the tedious part and holds the consequential part, which is the opposite way round from a one-click migration that finishes before you have read what it did.
The admin
An imported site gets the owner console too.
An imported React site is not a second-class project. It gets the same admin area a site built here from scratch gets, rendered in its own palette rather than the platform’s.
- Overview
- What the site is, what state it is in, and what happened to it last.
- Analytics
- Who came, from where, and which pages they read.
- Voice
- The brand voice every generated word on the site passes through.
- Access
- Who can sign in, and who cannot.
The console is noindex and reached by an emailed sign-in link, so there is no password to lose and nothing for a crawler to find. It reads as part of the site it belongs to, because it is drawn with that site’s own colours.
Once it is here
It behaves like anything else built on the platform.
Importing is a door, not a category. After it, the project uses the same loop and the same engines as a project that started here.
The build loop
Describe a change in plain English, watch it build, and check it on a live preview before anything reaches your domain.
The visibility audit
Machine visibility, conversion, security and agent readiness, scored on the built site and handed back as fixes.
The module library
Catalogue, booking, members, blog and the rest, installed as a switch rather than written from nothing.
Domains and email
The domain on a DNS zone you hold, with a certificate issued and sending from your own address.
Hardening comes with it. An imported site ships with the same secure headers, HSTS, content-security-policy, row-level data security and scanning as anything else built here, and can publish its own public trust page.
Q&A
Questions about importing a project
When does my domain move across?
The custom domain moves last. It only moves once three verification gates clear: a real member signs in on the imported site, a real payment event arrives from the provider, and the secrets are rotated. The domain is last because it is the thing a visitor notices going wrong.
What if something is wrong with the project?
The pre-flight step checks what could go wrong before anything moves, and reports it in plain words, so a problem surfaces while the project is untouched. Nothing dangerous is automated away, and the steps that are hard to undo wait for an explicit check from you.
Do I have to rotate my API keys?
Yes. Rotating the keys and tokens is one of the three gates, not an optional tidy-up afterwards. It is what stops the project you are leaving from being able to act on the one you are moving to, and the domain waits behind it.
Does the imported site keep its own design?
Yes. An imported React site keeps its own design and palette, and the owner admin console is rendered in that palette rather than the platform’s. It is the same console a site built here from scratch gets: overview, analytics, voice and access.
What does the imported project get that it did not have?
The same things every project here has: the chat build loop with a live preview before anything publishes, the visibility audit across machine visibility, conversion, security and agent readiness, the module library, custom domains with branded email, and hardening by default.
Bring it across, gate by gate.
The wizard does the tedious work and stops at the parts worth checking. Your live site keeps answering until the gates clear.