Plain text ganó. Migré mis notas de Notion a Markdown y perdí más de lo que esperaba

Una libreta escolar de 48 hojas es básicamente indestructible. La podés mojar, doblar, tirar, prestarla, llevarla a otro país, abrirla en 30 años. No necesita WiFi, no te pide que upgrades el plan, no "migra" tus datos a un nuevo formato sin avisarte. Y si alguien te roba la libreta, sabés exactamente qué perdiste.

Plain text es eso. Un .md es una libreta. Notion es un edificio inteligente con sensores en cada puerta.

El hilo de Hacker News "Plain text has been around for decades and it's here to stay" llegó a 99 puntos la semana pasada y me generó una incomodidad que no supe nombrar de inmediato. No porque esté en desacuerdo — estoy bastante de acuerdo. Sino porque yo tenía 1.847 páginas en Notion y no había movido un dedo.

Así que lo hice. Tres días. Script propio. Resultado incómodo.

Migrar Notion a Markdown plain text: el proceso real, sin romantizar

Notion tiene una función de exportación oficial. Exportás todo como Markdown + CSV, te baja un .zip, listo. En la teoría.

En la práctica, el zip que me bajé tenía esta estructura:

Cada carpeta con un UUID pegado al nombre. Cada archivo .md con bloques de propiedades rotas, imágenes referenciadas como Untitled abc123.png y links internos que apuntan a https://www.notion.so/UUID-largo — o sea, links muertos si no estás logueado.

Escribí un script para limpiar eso:

#!/bin/bash
# limpiar-notion-export.sh
# Renombra carpetas sacando los UUIDs de Notion
# y normaliza nombres a kebab-case

find . -type d | while read dir; do
  # Patrón: nombre con UUID al final (32 chars hex)
  nuevo=$(echo "$dir" | sed 's/ [a-f0-9]\{32\}$//' | tr ' ' '-' | tr '[:upper:]' '[:lower:]')
  if [ "$dir" != "$nuevo" ]; then
    mv "$dir" "$nuevo" 2>/dev/null
  fi
done

# Limpiar referencias a imágenes huérfanas en los .md
find . -name "*.md" -exec sed -i \
  '/!\[.*\](Untitled.*\.png)/d' {} \;

echo "Listo. Revisá manualmente los links internos."

El echo del final es la parte honesta del script. Los links internos — referencias entre páginas de Notion — son irrecuperables de forma automática. Tenés que revisarlos a mano o perderlos.

Yo tenía 214 links internos. Recuperé manualmente 31. Los otros 183 quedaron como texto plano sin destino.

Lo que realmente perdí (no era lo que pensaba)

Antes de empezar asumí que iba a extrañar las databases, los calendarios, las vistas kanban. Tenía razón en parte. Pero lo que más me dolió fue algo más tonto.

1. El grafo de relaciones

En Notion tenía una database de proyectos relacionada con una database de snippets de código relacionada con una database de decisiones de arquitectura. Cada fila podía tener Relation hacia otra tabla. Era mi grafo de conocimiento privado.

En Markdown, ese grafo no existe. Podés simular relaciones con links [[doble corchete]] si usás Obsidian. Pero si usás Zed, VSCode o cat, esos links son texto. El grafo sólo existe si el editor lo lee.

Mi tesis sobre esto: no perdí el grafo, nunca lo tuve. Lo tenía Notion. Yo era usuario de algo que Notion construyó sobre mis datos.

2. El historial de versiones

Notion guarda historial. Markdown puro no. Para tener historial en plain text necesitás Git — lo que es técnicamente superior pero agrega fricción brutal para notas rápidas de las 11pm.

Terminé con esto:

# alias en mi .zshrc para commitear notas rápido
# sin pensar en mensajes de commit
alias nota-save='cd ~/notas && git add -A && git commit -m "$(date +%Y-%m-%d\ %H:%M)" && cd -'

Funciona. Pero es fricción que Notion absorbía en silencio. Honestidad: lo que perdí acá fue comodidad, no capacidad.

3. Las imágenes embebidas de terceros

Tenía screenshots pegados directamente en Notion. Diagramas de arquitectura hechos con el editor interno. Tablas complejas con fórmulas.

