Cómo migrar de Lovable a Cursor sin perder el contexto (2026)

El código se transfiere y se sigue transfiriendo. La integración de GitHub de Lovable realiza la exportación y la sincronización bidireccional: los cambios realizados en Lovable se sincronizan con GitHub, y los cambios subidos (pushed) a la rama activa de GitHub se sincronizan de vuelta en Lovable. Hay dos capas: una conexión de espacio de trabajo que autoriza a Lovable a través de su aplicación de GitHub y es reutilizable en todos los proyectos, además de un enlace de repositorio de proyecto que conecta un proyecto de Lovable con un repositorio.

Vale la pena conocer algunos límites reales antes de confiar en ello. Lovable solo edita y sincroniza una rama a la vez, normalmente la predeterminada del repositorio (por lo general main); para trabajar en otro lugar, debes elegir una rama diferente en la configuración de GitHub del proyecto, donde también puedes crear una. No puedes importar un repositorio de GitHub existente a Lovable, y no puedes volver a conectarte al mismo repositorio después de desconectarlo (obtendrás uno nuevo). La aplicación de GitHub no se puede instalar dos veces en la misma cuenta u organización, los archivos de más de 100 MB no se sincronizan y cambiar el nombre de un usuario u organización de GitHub rompe la conexión.

Las variables de entorno y los secretos suelen ser el primer tropiezo. La documentación de GitHub de Lovable no los aborda y, en la práctica, el repositorio no es donde viven las claves de tus proveedores; los desarrolladores que han realizado esta migración informan de manera constante que configuran las credenciales de Supabase, Stripe y similares a mano después de clonar. Reserva una hora para los fallos del tipo "funcionaba en Lovable" que resultan ser una variable de entorno faltante.

El Knowledge no se transfiere, y esa es la única razón por la que Cursor parece menos inteligente. La función Knowledge de Lovable te permite proporcionar instrucciones y contexto persistentes al agente, en dos niveles:

• Workspace Knowledge — reglas compartidas en todos los proyectos de un espacio de trabajo: convenciones de estilo de código, convenciones de nomenclatura, librerías o frameworks preferidos, patrones arquitectónicos compartidos, requisitos de pruebas, calidad de código o reglas de linting. Solo los propietarios y administradores del espacio de trabajo pueden gestionarlo.
• Project Knowledge — instrucciones y contexto persistentes para un solo proyecto: qué hace la aplicación, perfiles de usuario (personas), esquema de base de datos, decisiones de arquitectura, terminología del dominio, pautas de diseño y enlaces a referencias importantes. Editable por cualquier persona con permisos de edición del proyecto.

Ambos viven en Settings → Knowledge y Project settings → Knowledge, ambos están limitados a 10,000 caracteres y —esta es la parte que la gente subestima— el Knowledge siempre se incluye como contexto de fondo para Lovable en cada mensaje, aunque la propia documentación de Lovable señala que la consistencia puede variar en conversaciones extremadamente largas.

Lee esa lista de nuevo y notarás que es un archivo de reglas. Lovable estaba haciendo lo que hace .cursor/rules; simplemente lo hacía en un cuadro de texto que quizás no habías abierto en meses.

El historial de chat no se transfiere, y esta es la verdadera pérdida. Cada "no, así no" que escribiste, cada restricción que descubriste al tropezar con ella, cada enfoque que rechazaste; todo eso está en la conversación, y la conversación se queda en Lovable. Parte de ello está en Knowledge si fuiste disciplinado. La mayor parte no lo está, razón por la cual el hecho de que Lovable pierda el hilo del contexto del proyecto entre sesiones es una queja común también en ese lado.

Paso 1: Llevar el código a Cursor y confirmar qué está haciendo la sincronización

En tu proyecto de Lovable, abre Settings y conecta GitHub si no lo has hecho, lo cual autoriza la aplicación de GitHub de Lovable y crea el repositorio. Luego, clónalo localmente y abre la carpeta en Cursor.

Decide tu postura de sincronización antes de empezar a editar, porque la sincronización bidireccional funciona en ambos sentidos:

• Ruptura limpia — has terminado con Lovable. Clona y trabaja normalmente; nada fluye de vuelta.
• Mantener ambos — Lovable para una iteración rápida de la interfaz de usuario, Cursor para la lógica. Es legítimo y común, y ambos no son realmente competidores. Solo recuerda que Lovable solo está observando una rama: los commits que subas a esa rama fluirán de vuelta a Lovable, y el trabajo en otras ramas será invisible para él hasta que cambies el selector de ramas.

Luego, maneja el entorno. Copia cualquier .env.example que exista, completa los valores reales desde los paneles de tus proveedores y verifica que la aplicación se ejecute localmente antes de cambiar cualquier código. Hacer esto primero significa que el próximo fallo que veas será tuyo, no una clave faltante.

