Migrar de WordPress a Movable Type — una guía práctica que merece documentarse precisamente por ir «en sentido contrario»

Este artículo reúne tanto los criterios para decidir si conviene migrar como el procedimiento práctico de migración, dirigido a la persona responsable de un sitio de una pyme o de un despacho profesional construido con WordPress, así como a la empresa de desarrollo que se encargue de la migración.

Cuando se habla de migrar de CMS, casi todos los artículos que se encuentran hablan de «de Movable Type a WordPress». Sin embargo, en la práctica existen casos reales en los que tiene sentido migrar en sentido contrario, de WordPress a Movable Type (o MovableType.net). Precisamente porque va en sentido contrario, hay poca información al respecto, así que este artículo reúne y organiza tanto el criterio de decisión como el procedimiento práctico de la migración.

«Tenemos un sitio hecho con WordPress, pero solo lo actualizamos unas pocas veces al mes. Y aun así, no dejamos de lidiar con los avisos de actualización del núcleo y de los plugins» — es una situación habitual en los sitios de pymes y despachos profesionales.

Cuando el objetivo del sitio es captar clientes y generar confianza, y las actualizaciones se limitan sobre todo a avisos y columnas, lo que se espera del CMS no es tanto capacidad de ampliación como que no dé trabajo y que sea difícil de romper. Este artículo explica los criterios para valorar una migración de WordPress a Movable Type, así como el procedimiento práctico para llevarla a cabo.

Términos empleados en este artículo

Para que también puedan leerlo con facilidad las personas responsables que encargan el trabajo, antes de nada se resumen aquí los términos técnicos.

1. Conclusión

• La migración de WordPress a Movable Type está técnicamente consolidada, y la función de importación de MovableType.net admite archivos de exportación en formato WordPress (XML). Además de las entradas y páginas, también recupera las imágenes y archivos referenciados en el cuerpo del artículo y en los campos personalizados.
• La migración tiene sentido en sitios con frecuencia de actualización baja, pocas personas actualizando y requisitos de ampliación estables. No es adecuada para sitios que implementan funciones dinámicas de membresía o comercio electrónico mediante plugins de WordPress.
• Lo que determina el éxito de la migración no son tanto las diferencias funcionales entre los CMS como el diseño de URL, las redirecciones 301 y la política de sustitución de las funciones de los plugins. Si solo se trasladan los datos sin decidir esto de antemano, se tropieza tanto en el SEO como en la operación diaria.
• Los tipos de contenido personalizados y el XML muy personalizado pueden no cargarse tal cual, por lo que conviene prever horas de conversión y ajuste (así lo indica también el manual oficial).

2. Por qué se produce una migración «en sentido contrario»

WordPress es el CMS más utilizado del mundo, y en sí mismo es una excelente opción. Sin embargo, precisamente por ser un CMS dinámico, conlleva una carga operativa propia.

• No se puede dejar de atender las actualizaciones. Las actualizaciones del núcleo, del tema y de los plugins se producen de forma continua, y dejarlas de lado se convierte directamente en un riesgo. Sobre las vulnerabilidades de los CMS y sus plugins, la IPA (Agencia de Promoción de Tecnología de la Información de Japón) ha emitido avisos repetidos, y los problemas originados en plugins destacan de forma especial.
• Suele faltar una persona responsable. No es raro encontrar sitios que la empresa de desarrollo entregó sin un contrato de mantenimiento posterior, de modo que «nadie pulsa el botón de actualizar».
• Problemas de compatibilidad entre plugins. En configuraciones donde cada actualización provoca que el diseño se rompa o que alguna función deje de funcionar, actualizar en sí mismo empieza a dar miedo, y el abandono se agrava todavía más.

Movable Type es un CMS cuyo funcionamiento básico es la publicación estática: genera de antemano los archivos HTML y los distribuye (también se puede optar por la publicación dinámica cuando sea necesario). Si la página que se devuelve al visitante es un archivo estático, el programa del CMS no se ejecuta en el lado público, lo que reduce la superficie de ataque y los puntos de fallo.

Además, si opta por la versión SaaS, MovableType.net, el proveedor del servicio se encarga de las actualizaciones del núcleo del CMS y de las medidas de seguridad, y el SSL (HTTPS) se puede usar sin coste adicional. Es una configuración que encaja con equipos que quieren dedicar tiempo al contenido del sitio, pero no ocuparse del mantenimiento del CMS.

3. Opciones de destino — Movable Type y MovableType.net

