Lovable es una herramienta excelente para prototipar rápido: en minutos tienes una app funcionando con un backend Supabase gestionado por ellos. El problema aparece cuando el proyecto crece y necesitas control total sobre la base de datos, las políticas de seguridad o simplemente quieres dejar de depender de su capa gestionada. Migrar a tu propio proyecto Supabase es más sencillo de lo que parece si sigues un orden claro. Aquí va el proceso que uso con clientes.
Por qué migrar
- Control total del schema, funciones y triggers, sin las limitaciones del editor de Lovable.
- Facturación directa con Supabase, sin el margen que añade Lovable sobre el backend gestionado.
- Independencia para escalar el frontend fuera del entorno de Lovable (Next.js, otro framework, apps nativas).
Antes de empezar: checklist
- Exporta el código del proyecto a GitHub desde Lovable (Settings → GitHub).
- Documenta el schema actual: tablas, relaciones, RLS policies y funciones Edge si las hay.
- Haz un backup completo de la base de datos (dump SQL) antes de tocar nada.
Paso 1 — Crear tu propio proyecto en Supabase
Crea un proyecto nuevo en supabase.com, anota la URL y la anon key, y elige la misma región que usaba el proyecto de Lovable para minimizar latencia si vas a migrar datos en caliente.
Paso 2 — Migrar el schema y los datos
El proyecto de Lovable ya corre sobre una instancia de Supabase, así que puedes usar pg_dump contra la base de datos gestionada (Lovable te da las credenciales de conexión en la configuración del proyecto) y restaurar ese dump en tu proyecto nuevo con psql o el propio SQL editor de Supabase. Revisa que se migren también los tipos custom, las extensiones (pgvector, uuid-ossp, etc.) y los triggers.
Paso 3 — Reconfigurar autenticación
Vuelve a configurar los providers de Auth (email, Google, magic link) en tu nuevo proyecto y actualiza las redirect URLs. Ten en cuenta que los usuarios existentes no se migran automáticamente vía dump estándar sin cuidado extra: exporta la tabla auth.users junto con identities para conservar las cuentas.
Paso 4 — Migrar Storage
Recrea los buckets con los mismos nombres y políticas, y copia los objetos con el CLI de Supabase o un script que itere sobre el bucket origen y suba cada archivo al destino. Actualiza cualquier URL firmada o pública que esté hardcodeada en el código.
Paso 5 — Actualizar variables de entorno
En el repo exportado, reemplaza NEXT_PUBLIC_SUPABASE_URL y NEXT_PUBLIC_SUPABASE_ANON_KEY (o los nombres equivalentes) por los de tu nuevo proyecto, y revisa que no queden referencias al proyecto gestionado por Lovable en configuraciones de build o CI.
Paso 6 — Revisar Row Level Security antes de ir a producción
Este es el paso que más se salta y el que más problemas causa. Lovable suele generar policies bastante permisivas para que todo funcione rápido en desarrollo. Antes de lanzar, audita cada tabla: qué puede leer y escribir un usuario anónimo, qué puede hacer un usuario autenticado, y si hay tablas que deberían tener RLS activado y no lo tienen.
Paso 7 — Probar en staging y desplegar
Despliega el frontend apuntando al nuevo proyecto en un entorno de staging, corre los flujos críticos (login, CRUD principal, subida de archivos, cualquier Edge Function) y solo entonces haz el corte de DNS o dominio a producción.
Errores comunes
- No migrar las Edge Functions (hay que redesplegarlas con el CLI, no se copian con el dump).
- Dejar RLS desactivado en tablas nuevas por defecto.
- Olvidar migrar los webhooks y triggers de base de datos que dependían del proyecto anterior.
Si prefieres que alguien lo haga por ti sin arriesgar datos en producción, en VeroLab hacemos justo este tipo de migraciones. Escríbeme y hablamos de tu caso.
Sigue leyendo: Cuando tiene sentido migrar tu proyecto de Lovable a Supabase