Una advertencia: no desconectes la integración de GitHub para "limpiar las cosas". No podrás volver a conectar el mismo repositorio después —Lovable creará uno nuevo— lo que convierte una limpieza en una bifurcación (fork) de tu propio proyecto.

Paso 2: Convertir el Knowledge de Lovable en reglas de Cursor

Esta es la parte que determina si Cursor se siente como un paso atrás.

Abre ambos niveles de Knowledge en Lovable y cópialos. Luego, mapéalos al modelo de Cursor, que es más granular que el de Lovable:

Las reglas de proyecto de Cursor viven en .cursor/rules como archivos .mdc, controlados por versiones, con campos de frontmatter description, globs y alwaysApply, y cuatro modos de activación:

• Always Apply — cada sesión de chat
• Apply Intelligently — cuando el Agent decide que es relevante según la descripción
• Apply to Specific Files — cuando un archivo coincide con un patrón
• Apply Manually — cuando se menciona con @ en el chat

Debido a que el Knowledge de Lovable siempre estaba activo, la conversión perezosa es hacer que todo sea Always Apply. No lo hagas. Tienes 10,000 caracteres de Knowledge de Lovable por nivel y la documentación de Cursor recomienda mantener las reglas por debajo de las 500 líneas, divididas en piezas componibles; así que aprovecha la granularidad que se te acaba de dar:

• Workspace Knowledge (estándares de código, nomenclatura, librerías preferidas, linting) → User Rules de Cursor, las preferencias globales en Customize → Rules que se aplican a todos los proyectos. Esa es la coincidencia estructural más cercana, y significa que tu próximo proyecto las heredará de la misma manera que en Lovable.
• Project Knowledge que es genuinamente global para el repositorio (qué hace la aplicación, terminología del dominio) → una regla Always Apply en .cursor/rules, o AGENTS.md en la raíz del proyecto, que Cursor admite como alternativa a .cursor/rules y que también lee desde subdirectorios.
• Project Knowledge que es específico de un área (esquema de base de datos, pautas de diseño) → reglas con alcance (scoped). Una regla de esquema con globs apuntando a tu capa de datos solo se carga cuando estás trabajando allí. Esto es estrictamente mejor que lo que Lovable podía hacer, y es la principal mejora en la migración.
• Enlaces a referencias importantes → mantenlos como una regla que mencionas con @, o como documentos en el repositorio a los que se apunta desde AGENTS.md. No necesitan estar en cada solicitud.

Luego, documenta lo que nunca estuvo en Knowledge. Revisa tu historial de chat de Lovable —o al menos las últimas dos semanas— y extrae las decisiones. No el código, sino las razones: por qué esta estructura de componentes, qué librería probaste y abandonaste, qué vetó el cliente. Coloca cada una en un documento con fecha en el repositorio. Esto es tedioso y es la hora de mayor valor de toda la migración, porque es el único contenido en este proceso que no se puede reconstruir a partir de los artefactos.

Vale la pena ser honestos sobre lo que has construido al final del Paso 2: una versión mejor organizada de lo mismo. La propia documentación de Cursor explica por qué existe este mecanismo en primer lugar: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt." Las reglas son una forma de volver a suministrar contexto cada vez. Contienen lo que te acordaste de escribir, y son el formato de una herramienta específica, que es exactamente la situación en la que te encontrabas con Knowledge.

Mira lo que realmente fue el Paso 2: copiaste el contexto de un cuadro de texto de 10,000 caracteres de un producto y lo pegaste en el formato de archivo de otro producto, luego reconstruiste a mano las partes que nunca estuvieron en ninguno de los dos.

Ahora considera que muchas personas que realizan esta migración siguen usando ambas herramientas, y aquí está la divergencia que nadie planea. Tu código se mantiene sincronizado automáticamente, porque eso es lo que hace la integración de GitHub. Tu conocimiento no. Las decisiones que tomas en Cursor nunca llegan al Knowledge de Lovable, por lo que Lovable sigue generando código basándose en una imagen del proyecto que tiene un mes de antigüedad, y el desfase se manifiesta en componentes regenerados que violan silenciosamente las reglas que estableciste en otro lugar. La sincronización bidireccional de código combinada con un conocimiento unidireccional es un peor modo de fallo que no tener sincronización en absoluto, porque parece que todo está bien.

Mantener el conocimiento en una sola capa que ambas herramientas puedan leer es lo que soluciona eso. MemoryLake es una capa de memoria que se sitúa debajo de tus herramientas: decisiones, esquemas, terminología de dominio y las razones detrás de ellos en un solo almacén, legible desde Cursor a través de MCP y desde cualquier otra cosa mediante la API. El almacén no está limitado a un cuadro de texto y no es un formato que tendrás que volver a convertir en el próximo cambio de herramienta.

