How to transfer a Lovable project to another account

Start with the ownership map

Write down the services that make the project work before you change access. A basic static site may only need the Lovable project and domain. A production app may also use GitHub, Vercel or another host, Supabase, Stripe, an email provider, analytics, a custom domain, and API keys. Each can have a different owner and billing account. The aim is not to make the checklist complicated. It is to avoid discovering after a handover that the new owner cannot deploy, receive form submissions, manage the database, or update DNS.

• Lovable workspace or project access
• GitHub repository and organisation
• Hosting account and deployment settings
• Database, storage, and authentication provider
• Domain registrar and DNS
• Analytics, email, payments, and API providers

Choose the right transfer route

Use the access and sharing controls actually available in the current workspace first. For a team project, adding the new owner or collaborator may be enough. When code ownership matters, a GitHub handover is often the most reliable backup and continuity path: the repository can be transferred, moved to an organisation, or shared with the responsible developer. Do not remove the existing owner until the new owner has proved they can reach the project and its connected services. The project may need both a Lovable access change and a GitHub ownership change.

Back up the project before changing anything

Create a recovery point before the transfer. Confirm that the latest Lovable changes are synced to the repository or exported in the available project workflow. Record the production URL, active branch, deployment settings, environment variable names, connected domain records, and key integrations. Avoid putting secret values in a document or repository. Instead, make a secure inventory of where each secret lives and who must rotate or re-enter it. A backup is useful because transfers can create permission changes, accidental disconnects, or configuration drift.

• Confirm the latest code is available in GitHub or an approved export
• Record the production branch and latest working deployment
• List environment-variable names without exposing secret values
• Record domain DNS and hosting configuration
• Document connected services and billing owners
• Keep a known working URL and test account

Move connected services carefully

GitHub, hosting, domains, databases, and payments should be handled deliberately. Give the new owner the minimum access needed first, then test. For GitHub, make sure the recipient can see the repository, branches, and settings. For hosting, confirm they can access project settings, deployments, logs, and environment variables. For a database, check who can manage schema, authentication, storage, and production backups. Domains are especially easy to overlook: the new owner may need registrar access as well as DNS control. Payment and email accounts may require their own ownership or legal-account process.

Secrets, analytics, and billing

A transfer is a sensible moment to rotate sensitive credentials, especially when a contractor, agency, or former employee previously had access. Review API keys, database keys, webhook secrets, payment keys, email provider credentials, analytics access, and third-party OAuth settings. Do not rotate everything blindly in the middle of a launch; make a plan, update the relevant environment settings, then test the affected workflow. Confirm who receives billing notices and who can approve future charges. Operational ownership is part of project ownership.

Test after the handover

The transfer is complete only when the new owner can operate the product independently. Have them open the project, inspect the repository, make a small safe change, create a preview deployment, and confirm the production deployment path. Test the key public journey: pages load, forms submit, authentication works, data saves, emails arrive, payments work where applicable, analytics receives an event, and the domain resolves correctly. Keep the old access active only as long as needed for support, then remove it according to your agreement.