El destino de la migración se divide, a grandes rasgos, en dos opciones.

Para un sitio corporativo o de un despacho profesional gestionado por un equipo pequeño, lo realista es evaluar primero MovableType.net y considerar la versión de software solo si los requisitos no encajan en ella. El flujo de aprobación (solicitud y aprobación) y la función de staging encajan bien con la operación de un despacho profesional que, por ejemplo, quiere publicar solo después de que lo revise el responsable del despacho.

4. Panorama general del proceso de migración

La migración se lleva a cabo en el siguiente orden. El punto clave es situar el inventario de URL (paso 2) antes de la migración de datos (paso 3).

1. Inventario actual — catálogo de páginas, funciones y plugins
2. Diseño de URL — definición de la tabla de correspondencia de URL antiguas y nuevas (mapeo 301)
3. Migración de datos — exportación de WordPress → importación
4. Reconstrucción de plantillas — implementación del diseño y los metadatos
5. Implementación de sustitutos de funciones — formularios, búsqueda, etc.
6. Verificación — cotejo entre lo antiguo y lo nuevo, comprobación real de las redirecciones
7. Publicación — cambio de DNS, envío del sitemap, verificación en Search Console

Hay una razón para colocar el paso 2 (diseño de URL) antes del paso 3 (migración de datos): las reglas de URL impregnan tanto la tabla de correspondencia 301 como los enlaces internos dentro del cuerpo de los artículos. Si primero se cargan los datos y después se decide «al final vamos a cambiar las reglas de URL», no basta con rehacer la tabla de correspondencia 301: hay que revisar uno por uno todos los enlaces a URL antiguas que quedan en el cuerpo de los artículos ya importados, y repetir también la verificación. Por el contrario, si las reglas de URL se fijan de antemano, la migración de datos (paso 3) y la reconstrucción de plantillas (paso 4) se pueden llevar a cabo en paralelo. Entienda este orden como uno en el que cuanto antes se decide algo, menos hay que retroceder después.

5. La práctica de la migración de contenido

5.1. Del lado de WordPress — Exportación

En el panel de administración de WordPress, siga estos pasos (véase la página oficial «Tools Export screen» de WordPress).

1. Abra «Herramientas» → «Exportar» en el menú lateral izquierdo.
2. Seleccione el alcance de la exportación. Si elige «Todo el contenido», las entradas, páginas, comentarios, campos personalizados, términos (categorías, etiquetas), menús de navegación y tipos de contenido personalizados se reúnen en un único archivo.
3. Al pulsar el botón «Descargar archivo de exportación», se guarda un archivo XML en su equipo. Este es el archivo en formato WXR.

Si el archivo resulta demasiado grande, se puede dividir desde esta misma pantalla. Si en lugar de «Todo el contenido» selecciona «Entradas», puede filtrar la exportación por categoría, autor, período (fecha de inicio y fin) y estado. «Páginas» también se puede filtrar por autor, período y estado. En sitios con muchos artículos, lo más seguro es dividir la exportación en varios archivos por período — «2023», «2024»… — e importarlos en orden. También es posible exportar solo la sección «Medios».

5.2. Del lado de MovableType.net — Importación

1. En la barra lateral izquierda del panel de administración, haga clic en «Herramientas» → «Importar».
2. Indique el archivo que desea cargar. Los formatos admitidos son el archivo de exportación de MovableType.net, el formato Movable Type, el formato WordPress y el formato CSV. El XML exportado desde WordPress se puede cargar tal cual como «formato WordPress».
3. Si activa «Importar elementos», el sistema extrae las URL del cuerpo de los artículos y de los campos personalizados, descarga los archivos correspondientes y los incorpora como elementos (imágenes y archivos adjuntos).

El manual oficial detalla varias advertencias que resultan importantes en el trabajo real.

• La carga puede tardar bastante tiempo. El sistema envía un correo de finalización a la dirección registrada cuando termina. No interrumpa el proceso pensando erróneamente que «la pantalla se ha congelado». El manual oficial no especifica un límite de tamaño de archivo ni de número de elementos, pero si el proceso no se completa en un solo intento o tarda demasiado, dividir la exportación por período, como se explica en el apartado 5.1, es una solución práctica.
• El BASENAME del artículo (la cadena que se usa en la URL) solo conserva los caracteres alfanuméricos de un byte cuando el original los contiene. Si coincide con el de otro artículo, se le añade un número. Los sitios que usaban slugs en japonés verán cambiar aquí su URL. Asegúrese de recoger este caso en la tabla de correspondencia de URL antiguas y nuevas del capítulo 6.
• Las páginas web se importan como artículos.