Las tablas se exportan como Markdown tables — bien. Las fórmulas, mal: se exportan como texto plano con el resultado calculado al momento del export, no como fórmula viva.

Los screenshots embebidos sobreviven si los subiste vos. Si usaste copy-paste directo desde el clipboard — y yo lo hacía todo el tiempo — Notion los guardó en sus CDN con URLs que ahora son privadas. Perdí unas 40 imágenes.

Lo que NO perdí y esperaba perder:

• Velocidad de escritura — igual o mejor en nvim
• Búsqueda — grep -r "término" ~/notas/ es más rápido que Notion search
• Acceso offline — infinitamente mejor
• Privacidad — datos propios, servidor propio, cero telemetría

Y acá viene la incomodidad real.

Mi tesis: plain text es la respuesta correcta a la pregunta equivocada

El post de HN celebra plain text como si fuera una victoria ideológica. Y entiendo el impulso — después de lo que Notion expuso con los emails de editores hace unas semanas, la migración parece obvia.

Pero yo noté algo durante los tres días de migración: usaba Notion principalmente para sentirme organizado, no para estar organizado.

El dashboard bonito, las vistas kanban, los íconos de emoji por página — eran una interfaz de productividad que me daba la sensación de control. Cuando migré a Markdown, la sensación desapareció. Pero los proyectos siguieron avanzando exactamente igual.

Entonces la pregunta correcta no es "¿plain text o Notion?". La pregunta es: ¿para qué usás realmente tu sistema de notas?

Si lo usás como base de conocimiento técnico con búsqueda, versionado y acceso offline: plain text gana sin discusión.

Si lo usás como herramienta de colaboración con un equipo, con bases de datos relacionales y formularios compartidos: Notion sigue siendo superior.

Si lo usás para sentirte organizado: el problema no es la herramienta.

Yo caía en las tres categorías al mismo tiempo. La migración me obligó a separar esas capas.

Errores comunes al migrar Notion a Markdown

Error 1: Exportar todo y asumir que está limpio

El export de Notion es un punto de partida, no un destino. Los UUIDs en nombres de carpeta, los links rotos y las imágenes huérfanas son trabajo manual inevitable. No existe script que lo resuelva todo.

Error 2: Replicar la estructura de Notion en carpetas

Notion te tienta a tener jerarquías profundas: Trabajo > Proyectos > Backend > 2025 > Q2 > Sprint 3. En plain text eso se vuelve un infierno de navegación. La alternativa que funcionó para mí: estructura plana + tags en el frontmatter YAML + grep.

---
# frontmatter en cada nota - indexable con grep o fzf
tags: [backend, railway, deploy]
fecha: 2025-07-14
proyecto: api-gateway
---

## Deploy en Railway — problema con variables de entorno

...

Con grep -r "railway" ~/notas/ --include="*.md" -l encontrás todo en menos de un segundo.

Error 3: Buscar el "Obsidian vs plain text puro" en el primer día

Obsidian agrega una capa de features encima de los .md. Es la solución más popular. Pero meterse en su ecosistema de plugins el día uno de la migración es ruido. Yo usé nvim durante dos semanas antes de decidir si necesitaba algo más. La respuesta fue: casi nada.

Error 4: Ignorar la seguridad del repositorio

Mis notas tienen snippets de configuración, decisiones de arquitectura, nombres de servicios internos. Meterlas en un repo Git privado en GitHub está bien — pero es datos propios en infraestructura ajena, igual que Notion. Si la privacidad es el driver de la migración, el repositorio tiene que ser local o en un VPS propio. Esto conecta directo con los problemas de superficie de confianza que analicé en el post sobre supply chain attacks: el eslabón débil no siempre es el software, a veces es dónde vivén los datos.

Error 5: Migrar todo de una

Migré 1.847 páginas de golpe. Fue un error. El 60% de esas páginas no las abrí en el último año. La estrategia correcta: exportar primero lo activo, ver si el flujo funciona, y después decidir qué del archivo vale la pena mover.

FAQ: Migrar Notion a Markdown plain text

¿Puedo migrar Notion a Markdown sin perder nada?

