Lovable to Cursor: Move the Plan, Not Just the Code

You connected GitHub, cloned the repo and opened it in Cursor. The app runs. Cursor can see every file Lovable ever wrote, and it reads them faster than you ever could.

Then you ask it to add a paid plan, and it asks where pricing should live. You settled that weeks ago, in a conversation you would now have to scroll for. The code came across. The reasons stayed where they were.

Moving the code is the quick part

Lovable is good at getting a first version live, and it makes leaving easy. Whether you land in Cursor or Claude Code, the move looks like this.

1. In Lovable, connect the project to GitHub. That creates a repository and keeps it in two-way sync on one branch, normally the default one. 2. Clone it and open it in Cursor. 3. Install dependencies and run the app locally before you change a line, so you know what working looks like. 4. Recreate your environment. Secret keys for payments, email or anything else usually live in those services' dashboards rather than in the repo, and a missing key looks exactly like a broken app.

Then decide who owns the branch. Anything pushed to the synced branch flows back into Lovable, so if you keep prompting screens there while Cursor takes the backend, give each tool its own files and pull before every session. And do not disconnect on a whim: Lovable cannot reconnect to the same repository. It makes a new one.

What stays behind

Two things do not travel with the repo.

The first is Lovable's Knowledge: the project notes, and any workspace rules, that Lovable considered on every edit. They sit in Lovable's settings as text fields of up to 10,000 characters each, not in your files.

The second is bigger, and it has no settings page. It is everything you decided in the chat. Maybe why checkout uses a hosted payment page instead of a custom form. The login approach you tried in week two and dropped. The feature you parked because an early user said it solved the wrong problem. What you meant to build next.

The code tells your new tool what exists. It cannot tell it what you were in the middle of.

Rules files carry habits, not a plan

The standard advice is to turn Knowledge into Cursor rules, and it is good advice. Cursor reads project rules from a .cursor/rules folder, where each rule can apply to every chat or only to matching files. It also reads a plain AGENTS.md at the root of the repo. Lovable reads AGENTS.md too, so if you keep both tools, that one file gives them the same instructions.

Do it. Then notice what a rules file is for. It holds conventions: use this component library, never edit the payments table by hand. It does not hold a sequence. Nothing in it says you are halfway through moving billing and checkout should wait until that lands. Nothing checks the finished work against it either.

Files describe. They don't decide. A rules file is the right home for how you build, and the wrong home for what comes next and why.

Bring the decisions and the next piece of work

Before you close the Lovable tab, spend half an hour on two things.

Write down the decisions that still hold, each with its reason and the options you rejected. The rejected ones matter most. Without them, a fresh assistant will cheerfully propose the approach you already tried, and you will only half remember why it failed.

Then write the next piece of work as a brief an assistant with no history could run: the goal, what is out of scope, how you will check it is done. That shape is a build handoff, and it is the difference between Cursor building the thing you asked for and Cursor tidying three screens on the way.

PAPI is one way to keep both current without a second document to maintain. It connects to Cursor and Claude Code alike, and one project works across both. Each decision keeps its reasoning and a confidence level, and when you change your mind after the move, the old call is superseded rather than overwritten, so the record shows what changed and why.

When to stay

If your app is still mostly screens, and you are still throwing away more than you keep, stay in Lovable. Cursor asks more of you: a terminal and git, and reading every diff before you accept it. That cost is worth paying once the project has stopped being disposable, and not before.

Be clear about the limits, too. PAPI does not move your code or write a line of it. Your assistant still does the building. What PAPI holds is the plan and the reasons behind it, the part a chat window was always a poor place to keep.

Where to go next

For the general version of this move, any tool to any tool, read switching AI coding tools without starting over. For the wall Lovable projects tend to hit before the move, read Lovable Limitations: What Happens After the Prototype. Once the repo is open in Cursor, install PAPI and run setup against the code as it actually is.