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

Warp abre con la frase que la mayoría de las guías de migración ocultan: "Warp no tiene un importador de Cursor con un solo clic".

La razón que da es técnica y correcta: "Cursor está construido sobre la base de código de VS Code, por lo que la configuración de su terminal reside en settings.json bajo claves como terminal.integrated.fontFamily y terminal.integrated.defaultProfile.*. Debido a que ese archivo es legible, el Agent de Warp puede traducir los valores de terminal correspondientes al archivo settings.toml de Warp".

Así que la automatización existe y es real, pero se limita a la apariencia. En el lado del agente, la página es igualmente directa: "Las funciones Composer y Agent de Cursor no tienen una ruta de migración directa; se asignan a diferentes conceptos de Warp".

Aquí está el mapeo que importa, extraído de la propia tabla de equivalencias de Warp:

La fila en la que debes concentrarte es .cursorrules. La instrucción de Warp es refrescantemente directa: "Ejecuta /init en Agent Mode para generar un AGENTS.md, o copia el contenido de tu .cursorrules directamente".

Eso cubre uno de los cuatro ámbitos de instrucción de Cursor. La documentación de Cursor enumera las Reglas de Proyecto en .cursor/rules, las Reglas de Usuario que son "Globales para tu entorno de Cursor", las Reglas de Equipo "gestionadas desde el panel de control" en los planes Team y Enterprise, y AGENTS.md como una "Alternativa simple a .cursor/rules".

Warp tiene dos ámbitos: Reglas Globales y Reglas de Proyecto. Por lo tanto, el mapeo pierde información en una dirección específica: las Reglas de Equipo de Cursor, gestionadas de forma centralizada en un panel de control, no tienen un equivalente en Warp al que puedas apuntar. Se convierten en Reglas Globales en la máquina de cada persona o en un archivo AGENTS.md confirmado en el repositorio, y solo el segundo se mantiene sincronizado por sí mismo.

Una cosa más que vale la pena mencionar antes de que alguien cuente con ello. Warp tiene un sistema de memoria persistente, Agent Memory, y es genuinamente compatible con múltiples entornos; la documentación describe la memoria como "compartida entre todos los entornos de agentes compatibles, incluidos el Warp Agent integrado, Claude Code, Codex y otros a medida que se agreguen". Pero la línea de disponibilidad es inequívoca: "Agent Memory está en vista previa de investigación (research preview) y está habilitada por equipo para socios de diseño (design partners)", con una lista de espera para solicitar acceso. Si tu equipo no es un socio de diseño, planifica esta migración como si aún no estuviera disponible, porque para ti no lo está.

Dos pasos. El primero hace un inventario de lo que Cursor realmente le estaba proporcionando al agente; el segundo lo coloca donde Warp lo leerá.

Paso 1: Inventariar los cuatro ámbitos de Cursor, no solo el que recuerdas

La documentación de Cursor define las reglas directamente como el mecanismo de persistencia: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Lo que significa que tus archivos de reglas son tu contexto, y los necesitas todos.

Abre cada ámbito y copia el contenido:

• Reglas de proyecto en .cursor/rules, como archivos .mdc. Ten en cuenta el truco mientras estás allí: "El sistema de reglas ignora un archivo .md simple en .cursor/rules porque no tiene frontmatter". Si has estado guardando notas como .md en ese directorio, Cursor nunca las leyó y no tiene sentido migrarlas como reglas.
• Reglas de usuario, globales para tu entorno de Cursor. Estas viven contigo, no con el repositorio, y son las que se olvidan con más frecuencia.
• Reglas de equipo, desde el panel de control, si estás en un plan Team o Enterprise. Obtén una exportación antes de perder el acceso.
• AGENTS.md, si ya lo usas. Este es un beneficio directo; se mueve tal cual.