Según el manual oficial, el alcance de la importación es el siguiente.

Cómo corregir la jerarquía de categorías cuando se rompe está descrito con detalle en la página «Importar» del manual oficial. Si se importa en formato Movable Type, reescribiendo los valores de PRIMARY CATEGORY: y CATEGORY: del archivo de exportación en un formato separado por barras, del tipo nombre-de-categoría-raíz/nombre-de-subcategoría, la jerarquía se conserva al importar. En los sitios donde, por necesidades del negocio, resulte imprescindible mantener la jerarquía de categorías, incorpore esta reescritura como un paso más del proceso de migración. El texto original de este procedimiento está en el manual de importación de MovableType.net.

El mismo manual incluye también ejemplos concretos de corrección para los tipos de contenido personalizados. Por ejemplo, reescribir <wp:post_type>portfolios</wp:post_type> como <wp:post_type>page</wp:post_type>. Basta con saber que no hay que quedarse en «no se pudo cargar»: a veces basta con corregir el XML como texto plano para que funcione, y eso ya cambia por completo la estimación del trabajo.

Si el sitio hace un uso intensivo de tipos de contenido personalizados y campos personalizados de WordPress, consulte la explicación oficial de la herramienta de conversión y el procedimiento y clasifique cada tipo de contenido en «se traslada automáticamente», «necesita conversión» o «hay que rehacerlo a mano». Esta tabla de clasificación se convierte directamente en la estimación de la migración.

Además, para los casos con un gran número de artículos o una estructura compleja, existe también un servicio oficial de asistencia a la migración. También hay publicadas unas preguntas frecuentes oficiales sobre la migración a la versión de software de Movable Type.

6. Conservación de las URL y el SEO

La mayoría de las causas por las que una migración de CMS hace perder posicionamiento SEO no están en el tipo de CMS, sino en el manejo de las URL.

La configuración de enlaces permanentes de WordPress (/?p=123, /2024/05/post-name/, /category/post-name/, etc.) normalmente no coincide con la estructura de URL después de la migración. La conservación se lleva a cabo con los siguientes pasos.

1. Inventario completo de URL. Se elabora un listado de todas las URL publicadas, incluidas las de artículos, páginas, categorías, etiquetas y páginas de imágenes (con ayuda de un sitemap o de una herramienta de rastreo).
2. Definición de la tabla de correspondencia con las nuevas URL. Se decide primero la regla de URL posterior a la migración y se elabora la tabla de correspondencia de URL antiguas a nuevas (mapeo 301). Se revisan con prioridad las páginas con más tráfico de búsqueda.
3. Configuración de las redirecciones 301. A las URL que cambien se les configura una redirección permanente (301).
4. Conservación de los elementos dentro de la página. El título, la meta descripción, la estructura de encabezados y los datos estructurados se trasladan de forma deliberada al reconstruir las plantillas. Los elementos que generaba el plugin de SEO se sustituyen, tras la migración, por una implementación en la propia plantilla.
5. Verificación tras la publicación. Se vuelve a enviar el sitemap XML, se supervisa la indexación y los errores en Search Console, y se comprueba de forma real la redirección de las páginas principales (verificando el código de estado).

Este orden — «primero el diseño de URL, después la migración de datos y el diseño visual» — no es exclusivo de las migraciones de CMS, sino un principio general de cualquier renovación de sitio web. En nuestro propio caso de renovación de sitio, lo primero que hicimos tampoco fue el diseño, sino el inventario de URL.

7. Sustitución de las funciones de los plugins — distinguir entre «buscar sustituto» y «dejar de ser necesario»

Al migrar desde WordPress, la lista de plugins puede parecer motivo de preocupación. Sin embargo, si se organiza función por función, la mayoría se puede clasificar en estas tres categorías.

El formulario de contacto es, en particular, la vía vital de un sitio orientado a captar clientes. Es un incidente que ocurre en la práctica: aprovechando la migración, el correo de notificación del formulario deja de llegar. Por eso, antes de publicar, hay que enviar una prueba real y confirmar que funciona. Sobre la falta de entrega de los correos del formulario, hemos reunido información en «Cómo investigar cuando no llegan los correos del formulario de contacto».

8. Resumen — para qué tipo de sitio es adecuado (sitios corporativos de profesionales independientes y equipos pequeños)