Justicia a quien la merece: el Knowledge de Lovable es una función bien diseñada para lo que hace. Dos niveles de alcance, siempre aplicados, editables por las personas adecuadas, y realmente hace que el agente se comporte bien. .cursor/rules de la misma manera es texto plano, controlado por versiones, revisado en pull requests y heredado por tu equipo automáticamente. Sigue usando ambos para reglas permanentes. La capa de memoria es para el registro acumulado: demasiado largo para un campo de 10,000 caracteres, demasiado específico para publicar y demasiado fácil de perder como para depender de que alguien lo escriba.

Paso 1: Crear una clave API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Mantenla en tu entorno o en un gestor de secretos; ya estás configurando variables de entorno para este proyecto, así que agrégala allí en lugar de en un archivo que se sincronice con GitHub.

Paso 2: Subir tus primeros recuerdos

Arrastra los documentos, imágenes y archivos que contienen lo que el Knowledge no pudo albergar: el esquema con su historial, las decisiones de arquitectura y sus porqués, las pautas de diseño, las restricciones del cliente. Sube fuentes en lugar de resúmenes siempre que puedas.

Paso 3: Conectar tu IA y agentes

Dale acceso a la memoria a Claude, Codex, OpenClaw y otros agentes de IA a través de MCP o la API. Cursor admite servidores MCP, por lo que esto es una entrada de configuración. Para herramientas sin un cliente MCP, recupera lo que necesitas a través de la API e inyéctalo en el prompt o flujo de trabajo.

La primera diferencia se nota en tu primera tarea real en Cursor. En lugar de un editor que conoce tu árbol de archivos y nada más, obtienes uno que puede responder por qué el flujo de autenticación tiene esa forma, porque la decisión está en el almacén, no en un hilo de Lovable.

La segunda es que las reglas con alcance comienzan a hacer un trabajo que Lovable no podía. Tus convenciones de esquema se cargan cuando estás en la capa de datos y no estorban cuando estás editando CSS. Esa es una ganancia real de capacidad con la migración, y solo se materializa si te resistes a convertir todo a Always Apply.

La tercera es el problema de desfase mencionado anteriormente. Cuando ambas herramientas leen un solo almacén, una decisión tomada en Cursor es visible para lo que sea que uses a continuación, lo cual es la diferencia entre dos herramientas que cooperan y dos herramientas que poco a poco van discrepando sobre tu proyecto.

Y sobrevive al siguiente paso. Mucha gente pasa de Lovable → Cursor → a otra cosa en menos de un año. El patrón está lo suficientemente consolidado como para que las migraciones de plataformas de prototipos a editores reales sean su propio género ahora. El conocimiento dentro de la herramienta significa que tienes que volver a hacer esto; el conocimiento debajo de ella significa que no.

Verificar que la aplicación se ejecute localmente antes de cambiar nada

Clona, instala, configura las variables de entorno, ejecuta. El reporte más común de "el código de Lovable está roto" es una credencial faltante, y diagnosticar eso mientras también haces refactorización es una pesadilla. Consigue una ejecución exitosa primero, luego comienza a trabajar.

No conviertas todo el Knowledge a Always Apply

El Knowledge de Lovable siempre estaba activo porque esa era la única opción. Cursor te ofrece globs y activación basada en descripciones; úsalos. Todo lo configurado como Always Apply se carga en cada solicitud para siempre, y un directorio de reglas inflado es el arrepentimiento estándar de esta migración.

Migra las razones, no solo las reglas

Knowledge le dice a Cursor cuáles son tus convenciones. Rara vez dice por qué, y el porqué es lo que evita que un agente te vuelva a proponer alegremente la librería que ya abandonaste. Extrae las razones de tu historial de chat mientras aún recuerdes qué hilos son importantes.

Decide tu postura de sincronización de forma explícita

O te comprometes con una ruptura limpia o te comprometes a mantener ambos; y si mantienes ambos, recuerda que Lovable observa una rama a la vez y que su Knowledge no aprenderá nada de tu trabajo en Cursor. Los proyectos a medio migrar donde nadie sabe qué herramienta tiene la autoridad son la razón por la cual los componentes se regeneran por encima de las correcciones escritas a mano.

Pasar de Lovable a Cursor no es realmente una migración de código: la sincronización bidireccional de GitHub se encarga del código, con las advertencias de que solo se sincroniza una rama, no puedes importar un repositorio existente a Lovable y no puedes volver a conectar un repositorio después de desconectarlo. La migración es tu Knowledge: dos niveles de 10,000 caracteres que se aplicaban a cada mensaje, que deben convertirse en User Rules para las convenciones a nivel de espacio de trabajo y en .cursor/rules con alcance para las específicas del proyecto, además de un documento con fecha para cada decisión que solo existió en un hilo de chat.

La elección que vale la pena tomar deliberadamente es dónde vivirá ese conocimiento después. En las reglas de Cursor, sirve a este repositorio en este editor y se volverá a convertir la próxima vez. En una capa que ambas herramientas leen, se mantiene actualizado en ambas, lo cual es de suma importancia precisamente en el caso en el que la gente termina encontrándose, donde tanto Lovable como Cursor siguen abiertos.