Mientras copias, registra el tipo de activación de cada regla. Los tipos de Cursor son Always Apply (Aplicar siempre), Apply Intelligently (Aplicar de forma inteligente, que se activa "Cuando el Agent decide que es relevante según la descripción") y Apply to Specific Files (Aplicar a archivos específicos, mediante coincidencia de patrones). Necesitarás esto en el lado de Warp, porque el modelo de Warp es más simple y algunas de tus reglas tendrán que cambiar de categoría.

Ten en cuenta también lo que no aparece en ningún archivo: las correcciones que hiciste en el chat durante los últimos seis meses. La documentación de Cursor es explícita en que los modelos no retienen memoria entre completados, por lo que si una preferencia nunca se escribió en una regla, se restablecía en cada sesión y no hay nada que exportar. Escríbelas ahora; esta es la única parte de la migración donde la fuente es tu propia memoria. Si te has preguntado por qué Cursor olvida las reglas de tu proyecto o las olvida entre máquinas, la división en cuatro ámbitos suele ser la respuesta.

Paso 2: Colócalo en los dos ámbitos de Warp y ten en cuenta las reglas de nombre de archivo

Warp admite exactamente dos tipos de reglas: "Las Reglas Globales se aplican a todos los proyectos y contextos" y "Las Reglas de Proyecto residen en tu base de código y se aplican automáticamente al trabajar dentro de ese proyecto. Se almacenan en un archivo AGENTS.md (o WARP.md para compatibilidad con versiones anteriores)".

Mapea de esta manera. Las Reglas de Proyecto de Cursor con Always Apply se convierten en contenido del archivo AGENTS.md raíz. Las Reglas de Proyecto de Cursor limitadas a archivos específicos se convierten en archivos AGENTS.md a nivel de directorio, porque "Warp aplica automáticamente el AGENTS.md (o WARP.md) en la raíz y en el directorio actual". Las Reglas de Usuario de Cursor se convierten en Reglas Globales de Warp. Las Reglas de Equipo de Cursor se convierten en contenido de AGENTS.md confirmado en el repositorio, que es la única forma que se mantiene compartida.

Tres reglas de nombre de archivo te afectarán si las pasas por alto:

1. "El nombre del archivo debe estar en mayúsculas para que Warp lo reconozca (por ejemplo, AGENTS.md, no agents.md ni Agents.md)".
2. "Si tanto WARP.md como AGENTS.md existen en el mismo directorio, WARP.md tiene prioridad". Por lo tanto, un WARP.md sobrante de un experimento anterior ganará silenciosamente sobre el archivo que acabas de escribir.
3. Warp recomienda AGENTS.md para proyectos nuevos y sigue admitiendo archivos WARP.md existentes, que puedes renombrar en cualquier momento sin otros cambios.

Las reglas que dependían del modo Apply Intelligently de Cursor requieren una decisión, porque las Reglas de Proyecto de Warp se aplican automáticamente por ubicación en lugar de por el criterio del modelo. Hazlas incondicionales o limítalas a un directorio. Mantenerlas vagas y esperar que se activen por relevancia es la forma en que un conjunto de reglas migrado se ignora silenciosamente, el mismo modo de fallo detrás de por qué los agentes ignoran tus archivos de instrucciones.

No te saltes /init. Ejecutarlo en Agent Mode genera un AGENTS.md con la estructura que Warp espera, lo cual es un mejor punto de partida que un archivo .cursorrules pegado.

Sigue los dos pasos anteriores y tendrás una configuración de Warp correcta. También habrás demostrado el punto incómodo: la parte automatizada de esta migración movió tu fuente, y la parte manual movió todo lo que importaba.

Esa asimetría no es culpa de Warp, ni de Cursor. Es lo que sucede cuando el conocimiento acumulado de un proyecto vive dentro del formato de archivo de una sola herramienta. La propia respuesta de Warp a esto, Agent Memory, es la idea correcta y actualmente está limitada a equipos de socios de diseño. Una capa de memoria externa te brinda la misma propiedad hoy, sin lista de espera. MemoryLake se configura en tres pasos.

Paso 1: Crear una clave API