No. La exportación oficial de Notion preserva el texto y las tablas básicas, pero los links internos entre páginas, las imágenes pegadas desde el clipboard, las fórmulas de bases de datos y las relaciones entre tablas no tienen equivalente directo en Markdown plano. Podés recuperar la mayoría del contenido textual, pero el grafo de relaciones y las funcionalidades de base de datos se pierden. La pregunta honesta es si esas funcionalidades las estabas usando o sólo estaban ahí.

¿Qué herramienta uso para leer Markdown después de migrar?

Depende de qué necesités. Para escritura técnica y velocidad: nvim con el plugin render-markdown.nvim que renderiza en terminal. Para algo más visual con grafo de links: Obsidian. Para integración con el flujo de desarrollo: VSCode o Zed tienen preview nativo. Yo terminé con nvim para el 90% y Obsidian para explorar el grafo cuando necesito ver conexiones.

¿Vale la pena migrar si trabajo en equipo?

Probablemente no, o no del todo. Plain text brilla como base de conocimiento personal y técnico. Para colaboración en tiempo real, formularios compartidos y bases de datos con permisos por usuario, Notion o Confluence siguen siendo más prácticos. Lo que sí vale la pena: separar las notas personales (plain text) de la documentación colaborativa (Notion/Confluence). No son mutuamente excluyentes.

¿Cómo manejo el versionado sin el historial de Notion?

Git. Sin excusas. Un git commit con fecha y hora como mensaje es suficiente para notas personales. Si querés algo más amigable, git-journal o el alias que mostré antes funcionan bien. El costo es fricción inicial; el beneficio es historial offline, branching para experimentos y diff legible. Notion cobraba por el historial en planes superiores; con Git es gratis y más potente.

¿Dónde guardo las imágenes y los adjuntos?

Depende de la cantidad. Para pocos archivos: carpeta /assets al lado de cada nota o sección. Para muchos: un storage propio (Cloudflare R2, Backblaze B2, o simplemente un directorio en un VPS) y referencias con paths relativos o URLs propias. Lo que no recomiendo: seguir dependiendo de las URLs de Notion CDN — esas URLs son privadas y expiran o cambian sin aviso.

¿Qué pasa con las databases de Notion — hay equivalente en plain text?

No hay equivalente exacto. Lo más cercano es frontmatter YAML en cada archivo + un script que los indexa. Con fzf, ripgrep y un script de bash que parsea el YAML podés construir algo funcional en una tarde. Proyectos como nb o zk formalizan ese patrón. Pero si tu uso de bases de datos en Notion era intenso — relaciones entre tablas, rollups, formularios — vas a extrañarlo. No hay forma de endulzar eso.

Conclusión: me quedé con plain text, pero con los ojos abiertos

Tres semanas después de la migración, mis notas técnicas viven en ~/notas/, versionadas con Git, editadas en nvim, buscadas con ripgrep. El flujo es más rápido para escribir y buscar. La privacidad es real, no prometida.

Pero no voy a romantizarlo: perdí cosas. Perdí 183 links internos. Perdí 40 imágenes. Perdí el grafo de relaciones que Notion mantenía. Perdí la sensación de tener un dashboard bonito.

Lo que gané fue claridad sobre qué usaba realmente y qué era decoración de productividad.

Mi postura final, sin suavizar: plain text es la infraestructura correcta para conocimiento técnico personal. Es a las notas lo que Docker es al deployment — portable, predecible, sin dependencias ocultas. Ya escribí sobre cómo los agentes async generan problemas de observabilidad que son invisibles hasta que los medís (acá el análisis de mis logs); el mismo principio aplica acá: si no podés leer tus datos con cat, no sabés realmente qué tenés.

Lo que no es plain text: la respuesta a la pregunta de si estás organizado. Eso es otra conversación, y no tiene que ver con el formato del archivo.

Si Notion te genera incomodidad después de lo que vimos con la privacidad, migrá. Pero hacelo con expectativas reales, no con la fantasía de que plain text resuelve el problema de raíz. El problema de raíz sos vos y qué querés hacer con ese conocimiento.

Lo mismo que me pasó con TypeScript en 2018: la resistencia era mía, no del lenguaje. Pero una vez que lo adoptás por las razones correctas, no volvés atrás.

¿Estás en el medio de una migración similar? ¿O convencido de que Notion vale cada centavo? Me interesa saber qué perdiste vos — o qué encontraste del otro lado.