Publicado
Hace poco migré el sitio web de una empresa desde Sitefinity CMS a un nuevo stack: Astro para el front end, Sanity como CMS headless y Vercel para el hosting. Me tomó unos pocos días, y gran parte del desarrollo lo hice con Claude Opus 5.5 como compañero de programación. Así me fue, incluido el error que cometimos en el lanzamiento.
Por qué migramos
Sitefinity funcionaba muy bien. Es un CMS robusto y muy granular, que permite controlar casi cada parte del sitio. Pero nuestro equipo trabajaba con un mindset mucho más ágil que aquel para el que la plataforma fue pensada. Nos movíamos rápido, con cambios frecuentes y un equipo pequeño, y el alcance de Sitefinity apuntaba a operaciones más grandes. Para una empresa con diez o más mercados, ese nivel de control probablemente se justifica. Para nosotros significaba más proceso del que necesitábamos y una licencia cara para lo que realmente usábamos.
El sitio llevaba cerca de un año creciendo a base de páginas nuevas, arreglos rápidos y parches. Eso es normal en un sitio de marketing, y también lo es la deuda técnica que viene con eso. Los estilos estaban definidos en varios lugares, algunos componentes hacían casi lo mismo y los cambios pequeños tomaban más tiempo del que deberían. En un equipo de dos personas, cada cambio lento tiene un costo real.
El nuevo stack
- Astro genera las páginas como HTML estático y solo envía JavaScript para los componentes que lo necesitan (documentación de Astro). En un sitio que es principalmente contenido, eso mantiene las páginas livianas.
- Sanity guarda el contenido, y el equipo lo edita en Sanity Studio. Astro lo lee al momento de compilar.
- Vercel compila y aloja el sitio desde el repositorio de Git.
Paso 1: inventariar todas las URLs
Antes de escribir una línea de código, hice una lista de todas las URLs del sitio antiguo: páginas, artículos del blog, landing pages y todo lo que tuviera enlaces desde anuncios, correos u otros sitios. Ese inventario se convirtió en la checklist de todo el proyecto. Si una URL estaba en la lista, necesitaba una página en el sitio nuevo o una redirección.
Paso 2: mapear las redirecciones 301
Algunas URLs cambiaron, así que cada URL antigua tuvo una redirección permanente a su equivalente más cercano en el sitio nuevo. Google recomienda redirecciones permanentes del lado del servidor (301 o 308), asignar las páginas antiguas una a una en lugar de mandar todo a la página de inicio, evitar cadenas de redirecciones y mantenerlas por al menos un año (Google Search Central). Seguimos esa lista punto por punto y probamos cada redirección antes del lanzamiento.
Paso 3: centralizar el sistema de diseño
Un año de parches había dejado el sistema de diseño fragmentado. Teníamos colores, tamaños de fuente y espaciados repetidos en distintos archivos, y varias versiones de la misma tarjeta o del mismo botón. Durante la migración, junté esos valores en un solo conjunto de estilos compartidos y rehice los componentes una sola vez, para que todas las páginas usen las mismas piezas. El diseño de página web se vuelve más rápido cuando una página nueva es principalmente una combinación de componentes que ya existen.
Cómo ayudó la IA en el desarrollo front end
El desarrollo front end con IA funcionó mejor en tareas bien definidas. Opus 5.5 me ayudó a rehacer las páginas como componentes de Astro, escribir los esquemas de contenido de Sanity, convertir el inventario de URLs en reglas de redirección y detectar inconsistencias entre componentes. Revisé cada cambio y comparé cada página con el sitio antiguo antes de seguir.
El diseño con IA sigue necesitando a una persona que tome las decisiones. El modelo era rápido para generar código, pero elegir qué mantener, qué fusionar y qué eliminar del sistema de diseño era mi trabajo. Esa revisión es lo que hizo posible hacerlo en unos pocos días sin romper el sitio.
El error: sin webhook en el lanzamiento
El sitio es estático, así que solo cambia cuando Vercel ejecuta una nueva compilación. En el lanzamiento olvidamos conectar Sanity con Vercel, así que el contenido publicado en Sanity no aparecía en el sitio hasta que alguien volvía a hacer un deploy.
La solución tomó unos minutos. Vercel permite crear un deploy hook, una URL que inicia una nueva compilación cuando recibe una solicitud (documentación de Vercel). En Sanity creamos un webhook que llama a esa URL cada vez que se publica un documento (documentación de Sanity). Ahora, al hacer clic en Publish, el sitio en vivo se actualiza en un par de minutos.
Qué cambió para un equipo de dos
Antes, los cambios pequeños de contenido muchas veces necesitaban tiempo de desarrollo dentro de Sitefinity. Ahora el equipo edita el contenido en Sanity y lo publica directamente, y las páginas nuevas se arman con los componentes compartidos. Hacer una página web con IA de esta forma acortó el tiempo entre una decisión y una página en vivo, aunque la planificación siguió necesitando el mismo cuidado.
Bueno, eso es todo por ahora. Si estás planeando una migración parecida, empieza por el inventario de URLs. ¡Nos vemos!