Migrar de WordPress a Astro: por qué lo estoy haciendo (y cuándo NO deberías)

La semana pasada migré un sitio corporativo real — el del estudio del que hago parte — de WordPress a Astro. No fue un capricho de tecnólogo: fue la conclusión de un mes viendo de cerca lo que le pasa a los WordPress institucionales cuando nadie los cuida.

Estos son los números de esa migración, lo que significa cada uno para una organización como la tuya, y — porque este blog no vende humo — la lista honesta de casos en los que migrar sería un error.

Los números de una migración real

El sitio venía de WordPress con tema comercial de página builder, WooCommerce instalado (con cero productos — solo por si acaso, desde 2021), y componentes duplicados: dos plugins de formularios, tres herramientas de analytics, un plugin de seguridad premium.

	Antes (WordPress)	Después (Astro)
Plugins que actualizar	~40	0
Base de datos que respaldar	1 (con años de tablas huérfanas)	0
Superficie atacable (PHP ejecutándose)	Todo el sitio	Ninguna — archivos estáticos
Hosting	Plan mensual administrado	$0 (hosting estático)
Tiempo de carga	2–4 segundos	Menos de 1
¿Quién actualiza el contenido?	“El de sistemas”	Panel propio, cualquiera del equipo

La última fila es importante y la explico más abajo, porque es la objeción #1 a los sitios estáticos — y ya tiene solución buena.

Qué significa “estático” (sin jerga)

WordPress arma cada página en el momento en que alguien la visita: consulta la base de datos, ejecuta PHP, pasa por 40 plugins, y entrega el resultado. Eso implica que en cada visita hay código ejecutándose que puede fallar, ser lento, o ser atacado.

Un sitio estático se arma una sola vez — cuando publicas un cambio — y lo que se entrega a cada visitante es el resultado final: archivos ya construidos. Como la diferencia entre cocinar el plato frente al cliente cada vez (con la cocina abierta a extraños) y entregar el plato ya emplatado.

Las consecuencias prácticas:

1. Seguridad por diseño, no por plugin. El caso del activador pirata de Wordfence que conté hace unos días es imposible en un sitio estático — no porque haya un mejor candado, sino porque no hay puerta: no hay PHP que ejecutar, no hay base de datos que inyectar, no hay panel wp-admin que forzar.

2. Nada que mantener. Sin plugins no hay actualizaciones pendientes, ni incompatibilidades entre versiones, ni el ciclo de miedo de “si actualizo se daña, si no actualizo me hackean” que describí en el checklist de las 12 señales.

3. Velocidad que Google premia. Los archivos estáticos se sirven desde CDN — el sitio carga desde un servidor cercano al visitante, en milisegundos. Y desde que la búsqueda incluye IAs que citan fuentes, los sitios rápidos, limpios y bien estructurados tienen ventaja medible.

4. Costo de operación cercano a cero. El hosting estático moderno es gratuito o casi para sitios institucionales típicos. El plan mensual de hosting administrado de WordPress — $30 a $100 USD/mes — desaparece.

“¿Y cómo edito el contenido sin WordPress?”

Esta es la objeción legítima. La respuesta corta: un panel de contenido separado del sitio.

En la migración que hice, el equipo edita textos, proyectos y personas desde un panel web — igual de fácil que WordPress — y al darle “publicar” el sitio se regenera en un minuto. La diferencia arquitectónica es crucial: el panel y el sitio viven separados. Si el panel fallara, el sitio sigue en pie, intacto, porque no depende de él para existir. En WordPress, el editor y el sitio son la misma cosa: si uno cae, caen los dos.

Cuándo NO migrar (léelo antes de escribirme)

Migrar no es la respuesta universal. Quedarte en WordPress es la decisión correcta si:

1. Tu operación ES WordPress. Tienda WooCommerce activa con cientos de pedidos, membresías con pagos recurrentes, LMS con cursos en marcha. Ahí WordPress no es el sitio: es el sistema de negocio. Migrar eso es otro proyecto, con otro presupuesto, y a veces no vale la pena.

2. Publicas mucho y muy seguido con un equipo grande. Si tienes 15 editores publicando a diario con flujos de revisión, el editor de WordPress sigue siendo difícil de superar. (Para un blog como este, o noticias institucionales mensuales, el panel separado sobra y alcanza.)

3. Tu sitio actual funciona, está mantenido y no te cuesta dolores. Si tienes quien lo cuide, respaldos probados y plugins al día — no arregles lo que no está roto. Guarda este artículo para cuando eso cambie.

4. El presupuesto solo alcanza para “moverlo”. Una migración mal hecha — sin redirecciones, sin migrar el SEO, sin resolver la edición de contenido — es peor que no migrar. Hecho a medias, pierdes lo mejor de ambos mundos.

Cuándo SÍ es urgente

Al revés, la migración sube al primer lugar de la lista cuando:

• El sitio es informativo/corporativo (quiénes somos, servicios, proyectos, contacto, blog) y vive en WordPress solo por inercia
• Ya nadie actualiza los plugins, o el “webmaster” ya no está — cada mes que pasa el riesgo crece en silencio
• Encontraste componentes pirata o abandonados (si no lo has revisado: guía de auditoría aquí)
• Pagas hosting administrado por un sitio que cambia unas pocas veces al año
• Tu sitio se cayó en un momento crítico y el diagnóstico dio como el de este postmortem: memoria agotada, plugins de hace 5 años, deuda acumulada

Si marcaste dos o más, el costo de migrar ya es menor que el costo de quedarte — solo que uno se paga una vez y el otro se paga en riesgo, cada mes.

Cómo se ve una migración bien hecha

Para que tengas la referencia al cotizar (mía o de quien sea):

1. Inventario primero: qué contenido existe de verdad, qué se migra, qué se archiva. En mi caso: 16 páginas resultaron ser 8 reales, un WooCommerce vacío se eliminó, y unas FAQs de relleno (“lorem ipsum” en producción desde 2022) se descartaron
2. El diseño se conserva o se mejora — nunca se pierde: colores, logos, identidad. La migración no debe verse como “otro sitio”
3. Redirecciones de todas las URLs viejas: el SEO acumulado durante años se transfiere, no se abandona
4. Panel de contenido para que el equipo edite sin tocar código
5. El WordPress viejo queda congelado unos días como respaldo — revertir debe ser posible en minutos
6. Solo cuando el nuevo lleva días estable: se cancela el hosting anterior

Tiempo real de mi última migración con todo lo anterior: tres días de trabajo. No los tres meses que te van a cotizar los que cobran por hora de reunión.

---

¿Tu sitio institucional está en la lista de “urgente”? Escríbeme — reviso tu caso concreto y te digo con franqueza si te conviene migrar o quedarte. A veces la respuesta correcta es la que no me deja factura.