Inicia sesión y genera una clave API desde tu panel de control. Esta credencial pertenece a tu equipo en lugar de a un editor, lo que permite que el mismo conocimiento sea legible desde Warp hoy y desde cualquier herramienta que evalúes el próximo trimestre.

Paso 2: Subir tus primeras memorias

Coloca las cosas que anotaste en el Paso 1 que no tenían un archivo donde residir: decisiones arquitectónicas y por qué se tomaron, las convenciones que seguías repitiendo en el chat, detalles específicos del cliente y del dominio, la razón por la que existe una solución temporal en particular. También coloca el contenido de las Reglas de Equipo aquí si la gestión centralizada era importante para ti; es lo más parecido a un ámbito gestionado desde un panel de control que tendrás en el lado de Warp.

Conserva AGENTS.md para lo que es bueno: las reglas que siempre deben aplicarse, confirmadas y revisables en el repositorio.

Paso 3: Conectar tu IA y agentes

Apunta el Agent de Warp al almacén. Si parte del equipo se queda en Cursor durante un período de prueba (que es la forma sensata de realizar una migración), ambos editores leerán la misma capa en lugar de bifurcarse en dos conjuntos de reglas divergentes que alguien tendrá que conciliar más tarde.

El primer cambio es que un período de prueba deja de ser costoso. La mayoría de las evaluaciones de Cursor a Warp se estancan porque mantener dos conjuntos de reglas sincronizados es tedioso, por lo que la gente se compromete demasiado pronto o abandona la prueba. Con la capa duradera fuera de ambos, ejecutarlos en paralelo no cuesta nada adicional.

El segundo es que la brecha de las Reglas de Equipo deja de importar. Los dos ámbitos de Warp son limpios, pero ninguno se gestiona de forma centralizada como un panel de control; un almacén compartido restaura esa propiedad sin pedirle a todos que mantengan Reglas Globales idénticas a mano.

El tercero es que dejas de competir por el espacio del prompt. Las reglas que siempre se aplican se concatenan en el contexto cada vez, lo cual es exactamente correcto para diez convenciones e incorrecto para doscientos datos sobre tu dominio. Dividir las "reglas que el agente debe seguir" de las "cosas que el agente debe saber" es la versión práctica de la distinción en lo que los agentes de programación realmente leen.

• Ejecuta primero la portabilidad de la configuración y luego olvídate de ella. Deja que el Agent de Warp traduzca settings.json con la habilidad modify-settings y revisa las diferencias. Maneja la apariencia; no esperes más.
• Inventaría los cuatro ámbitos de Cursor antes de desinstalar nada. Las Reglas de Usuario y las Reglas de Equipo son las que la gente suele perder.
• Elimina los archivos .md sueltos de .cursor/rules en lugar de migrarlos. Cursor los estaba ignorando; migrarlos solo mueve peso muerto.
• Comprueba si queda un archivo WARP.md sobrante. En el mismo directorio, tiene prioridad sobre AGENTS.md, lo que produce una sesión de depuración muy confusa.
• Usa nombres de archivo en mayúsculas. No se reconoce agents.md.
• Convierte las reglas de Apply Intelligently en reglas siempre activas o limitadas a un directorio. Warp aplica las reglas del proyecto por ubicación, no por criterio de relevancia.
• No planifiques en torno a Agent Memory a menos que tengas acceso. Está en vista previa de investigación para equipos de socios de diseño, con una lista de espera. Escribe tu migración para lo que puedas usar esta semana.
• Mantén las decisiones y el conocimiento del dominio fuera del archivo de reglas. Las reglas son para el comportamiento; el creciente cuerpo de contexto pertenece a un lugar donde pueda crecer.

Warp merece crédito por una página de migración que dice "sin importador de un solo clic" en el primer párrafo. Esa honestidad te dice dónde está el trabajo: la terminal se mueve sola, .cursorrules se copia en AGENTS.md y todo lo que tu agente aprendió sobre tu proyecto tiene que ser reescrito por una persona que lo recuerde.

Harás esa reescritura una vez para esta migración. Si lo vuelves a hacer para la próxima dependerá de dónde lo coloques esta vez.