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

Los elementos a nivel de editor se trasladan solos. Ambos son bifurcaciones (forks) de VS Code, por lo que las extensiones, los temas, los atajos de teclado y las configuraciones se transfieren con un esfuerzo mínimo. Esta es la parte que hace que la migración parezca fácil y oculta la parte que no lo es.

Tus reglas se transfieren como texto, no como comportamiento. La documentación de la comunidad describe que Windsurf maneja dos sistemas de reglas en paralelo: un archivo heredado .windsurfrules en la raíz del proyecto y los archivos Markdown con alcance más recientes bajo .windsurf/rules/, con un límite de caracteres combinado que se reporta alrededor de los 12,000 caracteres. El modelo de Cursor es de una naturaleza diferente. Las reglas del proyecto residen en .cursor/rules como archivos .mdc bajo control de versiones, y tres campos de frontmatter (alwaysApply, description, globs) deciden cuándo entra cada una en contexto.

Por lo tanto, el contenido sobrevive a la copia pero la activación no, razón por la cual un conjunto de reglas copiado parece funcionar y luego, silenciosamente, deja de tener efecto.

Las memorias de Cascade no se transfieren en absoluto. Se generan automáticamente, residen en la máquina que las creó, no se comparten con los compañeros de equipo y no existe una ruta de exportación. Ten en cuenta lo que esto significa para la migración: estaban haciendo un trabajo real para ti, son la única parte con una fecha límite estricta y la única forma de extraerlas es preguntarle al asistente antiguo qué sabe mientras aún esté en funcionamiento.

Cualquier cosa que nunca hayas escrito tampoco se transfiere. La razón por la que un directorio está fuera de límites, el orden de despliegue, las restricciones del cliente. No estaba en un archivo de reglas y no estaba en la memoria de Cascade de una forma que puedas leer, por lo que solo existe en tu cabeza y en la mente del compañero de equipo que lo recuerde.

Lo que Cursor te ofrece al otro lado es más estructura de la que tenías. Cuatro tipos de reglas, según su documentación: reglas de proyecto en .cursor/rules (bajo control de versiones, con alcance de repositorio), reglas de usuario que se aplican a todo tu entorno de Cursor, reglas de equipo gestionadas en el panel de control en los planes Team y Enterprise, y AGENTS.md como una alternativa en Markdown simple a .cursor/rules. Cursor también explica el mecanismo con claridad: "Los modelos de lenguaje grandes no retienen memoria entre completados. Las reglas proporcionan un contexto persistente y reutilizable a nivel de prompt". Las reglas se anteponen al contexto del modelo. No son memoria, y Cursor no afirma que lo sean.

Paso 1: Interroga a Cascade antes de desinstalar nada

Haz esto primero y hazlo mientras el editor antiguo todavía se pueda abrir. Abre Cascade y pregúntale, en lenguaje sencillo, qué ha aprendido sobre este proyecto: convenciones, trampas comunes, decisiones, cualquier cosa que recuerde sobre cómo trabajas. Pregúntale repetidamente, con diferentes enfoques, y pega las respuestas en un archivo borrador. Luego pregúntale qué cree que no debería hacer en esta base de código, lo que sacará a la luz un conjunto de recuerdos diferente al de la pregunta positiva.

Esta es la única hora irreversible en la migración. Los archivos de reglas están en el disco y seguirán allí la próxima semana. Las memorias de Cascade son un estado generado localmente en la máquina sin opción de exportación, y una vez que el editor desaparece, también lo hacen ellas.

Mientras estás en el proyecto antiguo, haz también un inventario de los propios archivos:

• .windsurfrules en la raíz del proyecto, si todavía tienes uno
• todo lo que esté bajo .windsurf/rules/
• flujos de trabajo y cualquier definición de herramientas que hayas configurado
• la configuración del servidor MCP, que volverás a añadir en lugar de convertir

Luego clasifica las reglas en tres grupos según su origen: derivadas del repositorio (el README también lo dice: elimínalas), escritas por ti y que siguen siendo válidas (esta es la migración), y escritas por ti pero obsoletas (elimínalas ahora, deliberadamente, mientras aún recuerdes cuál es cuál). Una migración es el único momento en el que alguien lee cada regla con ojos nuevos. Aprovéchalo.

Paso 2: Reescribe cada regla con la activación que merece

