You’ve built a Lovable app. It’s growing. You’re ready to move from your personal GitHub account to a GitHub Organization (maybe for the Pro plan, or just to collaborate with a team).
Naturally, you open your GitHub repository settings, scroll down to the "Danger Zone," and reach for the Transfer Ownership button.
STOP. 🛑
If you transfer that repository while it is connected to Lovable, you will break your sync, likely permanently. Lovable does not support "Bringing Your Own Repository" (BYOR) for existing projects. If you transfer the repo first, Lovable will refuse to reconnect to it and will insist on creating a duplicate.
Here is why the standard migration fails and the correct strategy to move your Lovable project to a GitHub Organization without losing your mind.
The Problem: Lovable is the "Source of Truth"
Most developer tools (like Vercel or Netlify) treat GitHub as the source of truth. You point them to a repo, and they deploy it.
Lovable works the other way around.
Lovable treats its own internal editor as the source of truth. When you "sync" to GitHub, Lovable pushes code out.
Because of this architecture:
- You cannot simply link a Lovable project to an existing, transferred repository.
- You must let Lovable create the repository itself during the connection process.
If you transfer your repo my-app to my-org/my-app manually, Lovable sees that remote repo as a stranger. When you try to reconnect, Lovable will say, "I need to create a repo," and you'll end up with my-org/my-app-1.
The Strategy: The "Fresh Start" Migration
To migrate successfully, we have to accept a trade-off: We will sacrifice the Git commit history to ensure the sync works perfectly.
We will not move the repo. Instead, we will archive the old one and let Lovable generate a fresh one in the new Organization.
Phase 1: The Safety Net (Backups)
Before touching anything, secure your data.
- Code Backup: Run a
git pulllocally and zip the folder. Keep this safe. - Database Backup: Go to your Supabase Dashboard -> Project Settings -> Database -> Backups. Create a fresh backup.
- Good news: Your Supabase database is loosely coupled. It connects via Project ID, not the GitHub repo. Moving your code will not delete your data.
- Rename the Old Repo: Go to your personal GitHub repo and rename it to
my-app-legacy. This frees up your preferred name (my-app) for the new organization.
Phase 2: Sever the Connections
You need to disconnect the services to prevent errors during the switch.
- Pause Deployments: If you use Coolify, Vercel, or Netlify, pause "Auto Deploy" to stop them from trying to pull from the old URL.
- Disconnect Lovable:
- Go to Lovable Project Settings -> Integrations -> GitHub.
- Click Disconnect.
- Note: Your code remains safe inside Lovable.
Phase 3: The "New" Transfer
This is where the magic happens. We don't "transfer" in GitHub. We "reconnect" in Lovable.
- In Lovable, go to Settings -> Integrations -> GitHub.
- Click Connect Project.
- Crucial Step: Select your Organization as the target.
- Tip: If you don't see your Org, you may need to click "Add Organization" to install the Lovable GitHub App on it.
- Lovable will ask to create a repository. Name it
my-app(since we renamed the old one, this name is available). - Confirm.
Lovable will now push the entire current state of your app to github.com/my-org/my-app as a fresh "Initial Commit". The sync is now live and healthy.
Phase 4: Re-wiring the Infrastructure
Now that the code has a new home, point your other tools to it.
1. Hosting (Coolify/Vercel/Netlify):
- Update the Git Source URL to the new organization repo.
- Important: Ensure the hosting provider's GitHub App is installed on your new Organization, not just your personal account.
- Trigger a manual deployment to verify the pipe is flowing.
2. Supabase (Branching):
- Your database connection (URL/Anon Key) stays the same—no changes needed there!
- However, if you use Supabase Branching, you must go to Supabase -> Integrations -> GitHub and reinstall the integration on your new Organization repo.
Summary
Migrating a Lovable app isn't just about moving files; it's about respecting the sync engine.
- DON'T use the GitHub "Transfer Ownership" button.
- DO disconnect and let Lovable create a fresh repo in the Org.
- ACCEPT that your Git commit history will reset (but keep the old repo as a read-only archive).
By following this "Lovable-First" approach, you avoid the "Ghost Repository" trap and keep your project shipping smoothly.
Have you migrated a Lovable project recently? Let me know in the comments if you hit any other snags!
Top comments (0)