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

Por el lado de Trae. Trae guarda las reglas a nivel de proyecto en .trae/project_rules.md y las reglas a nivel de usuario en .trae/user_rules.md. También crea un directorio .trae/rules/ en el proyecto, y puedes organizar los archivos de reglas en subcarpetas dentro de él; el sistema lee esos directorios de forma recursiva. Las reglas se invocan en el chat con #rulename, y todo es Markdown simple específicamente para que pueda controlarse por versiones y compartirse en un equipo. El soporte de MCP y .rules llegaron juntos en Trae v1.3.0, por lo que cualquier servidor MCP que hayas configurado es un concepto que se transfiere en lugar de algo que pierdes.

Por el lado de Cursor. Las reglas del proyecto viven en .cursor/rules como archivos .mdc, cada uno con uno de cuatro modos de activación: Always Apply, Apply Intelligently, Apply to Specific Files y Apply Manually. Cursor también lee un archivo AGENTS.md simple en la raíz del repositorio, que es el formato abierto que también leen Codex, Amp, Jules y Factory. Las preferencias personales que no deben confirmarse en el repositorio van en User Rules dentro de la configuración de Cursor.

Así que el mapeo es directo:

Lo que no se transfiere. Tres categorías, en orden ascendente de dolor:

1. Historial de sesiones. Tus conversaciones de Trae se quedan en Trae. Nada las leerá por ti.
2. Lo que sea que hayas dejado en el chat en lugar de en el archivo. La mayoría de las personas explican mucho más por sesión de lo que llegan a escribir. Esa explicación nunca se persistió en ningún lado.
3. Los enfoques rechazados. Lo más costoso de perder, porque Cursor te propondrá alegremente la refactorización que ya probaste y revertiste, y pasarás una tarde volviendo a decidir una cuestión ya resuelta.

Vale la pena señalar lo que la comunidad de Trae construyó para hacer frente a esto: existen paquetes de continuidad de flujo de trabajo de terceros para Trae que guardan el contexto bajo un comando y lo restauran bajo otro, precisamente porque la continuidad de la sesión tenía que hacerse a mano. Si has estado usando algo así, esos archivos guardados son la mejor materia prima que tienes para esta migración.

Paso 1: Mueve las reglas y divídelas de paso

No pegues un solo project_rules.md largo en un solo archivo .mdc largo. Los modos de activación de Cursor solo ayudan si las reglas están separadas por tema.

• Lee .trae/project_rules.md y divídelo en temas: comandos de compilación y prueba, convenciones de directorios, estilo, restricciones de seguridad, cualquier cosa sobre un subsistema específico.
• Crea un .mdc por tema en .cursor/rules y define el modo deliberadamente. Las restricciones universales van en Always Apply. Las reglas específicas de un subsistema van en Apply to Specific Files con globs. Los manuales ocasionales (una lista de verificación de lanzamiento, un procedimiento de migración) van en Apply Manually y se invocan cuando es necesario, de la misma manera que usabas #rulename en Trae.
• No configures todo en Always Apply. Es tentador y costoso: cada regla siempre activa consume tokens en cada completado. Este es el error más común en una migración de reglas y se manifiesta como una factura, no como un error.
• Mueve .trae/user_rules.md a las User Rules de Cursor en lugar de confirmarlo en el repositorio; las preferencias personales no deberían estar en el repositorio.
• Si es probable que tu proyecto sea tocado por más de un agente, considera colocar el núcleo neutral de la herramienta en un archivo AGENTS.md en la raíz, ya que Cursor y varios otros agentes lo leen.
• Reconfigura tus servidores MCP en Cursor y confirma que cada uno responda antes de confiar en él.

Paso 2: Reconstruye lo que las reglas nunca llegaron a contener

Reserva una hora y escribe el conocimiento que solo existía en las sesiones de Trae:

• Decisiones y sus razones. "El consumidor de la cola sigue siendo de un solo hilo porque el orden importa para los reembolsos" es una línea que evita una mala sugerencia durante el próximo año.
• Callejones sin salida. Enfoques probados y revertidos, con la razón. Esto es lo que detiene el bucle.
• Trampas locales. La prueba que falla de forma intermitente en Windows, el archivo generado que nunca debe editarse a mano, la migración que debe ejecutarse antes de la siembra de datos (seed).
• Cualquier cosa de un archivo de contexto guardado. Si usaste un flujo de trabajo de continuidad de Trae, explora esos archivos ahora; son el único registro escrito que tienes de tus sesiones.

Escribe esto como conocimiento, no como reglas. No pertenece a un .mdc siempre activo, porque crece cada semana y nadie quiere pagar por un preámbulo de 900 líneas en cada completado.

Lo que plantea la pregunta obvia: ¿dónde pertenece realmente?