Ahora convierte las reglas, una a una, y elige el tipo a propósito. Los cuatro modos de Cursor se corresponden con cuatro costes diferentes:

• Always Apply (alwaysApply: true): se incluye en cada sesión de chat, ignorando los globs y la descripción. Reserva esto para el puñado de reglas que harían que una respuesta fuera incorrecta: el encabezado de derechos de autor, "nunca edites archivos generados en dist/", la restricción arquitectónica estricta.
• Apply to Specific Files (con globs definido, alwaysApply: false): se adjunta automáticamente cuando un archivo coincidente está en contexto. Aquí es donde pertenece la mayoría de tus reglas con alcance de Windsurf: globs: src/components/**/*.tsx expresa "las reglas del frontend" como un patrón en lugar de una esperanza.
• Apply Intelligently (con description definido, sin globs): el agente lee la descripción e incorpora la regla cuando considera que es relevante. Útil para reglas de dominio que no se corresponden con una ruta, y solo es tan bueno como la descripción que escribas.
• Apply Manually (sin descripción, sin globs): se incluye solo cuando lo mencionas con @, como @my-rule. El lugar adecuado para esa larga lista de verificación que deseas bajo demanda y no en cada completado.

Tres trampas mecánicas que debes evitar mientras haces esto:

La extensión importa. Las reglas del proyecto deben usar .mdc. La documentación de Cursor indica que el sistema de reglas ignora los archivos .md ordinarios en .cursor/rules porque carecen de los campos de frontmatter. Si prefieres Markdown simple, la ruta documentada es AGENTS.md, no un archivo .md en la carpeta de reglas.

No marques todo como Always Apply. Es la forma más rápida de hacer que la migración "funcione" y la forma más segura de hacerla inútil: cada regla en cada completado diluye las que realmente importan, y la recomendación de Cursor es mantener las reglas por debajo de las 500 líneas. Si tu configuración de Windsurf estaba al límite de un presupuesto de caracteres, ese presupuesto te estaba haciendo un favor al obligarte a elegir. Aquí nada lo impone.

Coloca los estándares compartidos donde tus compañeros de equipo puedan acceder a ellos. Las reglas del proyecto están bajo control de versiones, por lo que confirmarlas (commit) es la forma en que el equipo hereda tu trabajo. En los planes Team y Enterprise, las reglas de equipo en el panel de control son la capa superior a esa. Tus hábitos personales van en las reglas de usuario, no en el repositorio.

Finalmente, toma el conocimiento de Cascade que recopilaste en el Paso 1 y colócalo deliberadamente. La mayor parte no tiene forma de regla: es contexto, historia y razonamiento. Parte se convierte en una regla; el resto pertenece a la documentación del repositorio o a un almacén que tus asistentes puedan leer, que es lo que tratamos en la siguiente sección.

Mira lo que acabas de hacer. Convertiste el formato de reglas de un proveedor al formato de reglas de otro proveedor, y copiaste a mano un conjunto de memorias de una ventana de chat porque no había otra manera. Si Cursor cambia de manos el próximo año (y la razón por la que estás leyendo esto es que tu último editor lo hizo), lo volverás a hacer.

La división duradera es esta: las reglas se quedan en el repositorio, porque eso es lo que un agente de programación necesita tener delante. El conocimiento detrás de las reglas va a un lugar que no pertenece a ningún editor.

MemoryLake es una capa de memoria para eso: las decisiones, los informes de incidentes y los documentos de origen a partir de los cuales se comprimen tus reglas, en un solo almacén, legibles directamente desde herramientas compatibles con MCP como Claude y Codex, y desde ChatGPT a través de la API. El archivo .mdc dice qué hacer; el almacén dice por qué, y sobrevive al editor.

Paso 1: Crea una clave API

Genera una clave y realiza tu primera solicitud en unos 30 segundos. Manténla en tu entorno o en un gestor de secretos en lugar de pegarla en una ventana de chat.

Paso 2: Sube tus primeras memorias

Arrastra los documentos, imágenes y archivos que respaldan las reglas que acabas de convertir: el informe de incidente que dejó un módulo fuera de límites, la decisión de arquitectura y su fecha, los requisitos del cliente, los contratos de API, además del conocimiento de Cascade que recopilaste. Sube las fuentes en lugar de un resumen ordenado; el resumen es lo que pasaste el Paso 1 intentando reconstruir.

