Migración de contenido a WordPress enterprise, mapeada antes de mover nada

Distinto alcance, mismo proyecto. La página de migración a WordPress cubre la decisión y el proyecto: el caso de negocio para dejar una plataforma heredada, los plazos, las integraciones y la gobernanza.

Esta página cubre un frente de trabajo dentro de ese programa, la parte donde el contenido efectivamente se mueve. Mapeo, transformación, importación, redirecciones y validación.

Si todavía están decidiendo si cambiar de plataforma, empiecen por ahí. Si la decisión ya está tomada y están resolviendo qué pasa con doce mil registros, están en el lugar correcto.

Tres insumos: un inventario de lo que existe, la arquitectura destino y una decisión editorial sobre qué vale la pena llevarse. El mapeo registra una decisión por cada tipo de objeto heredado:

• Se mueve tal cual. El modelo destino tiene un equivalente y los campos coinciden.
• Se transforma. El contenido pasa a ser otro tipo, o sus campos se dividen, se combinan o cambian de tipo para encajar en el modelo nuevo.
• Se deprecia. Se archiva en lugar de migrarse, casi siempre porque hace años que nada lo referencia.

Depreciar es la decisión que los equipos posponen, y la que más reduce el costo de todo lo que viene después. Migrar contenido muerto significa pagar por moverlo, por validarlo y por mantenerlo.

Depende de la forma del origen, y lo definimos al principio porque revertir esa elección a mitad de camino sale caro.

Dos caminos generales. Una herramienta de importación estándar resuelve las formas comunes, XML, CSV y JSON, con mapeo visual de campos y corridas repetibles. Un pipeline a medida, PHP, SQL o una capa ETL sobre la REST API, es lo que necesitan los esquemas inusuales y los orígenes multisistema.

La mayoría de las migraciones enterprise usan los dos: la herramienta para el grueso, lógica a medida para las partes que no encajan. El tooling específico lo nombramos en el plan de migración y no acá, porque la respuesta correcta cambia con el origen y con lo que tu equipo vaya a mantener después.

Las redirecciones siguen la misma lógica. Dentro de WordPress quedan editables por tu equipo, que es lo que prefieren los editores. Pasadas las decenas de miles de reglas, las reglas a nivel servidor rinden mejor y las movemos ahí.

El mapeo de URLs pasa antes de que se mueva nada. Cada URL heredada indexada se empareja con un destino y se clasifica: 301 para una mudanza permanente, 302 solo donde el destino es realmente temporal.

Una vez implementado, el mapa se rastrea para confirmar la cobertura y detectar cadenas, donde una redirección apunta a otra. Inofensivas de a una, un problema de crawl budget en conjunto.

Durante el cutover miramos la cobertura en Search Console en lugar de esperar los reportes de tráfico. La misma disciplina, contada desde el lado del buscador, está en nuestra página de SEO enterprise.

Sí, y la mayoría de los equipos no tiene alternativa.

Dos opciones, se elige por proyecto. Congelar las actualizaciones del contenido heredado durante una ventana definida antes del cutover, que es lo más simple cuando la ventana es corta. O seguir publicando y correr importaciones incrementales, donde el pipeline vuelve a correr sobre todo lo creado o editado desde la carga anterior.

Las importaciones incrementales son la razón por la que configuramos las importaciones como trabajos repetibles desde el primer día. Hacer que un script de una sola pasada se pueda volver a correr, ya en la semana del lanzamiento, es la forma típica de que una migración se atrase.