A continuación se describe el perfil de sitio para el que resulta adecuada una migración de WordPress a Movable Type (en especial, a MovableType.net).

• Las actualizaciones se centran en avisos, columnas y presentación de logros, y las secciones que se actualizan son de formato fijo
• No hay una persona dedicada a la web y no se puede destinar personal al mantenimiento del CMS
• Como en los sitios de profesionales independientes (asesores fiscales, escribanos, etc.), se quiere intercalar una revisión y aprobación antes de publicar
• No tiene funciones dinámicas como membresía, comercio electrónico o sistemas de reserva (o se pueden externalizar a un servicio externo)
• Pertenece a un sector donde un incidente de seguridad se convierte directamente en un problema de confianza, y se quiere reducir la superficie de ataque

Por el contrario, los sitios que planean seguir utilizando activamente la ampliación mediante plugins, o aquellos en los que las funciones dinámicas son el núcleo del sitio, hacen mejor en quedarse con WordPress (y organizar un sistema de mantenimiento adecuado). La migración no es un fin en sí mismo, sino un medio para equilibrar el sistema operativo con los requisitos del sitio.

Si desea valorar la cuestión desde la estructura general del sitio o el presupuesto, consulte también «Coste de desarrollo de un sitio web para pymes» y «Estructura de la página de servicios para B2B técnico».

Para quienes estén considerando una migración de CMS

Si le preocupa la carga de mantenimiento de WordPress, tampoco es necesario decidir la migración de inmediato. Lo más seguro es empezar por hacer un inventario de las páginas, funciones y plugins del sitio actual, y por organizar qué cambiaría con la migración (qué dejaría de ser necesario y qué habría que rehacer).

KomuraSoft LLC ofrece desarrollo web, que incluye migraciones de CMS, y consultoría técnica, que incluye la organización de la política de migración. Para consultas que empiecen por el inventario de la situación actual, contáctenos a través de nuestra página de contacto.

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Se pueden trasladar los artículos de WordPress a Movable Type tal cual?

El contenido básico, como entradas y páginas, se puede migrar. La función de importación de MovableType.net admite archivos de exportación en formato WordPress (XML) y también recupera las imágenes y archivos referenciados en el cuerpo del artículo y en los campos personalizados. Sin embargo, los tipos de contenido personalizados o los datos muy personalizados pueden no cargarse tal cual y requerir conversión o ajustes manuales. Antes de migrar, es importante distinguir qué contenido depende de las funciones estándar de WordPress y cuál depende de plugins o personalizaciones.

¿Migrar de CMS perjudica el posicionamiento SEO?

Lo que importa no es el tipo de CMS en sí, sino si las URL cambian y si las redirecciones se configuran correctamente. Antes de migrar, elabore un inventario completo de todas las URL, defina la correspondencia con las nuevas URL y configure redirecciones 301 para cada URL que cambie. Si mantiene el título, la meta descripción y la estructura de encabezados, y tras la publicación vuelve a enviar el sitemap XML y revisa Search Console, podrá evitar una caída importante causada por la propia migración. Por el contrario, omitir este trabajo hará perder posicionamiento sin importar qué CMS se elija.

¿Qué ocurre con las funciones que antes gestionaban los plugins de WordPress?

Dado que el mecanismo de plugins en sí no se puede trasladar, se decide un sustituto para cada función por separado. Los formularios de contacto se reconstruyen con la función de formularios de la plataforma de destino o un servicio de formularios externo, los metadatos que generaban los plugins de SEO se implementan en la plantilla, y las entradas relacionadas y las migas de pan también se integran en la plantilla. Por otro lado, los plugins de seguridad y copias de seguridad a menudo dejan de ser necesarios por completo en una arquitectura de publicación estática o SaaS: su función desaparece por sí sola. La clave está en distinguir entre «funciones que necesitan sustituto» y «funciones que simplemente dejan de ser necesarias».

¿Conviene elegir Movable Type o MovableType.net?

Si gestiona usted mismo el servidor y quiere libertad para ampliar el sitio con plugins e integraciones de bases de datos, la versión de software de Movable Type es la adecuada. Si prefiere delegar la gestión del servidor y las actualizaciones del núcleo del CMS para aligerar la operación, la oferta SaaS MovableType.net es más apropiada. Para organizaciones sin personal web dedicado, como el sitio corporativo de una pyme o el sitio de un profesional independiente, es realista empezar evaluando MovableType.net, ya que deja las actualizaciones del núcleo y la seguridad en manos del proveedor del servicio.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.