Migrar de Word a Markdown: la guía completa
Migrar documentos de Word a Markdown es en gran parte mecánico, pero los fallos son predecibles y baratos de prevenir. Todos ellos se remontan a tratar la conversión como un único paso mágico en lugar de una pequeña canalización con algunas decisiones dentro.
Esta guía recorre esas decisiones en orden: cuánto estás migrando realmente, qué sobrevive a la conversión y qué no, cómo viajan las notas al pie, las tablas y las fórmulas, y cómo terminar con un archivo que tu sitio estático o wiki acepta a la primera.
Define el alcance antes de convertir
Un único documento vivo y un archivo de diez años son proyectos distintos. Para un documento, el objetivo es una conversión fiel que puedas pulir a mano en una tarde. Para un archivo, el objetivo pasa a ser la repetibilidad: un mismo conjunto de opciones aplicado con coherencia, con personas revisando una muestra en lugar de cada archivo.
En ambos casos, empieza con una muestra. Convierte dos o tres documentos representativos —los de peores tablas y más figuras— e inspecciona el resultado de cerca. La muestra te dice qué opciones importan y cuánta limpieza necesitará el resto de la pila, antes de comprometerte con la ejecución completa.
Qué se convierte limpiamente y qué no
Los estilos de título reales de Word se convierten en encabezados Markdown, las tablas simples en tablas, las notas al pie en notas al pie, y las imágenes incrustadas se extraen como archivos reales. El contenido que vive en el flujo normal del documento se transfiere bien, y eso es la mayor parte de lo que realmente es un documento típico.
Las excepciones se agrupan en los bordes. El formato aplicado directamente, como líneas en negrita que fingen ser títulos, no se convierte en estructura: aplica primero estilos de título reales en Word. Los cambios controlados se convierten como si cada cambio hubiera sido aceptado, así que resuelve las revisiones antes de convertir si el texto eliminado te importa. Los comentarios, cuadros de texto y formas flotantes no se transfieren con fiabilidad; su contenido debe moverse al flujo principal o capturarse por separado.
Las notas al pie viajan contigo
Las notas al pie de Word son una de las sorpresas agradables. Pandoc las lee y la salida Markdown usa sintaxis de notas real: cada marca en el texto se convierte en una referencia entre corchetes con un acento circunflejo antes del número, y todas las definiciones se reúnen al final del documento, enlazadas de vuelta a sus marcas.
Dos cosas aún merecen una revisión. Las notas que se referencian entre sí, o que contienen tablas o imágenes, pueden salir en un orden o forma distintos del original. Y las notas al final se convierten igual que las notas al pie, que en Markdown suele ser lo que quieres de todos modos.
Las tablas y sus límites
Activa la opción GFM cuando el destino sea GitHub, Obsidian o la mayoría de los wikis: las tablas simples se convierten en tablas de tubería (pipe tables): una fila de encabezado, una línea separadora y una fila por línea. Ese formato se renderiza en todas partes y sigue siendo legible como texto plano.
El límite es estructural. Las celdas combinadas, las celdas con varios párrafos y las tablas anidadas no tienen representación en tablas de tubería, y Pandoc recurre a dialectos de Markdown que esas plataformas ignoran. La solución honesta está aguas arriba: descombina y aplana las tablas complicadas en Word, o acepta que algunas necesitarán retoques manuales tras la migración.
Las matemáticas se convierten en LaTeX
Las ecuaciones escritas con el editor de ecuaciones de Word se almacenan como matemáticas estructuradas, y Pandoc las convierte en lugar de descartarlas. La salida Markdown envuelve las fórmulas en línea con delimitadores de signo de dólar y coloca las ecuaciones destacadas en sus propias líneas; el formato de salida LaTeX emite entornos matemáticos nativos para las canalizaciones de renderizado que los esperan.
Tras la conversión, busca los dos puntos débiles: fórmulas en línea que Word mostraba de forma ambigua, y cualquier cosa pegada en Word como imagen hace años, que ahora es una imagen, no matemáticas. Esas hay que reescribirlas, y saberlo antes de empezar la migración mantiene el calendario honesto.
Una estrategia de imágenes predecible
Cada imagen incrustada se extrae a una carpeta media junto al archivo convertido, con los nombres que asignó el paquete docx: image1.png y sus hermanos. El Markdown referencia esas rutas relativas, y una descarga ZIP entrega ambos juntos, manteniendo cada documento convertido como un par autocontenido.
Decide antes de la ejecución si los documentos conservan sus propias carpetas media o se fusionan en una carpeta assets compartida. Mantenerlas separadas es seguro y automático; fusionar exige renombrar con prefijos significativos y actualizar las referencias. Lo que debes evitar es descubrir la colisión después de que varios image1.png ya se hayan sobrescrito entre sí.
Front matter para tu sitio estático
Los generadores de sitios estáticos como Hugo y Jekyll esperan front matter YAML al inicio de cada archivo: title, author, date. El conversor puede emitir ese bloque a partir de las propiedades del documento guardadas en el docx, de modo que los archivos llegan ya con metadatos en lugar de tener que escribirlos después.
Eso solo funciona si las propiedades son reales. Los archivos de Word convertidos en masa desde formatos antiguos suelen tener el campo Title vacío y un creador que es la cuenta de un exempleado. Dedicar diez minutos en Word antes de la ejecución, rellenando la información del archivo de cada documento, es la diferencia entre un front matter útil y marcadores de posición.
La pasada de migración por lotes
Una vez calibradas las opciones con la muestra, la ejecución masiva transcurre sin sobresaltos. Añade la carpeta de archivos docx al conversor de este sitio, deja que la cola procese cada uno con su propio estado y descarga el ZIP. La salida por lotes da a cada documento su propio subdirectorio, así que las imágenes de un trabajo nunca pueden tapar las de otro.
Conserva los docx originales hasta que la migración quede aprobada. Son la fuente de verdad de todo lo que la conversión suavizó o dejó caer, y volver a ejecutar con opciones ajustadas siempre es más barato que reconstruir de memoria un detalle perdido.
Una lista de verificación para la migración terminada
Para cada documento, verifica seis cosas: la jerarquía de encabezados desciende sin saltos, cada referencia de imagen resuelve a un archivo que existe, las tablas se renderizan en la plataforma de destino, las notas al pie aparecen como notas reales, las fórmulas se renderizan donde deben y los campos del front matter están rellenos, no vacíos.
Por último, ejecuta un documento de principio a fin en el destino real: compila el sitio estático, previsualiza la página del wiki, abre la nota en Obsidian. Una migración está terminada cuando el sistema de destino renderiza los archivos, no cuando el conversor informa de éxito. Esa última comprobación lleva minutos y atrapa todo lo que las comprobaciones a nivel de archivo pasaron por alto.