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

Al buscar «migración de CMS», la mayoría de los artículos que se encuentran tratan sobre el paso de Movable Type a WordPress. Sin embargo, en la práctica, migrar en sentido contrario —de WordPress a Movable Type (o MovableType.net)— resulta a veces una decisión perfectamente racional. Precisamente porque hay poca información sobre este sentido contrario, este artículo reúne tanto los criterios de decisión como el procedimiento práctico de migración.

«Tenemos un sitio hecho con WordPress, pero solo lo actualizamos unas pocas veces al mes. Aun así, no dejamos de perseguir las notificaciones de actualización del núcleo y de los plugins» — una situación familiar para pequeñas y medianas empresas y despachos profesionales.

Cuando el objetivo de un sitio es generar consultas y construir confianza, y las actualizaciones consisten sobre todo en avisos y columnas, lo que ese tipo de sitio necesita de un CMS no es capacidad de ampliación, sino poco mantenimiento y resistencia a romperse. Este artículo repasa los criterios para valorar una migración de WordPress a Movable Type, así como el procedimiento real de migración.

1. Primero, la conclusión

• La migración de WordPress a Movable Type está bien establecida técnicamente: la función de importación de MovableType.net admite archivos de exportación en formato WordPress (XML). Importa no solo entradas y páginas, sino también imágenes y archivos referenciados en el texto y en los campos personalizados.
• La migración tiene sentido para sitios con baja frecuencia de actualización, pocas personas encargadas de actualizar y requisitos de ampliación estables. No es adecuada para sitios construidos en torno a funciones dinámicas como áreas de socios o comercio electrónico implementados mediante plugins de WordPress.
• Lo que determina el éxito de una migración no son las diferencias funcionales entre CMS, sino el diseño de URL, las redirecciones 301 y la estrategia de sustitución de las funciones de los plugins. Si solo se trasladan los datos sin haber decidido estos aspectos de antemano, surgirán problemas tanto en el SEO como en el trabajo diario.
• Los tipos de contenido personalizados y el XML muy personalizado pueden no importarse limpiamente tal cual, así que reserve tiempo para la conversión y el ajuste manual (esto se indica explícitamente también en el manual oficial).

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

WordPress es el CMS más utilizado del mundo, y es en sí mismo una excelente opción. Por otro lado, al ser un CMS dinámico, conlleva una carga operativa propia.

• El trabajo de actualización nunca se detiene. Las actualizaciones del núcleo, los temas y los plugins ocurren de forma continua, y descuidarlas ya es en sí un riesgo. El IPA (agencia japonesa de promoción de tecnologías de la información) ha emitido repetidas advertencias sobre vulnerabilidades de CMS y plugins, con los problemas derivados de plugins especialmente destacados.
• A menudo el sitio termina sin nadie a cargo. No es raro que un sitio entregado por una agencia se quede sin contrato de mantenimiento, dando lugar a un sitio en el que «nadie ha pulsado nunca el botón de actualizar».
• Problemas de compatibilidad entre plugins. En configuraciones donde cada actualización rompe el diseño o desactiva alguna función, actualizar se vuelve algo temido, lo que acelera aún más el abandono.

Movable Type es un CMS construido en torno a la publicación estática: genera el HTML de antemano y lo sirve tal cual (también se puede optar por publicación dinámica si es necesario). Si las páginas que se devuelven a los visitantes son archivos estáticos, no hace falta que ningún programa del CMS se ejecute en el lado público, lo que reduce tanto la superficie de ataque como los puntos de fallo.

Al optar por la oferta SaaS MovableType.net, se va un paso más allá: el proveedor del servicio se encarga de las actualizaciones del núcleo del software y de la seguridad, y el SSL (HTTPS) está incluido sin coste adicional. Es una configuración adecuada para una organización que quiere seguir invirtiendo en el contenido del sitio sin querer ocuparse del mantenimiento del CMS.

3. Destinos de la migración — Movable Type frente a MovableType.net

Hay, en líneas generales, dos destinos posibles para la migración.

Para un sitio corporativo o de un profesional independiente gestionado por un equipo pequeño, es realista empezar evaluando MovableType.net y considerar la versión de software solo si los requisitos superan lo que esta ofrece. El flujo de aprobación (solicitud/aprobación) y el entorno de pruebas encajan bien con la forma de trabajar de los despachos profesionales, por ejemplo, «publicar solo tras la revisión del responsable del despacho».

4. Visión general del proceso de migración

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

1. Inventario del estado actual — listado de páginas, funciones y plugins
2. Diseño de URL — definición de la correspondencia entre 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. Sustitución de funciones — formularios, búsqueda, etc.
6. Verificación — comparación entre lo antiguo y lo nuevo, medición de redirecciones
7. Publicación — cambio de DNS, envío del sitemap, verificación en Search Console

5. Los aspectos prácticos de la migración de contenido

En el lado de WordPress, utilice la función de exportación del panel de administración para generar un XML (formato WXR). En el lado de MovableType.net, cargue ese archivo desde la pantalla de la herramienta de importación. Según el manual oficial, el alcance de lo que se importa es el siguiente:

Si utiliza mucho los tipos de contenido personalizados o los campos personalizados de WordPress, consulte la herramienta de conversión oficial y su guía de procedimiento y clasifique cada tipo de contenido a migrar en «se migra automáticamente», «requiere conversión» o «hay que reconstruirlo manualmente». Esta clasificación se convierte, de hecho, en la estimación de la migración.

Tenga en cuenta que, para sitios con muchos artículos o una estructura compleja, también existe una ventanilla oficial de asistencia para la migración. Para la migración a la versión de software de Movable Type también se ha publicado unas preguntas frecuentes oficiales.

6. Conservar las URL y el SEO

La mayoría de las causas por las que una migración de CMS perjudica el rendimiento SEO no tienen que ver con el tipo de CMS, sino con cómo se gestionan las URL.

Los ajustes de enlaces permanentes de WordPress (/?p=123, /2024/05/post-name/, /category/post-name/, etc.) normalmente no coinciden con la estructura de URL tras la migración. Consérvelas siguiendo estos pasos:

1. Inventaríe todas las URL. Liste todas las URL publicadas —entradas, páginas, categorías, etiquetas, páginas de imágenes— con ayuda de un sitemap o una herramienta de rastreo.
2. Defina la correspondencia con las nuevas URL. Decida primero las reglas de URL tras la migración y luego construya una tabla de correspondencia de URL antigua a nueva (mapeo 301). Revise primero las páginas con más tráfico de búsqueda.
3. Configure las redirecciones 301. Aplique redirecciones permanentes (301) a cada URL que cambie.
4. Conserve los elementos de la página. El título, la meta descripción, la estructura de encabezados y los datos estructurados deben conservarse de forma deliberada durante la reconstrucción de plantillas. Los elementos que antes generaban los plugins de SEO se sustituyen, tras la migración, por una implementación en la plantilla.
5. Verifique después de la publicación. Vuelva a enviar el sitemap XML, supervise la indexación y los errores en Search Console, y mida las redirecciones en las páginas principales (comprobando los códigos de estado).

Este principio —«primero el diseño de URL, después la migración de datos y el diseño»— se aplica a las renovaciones de sitios en general, no solo a las migraciones de CMS. En nuestro propio caso de estudio de renovación de un sitio, lo primero que hicimos no fue el diseño, sino el inventario de URL.

7. Sustituir las funciones de los plugins — separar «buscar sustituto» de «ya no es necesario»

Al migrar desde WordPress, la lista de plugins puede parecer motivo de inquietud. Pero al clasificarlos función por función, la mayoría se agrupa en tres categorías.

El formulario de contacto, en particular, es el elemento vital de un sitio orientado a captar clientes potenciales. Los casos en los que los correos de notificación dejan de llegar en silencio tras una migración ocurren de verdad, así que envíe siempre una prueba real antes de la publicación. Hemos recopilado cómo investigar los correos de formularios no entregados en «Cómo investigar cuando los correos del formulario de contacto no llegan».

8. ¿Para qué tipo de sitio es adecuado? — despachos profesionales y sitios corporativos gestionados por equipos pequeños

En resumen, este es el perfil del sitio para el que una migración de WordPress a Movable Type (especialmente MovableType.net) suele ser adecuada:

• Las actualizaciones consisten sobre todo en avisos, columnas y casos de éxito, y el trabajo de actualización es bastante rutinario
• No hay personal web dedicado, y nadie puede dedicar tiempo al mantenimiento del propio CMS
• Como en los sitios de contables, notarios y otros profesionales independientes, se desea un paso de revisión/aprobación antes de publicar cualquier cosa
• El sitio no tiene funciones dinámicas como sistemas de socios, comercio electrónico o reservas (o estas pueden externalizarse a un servicio externo)
• Es un sector en el que un incidente de seguridad se convierte directamente en un problema de confianza, y se desea reducir la superficie de ataque

Por el contrario, si tiene previsto seguir ampliando activamente el sitio mediante plugins, o si la funcionalidad dinámica es el núcleo del sitio, permanecer en WordPress (y establecer una estructura de mantenimiento adecuada) es la opción más sensata. La migración no es un fin en sí misma, sino una herramienta para equilibrar su capacidad operativa con los requisitos del sitio.

Si desea plantearse esto en términos de la estructura general del sitio y los costes, consulte también «Costes de desarrollo de sitios web para pymes» y «Estructura de páginas de servicio para B2B técnico».

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

Si le preocupa la carga de mantenimiento de WordPress, no es necesario decidir la migración de inmediato. El punto de partida seguro es simplemente inventariar las páginas, funciones y plugins de su sitio actual, y determinar qué cambiaría con la migración: qué dejaría de ser necesario y qué habría que reconstruir.

KomuraSoft LLC ofrece servicios de desarrollo web que incluyen la migración de CMS, así como consultoría técnica para ayudar a definir la estrategia de migración. Si desea comenzar con un inventario de su sitio actual, póngase en contacto 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.