Paso 3: Conecta tu IA y agentes

Dale a Claude, Codex, OpenClaw y otros agentes de IA acceso a la memoria a través de MCP o la API. Las herramientas compatibles con MCP leen el mismo almacén directamente junto con sus propios archivos de reglas. Para ChatGPT, recupera lo que necesitas a través de la API e inyéctalo en el prompt o en el flujo de trabajo que llama al modelo.

La primera diferencia es que tu conjunto de Always Apply puede mantenerse pequeño. La presión por cargarlo todo proviene de no tener otro lugar donde ponerlo; cuando el detalle es recuperable, las reglas cargadas siempre son las tres restricciones que realmente cambian las respuestas.

La segunda es que el motivo viaja con la regla. "No edites archivos en generated/" es cuestionado por cada nuevo ingeniero y cada nuevo agente. La misma regla con el ticket y el incidente adjuntos no lo es, y esa es la diferencia entre una convención y una decisión arquitectónica que sobrevive.

La tercera es que la recopilación se convierte en un coste de una sola vez. Lo hiciste para Cascade. No lo harás para Cursor, porque el conocimiento no quedará atrapado en Cursor, lo que también significa que estará allí cuando un compañero de equipo pregunte, en lugar de estar solo en tu portátil, la misma brecha que hay detrás de las reglas que no te siguen entre máquinas.

And it composes with what Cursor does natively. Rules keep doing their job at the prompt level, exactly as documented. The store holds what rules were never meant to hold: history, rationale, and the documents themselves.

Asume que nada de lo que vive en la aplicación se puede exportar

Los archivos de reglas son tuyos. Las memorias generadas, en cualquier herramienta, generalmente no lo son. Antes de desinstalar, pregúntale al asistente qué sabe y copia las respuestas. Trata todo lo que solo existe en una interfaz de usuario como algo perecedero.

Convierte el alcance, no solo el texto

El acto de mayor valor en esta migración es convertir "estas son mis reglas de frontend" en globs: src/components/**/*.tsx. Las reglas con alcance de ruta se cargan cuando son relevantes y se mantienen fuera del contexto cuando no lo son, lo cual es tanto más económico como más preciso que una regla que espera que el modelo note un calificador.

Confirma las reglas en el repositorio y usa la capa de equipo para los estándares

Una regla bajo control de versiones se puede revisar y heredar; una regla en tu configuración personal, no. En los planes Team o Enterprise, coloca los estándares de toda la organización en las reglas de equipo para que no dependan de la configuración local de cada desarrollador.

Elimina durante el traslado

Cada regla obsoleta que traslades será obedecida, silenciosamente, por un agente que no tiene forma de saber que está desactualizada. El coste de eliminar una regla que aún necesitabas es de un minuto para volver a escribirla. El coste de mantener una incorrecta es una semana de diferencias (diffs) confusas.

No trates las reglas como una imposición

Cursor tiene claro que las reglas proporcionan contexto a nivel de prompt. Eso es influencia, no una garantía. Cualquier cosa que deba cumplirse siempre (formato, no hacer push directo a main, archivos generados intactos) pertenece a un formateador, un hook o a la CI. Las reglas explican; las herramientas imponen.

La migración de Windsurf a Cursor parece una copia de archivos y no lo es. Ambos editores son bifurcaciones de VS Code, por lo que la capa del editor se traslada sola, y luego la parte que importa (cuándo se aplica cada regla) tiene que reconstruirse en los términos de Cursor: archivos .mdc cuyo frontmatter elige Always Apply, patrón de archivo, seleccionado por el agente o manual. Copia archivos .md simples en .cursor/rules y se ignorarán por completo, sin ningún error que te lo advierta.

Así que haz las dos cosas en el orden correcto. Interroga a Cascade antes de desinstalar, porque las memorias locales generadas automáticamente no tienen opción de exportación ni segunda oportunidad. Luego, reescribe cada regla con la activación que merece, elimina lo que esté obsoleto, confirma lo que tu equipo necesita y coloca el razonamiento detrás de esas reglas en un almacén que no esté dentro de un editor. La próxima vez que un IDE cambie de manos, ese almacén será la razón por la que te costará una tarde en lugar de una semana.