De dos décadas de historia atrapadas en servidores y bases de datos caras

Cuando un medio lleva más de veinte años almacenando datos de cada partido partido de rugby que se juega, su mayor activo deja de ser una web y pasa a ser una fuente de datos historicos únicos. Miles de resultados, estadísticas, fotos y archivos acumulados a lo largo de dos décadas. Rugby Champagne, tenía esa historia (de hecho, el archivo de rugby más completo del país) pero la tenía guardada en un sistema que se había vuelto un problema más que una ventaja.

El punto de partida

La plataforma corría sobre máquinas virtuales tradicionales y una base de datos SQL Server. Sobre el papel funcionaba (siendo relajados con la palabra funcionar). En la práctica, arrastraba los problemas típicos de una arquitectura pensada para otra época:

  • Costos fijos altos: Las licencias de SQL Server y los servidores siempre encendidos se pagaban completos todos los meses, hubiera o no tráfico. Se pagaba por la capacidad de aguantar el peor día del año, los 365 días del año.
  • No escalaba: Cuando un partido importante o una noticia fuerte traían un pico de visitas, el sitio se ponía lento o directamente se caía. Justo en el momento de mayor audiencia, que es cuando un medio no se puede permitir estar afuera.
  • Techo de crecimiento: Crecer significaba comprar y configurar más servidores por adelantado. La infraestructura venia frrenando su crecimiento.

El miedo de fondo (el mismo que frena a casi todos los que están en esta situación) era uno solo: si tocamos esto, ¿perdemos veinte años de información?

La decisión

La premisa fue clara desde el principio: migrar no podía significar empezar de cero ni resignar el archivo histórico. Todo lo publicado en estas dos décadas tenía que sobrevivir, quedar accesible y conservar sus direcciones para no romper enlaces ni perder posicionamiento. Por eso no fue un “apagar lo viejo y prender lo nuevo”. Fue una migración por etapas, con la información vieja conviviendo con la nueva mientras se trasladaba, se verificaba y se daba de baja la pieza anterior recién cuando la nueva ya estaba probada. En ningún momento el sitio dejó de estar online.

La solución

Reemplazamos el esquema de servidores siempre encendidos por una arquitectura en la nube donde cada parte hace una sola cosa y se paga por lo que realmente se usa:

  • La base de datos pasó de SQL Server a PostgreSQL administrado, una solución abierta, rápida y sin costos de licencia.
  • La aplicación dejó de vivir en máquinas virtuales fijas y pasó a infraestructura sin servidores (serverless) que se enciende sola cuando hay tráfico y se apaga cuando no lo hay.
  • El contenido pesado (imágenes, archivos, galerías) se movió a almacenamiento de objetos en la nube, servido desde una red de distribución global.
    • De cara al usuario que consume estos datos en la web y la app, se sumó una capa de caché edge (CDN): las páginas se entregan desde el punto más cercano al usuario, lo que descarga al sistema y acelera todo.

El resultado es una plataforma que se adapta sola a la demanda en lugar de obligar al medio a anticiparla y pagarla por adelantado.

El detalle técnico, para quien lo quiera

La migración fue de SQL Server sobre máquinas virtuales a un stack de PostgreSQL administrado (Supabase), una API en Node.js sobre Google Cloud Run (serverless, escala a demanda y a cero), frontend en Astro con renderizado en el servidor, almacenamiento de medios en Cloudflare R2 y caché en el borde sobre Cloudflare, con reglas de protección frente a tráfico automatizado abusivo. Cada componente escala de forma independiente.

Los resultados

Velocidad y consistencia tanto para los que gestionan estos datos como para los usuarios que lo consumen, mejorando la productividad interna de la empresa y ofreciendo una experiencia mas fluida para los clientes

Siempre online. La plataforma sostiene un 99% de disponibilidad. Las caídas en momentos de alto tráfico dejaron de ser un tema: el sistema resiste volúmenes imprevistos de tráfico sin que la carga del sitio se vea afectada en absoluto.

**Más barato y, sobre todo, con lugar para crecer. **Se eliminaron las licencias de base de datos y los servidores ociosos: el gasto pasó de un costo fijo alto a uno variable y proporcional al uso real. Pero el cambio más importante no es solo el ahorro: es que ahora crecer ya no cuesta una inversión por adelantado. La infraestructura acompaña al proyecto en lugar de ponerle un techo.

El archivo, intacto. Se migraron más de 20 años de información histórica. Nada quedó en el camino.

La lección para quien está evaluando lo mismo

Cambiar un sistema que “todavía funciona” da miedo, sobre todo cuando lleva años de historia encima. Pero seguir sosteniendo una infraestructura cara y rígida también tiene un costo: el que se paga todos los meses, y el de no poder crecer cuando llega la oportunidad.

La buena noticia es que migrar no obliga a elegir entre el pasado y el futuro. Se puede pasar a tecnología moderna, más económica y que escala sola, sin perder nada de lo construido. Eso fue exactamente lo que hicimos con Rugby Champagne, el banco de datos de rugby más importante de la Argentina.