Ambos editores te ofrecen las mismas dos cosas: un archivo de reglas y un contexto nuevo en cada sesión. Por eso la migración es fácil y por eso también se pierden datos. Las reglas son el lugar adecuado para las restricciones y el lugar equivocado para el conocimiento acumulado, y ni Trae ni Cursor ofrecen un tercer lugar para ponerlo. Así que termina en el chat, y el chat termina cuando finaliza la sesión.

La solución es agregar la capa que falta en lugar de escribir un archivo de reglas más largo. MemoryLake es una capa de memoria que vive fuera del editor y es accesible a través de MCP o una API, por lo que el conocimiento deja de ser específico del editor, y la próxima migración dejará de ser un proyecto de arqueología.

Paso 1: Crea una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos.

Paso 2: Sube tus primeras memorias

Carga el registro de decisiones que acabas de escribir, además del material que la gente sigue explicando una y otra vez: notas de arquitectura, contratos de API, manuales de procedimientos (runbooks), informes de incidentes, diagramas. Los documentos, imágenes y otros archivos van todos al mismo lugar.

Paso 3: Conecta tu IA y agentes

Dale acceso a Cursor, Claude, Codex, OpenClaw y otros agentes a través de MCP. Tus archivos .cursor/rules volverán a ser cortos y con forma de reglas, y el conocimiento que crece semanalmente vivirá en un lugar que cualquier herramienta puede consultar, incluido el editor que uses el próximo año.

La primera diferencia es el costo, y es medible. Los archivos de reglas se inflan porque cumplen una doble función, y las reglas siempre activas se facturan en cada completado. Mover el conocimiento fuera de las reglas y llevarlo a una capa consultable reduce lo que pagas por solicitud, al tiempo que aumenta lo que el agente puede encontrar cuando realmente lo necesita.

La segunda es que el cambio deja de ser de una sola vía. En este momento, si Cursor no se adapta a ti, volver atrás significa otra reconstrucción manual, por lo que la gente se queda con una herramienta que no funciona. Cuando el conocimiento es externo, evaluar un editor durante dos semanas cuesta solo un cambio de configuración.

La tercera es la consistencia del equipo. Un archivo de reglas en el repositorio se comparte; el contexto que escribiste en tu chat de Trae, no. Si tres desarrolladores tienen un modelo mental diferente de por qué la arquitectura se ve así, sus agentes producirán tres tipos diferentes de código, lo cual es el mismo fallo que Cursor olvidando el contexto entre máquinas, solo que distribuido entre personas.

Audita tus modos de reglas en la primera semana

Abre cada .mdc y verifica su modo de activación en comparación con la frecuencia con la que realmente se necesita. Cualquier cosa en Always Apply que no sea una restricción universal debería degradarse. Cursor te ofrece cuatro modos por una razón, y usar solo uno de ellos es la forma en que los archivos de reglas se vuelven costosos silenciosamente.

Mantén el registro de conocimiento en un solo lugar, no en tres archivos

La tentación después de una migración es dispersar notas en archivos README, comentarios y archivos de reglas. Elige un solo hogar para el conocimiento acumulado y dirige todo allí. El conocimiento fragmentado es funcionalmente lo mismo que la falta de conocimiento, porque nada puede recuperarlo todo.

No elimines tu configuración de Trae durante quince días

Conserva .trae/ y tu instalación de Trae hasta que hayas trabajado una semana completa en Cursor, incluyendo una sesión de depuración real. Las brechas de migración nunca aparecen en la primera hora; aparecen la primera vez que necesitas algo que asumiste que se había transferido. La misma precaución se aplica a cualquier cambio de editor, incluyendo pasar a Cursor desde Copilot o llevar las reglas de Cursor a Claude Code.

La migración de Trae a Cursor es una de las más sencillas de editor disponibles: ambos guardan las instrucciones en Markdown, ambos leen un directorio de reglas y ambos se comunican mediante MCP. Divide .trae/project_rules.md en archivos .mdc separados, define los modos de activación deliberadamente en lugar de dejar todo por defecto en Always Apply, mueve las reglas de usuario a la configuración de Cursor y vuelve a conectar tus servidores MCP.

Luego, dedica el esfuerzo ahorrado a la parte que ningún mapeo de archivos cubre. Ninguno de los dos editores almacena lo que te enseñaron tus sesiones, por lo que alguien tiene que escribir las decisiones y los callejones sin salida; y si se escriben en un archivo de reglas siempre activo, pagarás por ellos en cada completado y aun así los perderás en la próxima migración. Una capa de memoria fuera del editor es lo que hace que el contexto sea algo que conservas en lugar de algo que reconstruyes. Ese es, en última instancia, el mismo vacío detrás de Trae olvidando el contexto entre sesiones y Cursor olvidando las sesiones anteriores.